W

writing-docs

by @remotion-devv
4.4(40)

Remotionドキュメントを作成し、新しい.mdxファイルの作成方法とドキュメント構造への追加方法を指導し、ドキュメントの標準化を確保します。

technical-documentationapi-documentationmarkdowndeveloper-experienceremotionGitHub
インストール方法
npx skills add https://github.com/remotion-dev/remotion --skill writing-docs
compare_arrows

Before / After 効果比較

1 组
使用前

明確な指示がない場合、文書作成は統一された規範を欠きがちで、内容の書式が不一致になったり、構造が混乱したりします。これにより、文書は読みにくく、保守が困難になり、情報伝達の効率が低下し、チームの協力に影響を与えます。

使用後

標準化された文書作成プロセスは、文書の作成方法と整理方法を指導し、内容の書式と構造の統一を保証します。これにより、文書の可読性と保守性が大幅に向上し、情報の正確な伝達が確保され、チームの効率的な協力が促進されます。

SKILL.md

writing-docs

Writing Remotion Documentation Documentation lives in packages/docs/docs as .mdx files. Adding a new page Create a new .mdx file in packages/docs/docs Add the document to packages/docs/sidebars.ts Write the content following guidelines below Run bun render-cards.ts in packages/docs to generate social preview cards Breadcrumb (crumb): If a documentation page belongs to a package, add crumb: '@remotion/package-name' to the frontmatter. This displays the package name as a breadcrumb above the title. --- image: /generated/articles-docs-my-package-my-api.png title: '' crumb: '@remotion/my-package' --- One API per page: Each function or API should have its own dedicated documentation page. Do not combine multiple APIs (e.g., getEncodableVideoCodecs() and getEncodableAudioCodecs()) on a single page. Public API only: Documentation is for public APIs only. Do not mention, reference, or compare against internal/private APIs or implementation details. Use headings for all fields: When documenting API options or return values, each property should be its own heading. Use ### for top-level properties and #### for nested properties within an options object. Do not use bullet points for individual fields. Language guidelines Keep it brief: Developers don't like to read. Extra words cause information loss. Link to terminology: Use terminology page for Remotion-specific terms. Avoid emotions: Remove filler like "Great! Let's move on..." - it adds no information. Separate into paragraphs: Break up long sections. Address as "you": Not "we". Don't blame the user: Say "The input is invalid" not "You provided wrong input". Don't assume it's easy: Avoid "simply" and "just" - beginners may struggle. Code snippets Basic syntax highlighting: ts const x = 1; Type-safe snippets (preferred) Use twoslash to check snippets against TypeScript: ts twoslash import {useCurrentFrame} from 'remotion'; const frame = useCurrentFrame(); Hiding imports Use // ---cut--- to hide setup code - only content below is displayed: ts twoslash import {useCurrentFrame} from 'remotion'; // ---cut--- const frame = useCurrentFrame(); Adding titles Always add a title to code fences that show example usage: ts twoslash title="MyComponent.tsx" console.log('Hello'); Special components Steps - 1 First step - 2 Second step Experimental badge This feature is experimental. Interactive demos Demos must be implemented in packages/docs/components/demos/index.tsx. See the docs-demo skill for details on adding new demos. AvailableFrom Use to indicate when a feature or parameter was added. No import needed - it's globally available. For page-level version indicators, use an # h1 heading with inline so it appears next to the title (not below it). Use < and > to escape angle brackets in component names: # <MyComponent> # @remotion/my-package For section headings: ## Saving to another cloud CompatibilityTable Use to indicate which runtimes and environments a component or API supports. No import needed. Place it in a ## Compatibility section before ## See also. Available boolean props: chrome, firefox, safari, player, studio, clientSideRendering, serverSideRendering. Set to true (supported) or {false} (not supported). Set to empty string "" for not applicable if this is a frontend API: nodejs="", bun="", serverlessFunctions="". Use hideServers to hide the Node.js/Bun/serverless row if this is a frontend API. ## Compatibility Optional parameters For optional parameters in API documentation: Add ? to the heading - this indicates the parameter is optional --> Don't do it if it is a CLI flag (beginning with --) - CLI flags are always optional Do NOT add optional text - the ? suffix is sufficient Include default value in description - mention it naturally in the text ### onError? Called when an error occurs. Default: errors are thrown. Do NOT do this: ### onError? optional Called when an error occurs. Combining optional and AvailableFrom When a parameter is both optional and was added in a specific version: ### onError? Called when an error occurs. "Optional since" pattern If a parameter became optional in a specific version (was previously required): ### codec? Optional since . Previously required. Generating preview cards After adding or editing a page, generate social media preview cards: cd packages/docs && bun render-cards.ts Verifying docs compile To check that documentation builds without errors: # from the monorepo root bun run build-docs This validates MDX syntax, twoslash snippets, and broken links.Weekly Installs373Repositoryremotion-dev/remotionGitHub Stars39.6KFirst SeenJan 20, 2026Security AuditsGen Agent Trust HubPassSocketPassSnykPassInstalled onclaude-code321opencode263gemini-cli263cursor258codex249github-copilot201

ユーザーレビュー (0)

レビューを書く

効果
使いやすさ
ドキュメント
互換性

レビューなし

統計データ

インストール数2.7K
評価4.4 / 5.0
バージョン
更新日2026年10月14日
比較事例1 件

ユーザー評価

4.4(40)
5
28%
4
50%
3
20%
2
3%
1
0%

この Skill を評価

0.0

対応プラットフォーム

🔧Claude Code
🔧OpenClaw
🔧OpenCode
🔧Codex
🔧Gemini CLI
🔧GitHub Copilot
🔧Amp
🔧Kimi CLI

タイムライン

作成2026年3月17日
最終更新2026年10月14日
🎁 Agent 知識カード
アンケート