
Writing Docs
Add or edit Remotion public docs as MDX with correct sidebar, crumbs, headings-per-field, and social preview cards.
Overview
Writing Docs is an agent skill for the Build phase that governs how Remotion MDX documentation pages, sidebars, and API reference structure are authored.
Install
npx skills add https://github.com/remotion-dev/remotion --skill writing-docsWhat is this skill?
- 4-step flow: new MDX under packages/docs/docs, sidebars.ts entry, content rules, bun render-cards.ts for previews
- One public API per page—no combined codec helper pages
- crumb frontmatter for package breadcrumbs above titles
- Each API option and return field uses ### / #### headings, not bullet lists
- Public API only—no internal/private API comparisons
- 4-step checklist for adding a new documentation page
Adoption & trust: 1.3k installs on skills.sh; 49.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are adding Remotion API docs but risk wrong sidebar wiring, merged API pages, or bullet-style field lists that fail review.
Who is it for?
Developers documenting Remotion packages or patching packages/docs who want agent output to pass maintainers’ structural rules on the first pass.
Skip if: Non-Remotion products, internal runbooks, or marketing landing copy outside packages/docs.
When should I use this skill?
Adding docs pages, editing MDX files in packages/docs, or writing documentation content for Remotion.
What do I get? / Deliverables
You get MDX that matches Remotion conventions—one API per page, heading-per-field, optional crumb, sidebar entry, and regenerated preview card images.
- New or updated .mdx page
- sidebars.ts registration
- Generated social preview card assets
Recommended Skills
Journey fit
How it compares
Use instead of generic “write good docs” prompts when the target is Remotion’s MDX site and sidebar pipeline.
Common Questions / FAQ
Who is writing-docs for?
Remotion contributors and indie builders maintaining programmatic video libraries who edit packages/docs MDX with Claude Code, Cursor, or Codex.
When should I use writing-docs?
Use it during Build when adding docs pages, editing MDX under packages/docs, or refreshing API reference before a Remotion release.
Is writing-docs safe to install?
It describes repo file edits and a local bun script—review the Security Audits panel on this Prism page and treat filesystem access like any docs PR.
SKILL.md
READMESKILL.md - Writing Docs
# Writing Remotion Documentation Documentation lives in `packages/docs/docs` as `.mdx` files. ## Adding a new page 1. Create a new `.mdx` file in `packages/docs/docs` 2. Add the document to `packages/docs/sidebars.ts` 3. Write the content following guidelines below 4. 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. ```md --- image: /generated/articles-docs-my-package-my-api.png title: '<MyComponent>' 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](/docs/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: ````md ```ts const x = 1; ``` ```` ### Type-safe snippets (preferred) Use `twoslash` to check snippets against TypeScript: ````md ```ts twoslash import {useCurrentFrame} from 'remotion'; const frame = useCurrentFrame(); ``` ```` ### Hiding imports Use `// ---cut---` to hide setup code - only content below is displayed: ````md ```ts twoslash import {useCurrentFrame} from 'remotion'; // ---cut--- const frame = useCurrentFrame(); ``` ```` ### Adding titles Always add a `title` to code fences that show example usage: ````md ```ts twoslash title="MyComponent.tsx" console.log('Hello'); ``` ```` ## Special components ### Steps ```md - <Step>1</Step> First step - <Step>2</Step> Second step ``` ### Experimental badge ```md <ExperimentalBadge> <p>This feature is experimental.</p> </ExperimentalBadge> ``` ### Interactive demos ```md <Demo type="rect"/> ``` 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 `<AvailableFrom>` inline so it appears next to the title (not below it). Use `<` and `>` to escape angle brackets in component names: ```md # <MyComponent><AvailableFrom v="4.0.123" /> ``` ```md # @remotion/my-package<AvailableFrom v="4.0.123" /> ``` For section headings: ```md ## Saving to another cloud<AvailableFrom v="3.2.23" /> ``` ### 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