Official agent skill

Write API Reference

by vercel in vercel/next.js

Produces API reference documentation for Next.js APIs: functions, components, file conventions, directives, and config options.

OfficialMITAuto-check passedDocuments & Office

Install Write API Reference

skills CLI
$ npx skills add vercel/next.js --skill write-api-reference -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install vercel/next.js write-api-reference --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/vercel/next.js.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/write-api-reference .claude/skills/write-api-reference && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
write-api-reference
GitHub stars
143k
Token cost
~2.2k tokens
SKILL.md length
809 words
Files
1
Skills in repo
27
Repo updated
First seen
Licence
MIT

At a glance

Produces API reference documentation for Next.js APIs: functions, components, file conventions, directives, and config options.

  • Works in 5 steps: Function (cookies, fetch,… → Component (Link, Image, Script): props… → File convention (page, layout, route):… → …
  • Paths like docs/01-app/03-api-reference/
  • SKILL.md covers Goal, Structure, Rules and Workflow, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Write API Reference is an agent skill from vercel/next.js, published by the product's own GitHub organization. Produces API reference documentation for Next.js APIs: functions, components, file conventions, directives, and config options. Auto-activation: User asks to write, create, or draft an API reference page. Also triggers on paths like docs/01-app/03-api-reference/, or keywords like "API reference", "props", "parameters", "returns", "signature". Input sources: Next.js source code, existing API reference pages, or user-provided specifications. Output type: A markdown (.mdx) API reference page with YAML frontmatter…

Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Documents & Office, covering Markdown. It works with Next.js. The licence is MIT.

When your agent uses it

  • Paths like docs/01-app/03-api-reference/
  • Keywords like API reference

Example prompts

  • “API reference”
  • “parameters”
  • “returns”
  • “/write-api-reference”

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Function (cookies, fetch, generateStaticParams): signature, params/returns, methods table, examples
  2. Component (Link, Image, Script): props summary table, individual prop docs, examples
  3. File convention (page, layout, route): definition, code showing the convention, props, behavior, examples
  4. Directive (use client, use cache): definition, usage, serialization/boundary rules, reference
  5. Config option (basePath, images, etc.): definition, config code, behavioral sections

What it can do on your machine

Read from SKILL.md and the folder at commit a32ddfd. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Write API Reference loads about 2.2k tokens when it runs. Until then it costs about 154 tokens; SKILL.md has 809 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~154
When it runs · the whole SKILL.md, loaded when a task matches
~2.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from vercel/next.js at commit a32ddfd, republished under its MIT licence (© vercel). 809 words, ~2,176 tokens.

Download SKILL.mdSave it as .claude/skills/write-api-reference/SKILL.md (or your agent's skills folder).
name
write-api-reference
description
Produces API reference documentation for Next.js APIs: functions, components, file conventions, directives, and config options. **Auto-activation:** User asks to write, create, or draft an API reference page. Also triggers on paths like `docs/01-app/03-api-reference/`, or keywords like "API reference", "props", "parameters", "returns", "signature". **Input sources:** Next.js source code, existing API reference pages, or user-provided specifications. **Output type:** A markdown (.mdx) API reference page with YAML frontmatter, usage example, reference section, behavior notes, and examples.
agent
Plan
context
fork
metadata.internal
true

Writing API Reference Pages

Goal

Produce an API reference page that documents a single API surface (function, component, file convention, directive, or config option). The page should be concise, scannable, and example-driven.

Each page documents one API. If the API has sub-methods (like cookies.set()), document them on the same page. If two APIs are independent, they get separate pages.

Structure

Identify which category the API belongs to, then follow the corresponding template.

Categories
  1. Function (cookies, fetch, generateStaticParams): signature, params/returns, methods table, examples
  2. Component (Link, Image, Script): props summary table, individual prop docs, examples
  3. File convention (page, layout, route): definition, code showing the convention, props, behavior, examples
  4. Directive (use client, use cache): definition, usage, serialization/boundary rules, reference
  5. Config option (basePath, images, etc.): definition, config code, behavioral sections
Template
markdown
---
title: {API name}
description: {API Reference for the {API name} {function|component|file convention|directive|config option}.}
---

{One sentence defining what it does and where it's used.}

```tsx filename="path/to/file.tsx" switcher
// Minimal working usage
```

```jsx filename="path/to/file.js" switcher
// Same example in JS
```

## Reference

{For functions: methods/params table, return type.}
{For components: props summary table, then `#### propName` subsections.}
{For file conventions: `### Props` with `#### propName` subsections.}
{For directives: usage rules and serialization constraints.}
{For config: options table or individual option docs.}

### {Subsection name}

{Description + code example + table of values where applicable.}

## Good to know

- {Default behavior or implicit effects.}
- {Caveats, limitations, or version-specific notes.}
- {Edge cases the developer should be aware of.}

## Examples

### {Example name}

{Brief context, 1-2 sentences.}

```tsx filename="path/to/file.tsx" switcher
// Complete working example
```

```jsx filename="path/to/file.js" switcher
// Same example in JS
```

## Version History

| Version  | Changes         |
| -------- | --------------- |
| `vX.Y.Z` | {What changed.} |

Category-specific notes:

  • Functions: Lead with the function signature and await if async. Document methods in a table if the return value has methods (like cookies). Document options in a separate table if applicable.
  • Components: Start with a props summary table (| Prop | Example | Type | Required |). Then document each prop under #### propName with description, code example, and value table where useful.
  • File conventions: Show the default export signature with TypeScript types. Document each prop (params, searchParams, etc.) under #### propName with a route/URL/value example table.
  • Directives: No ## Reference section. Use ## Usage instead, showing correct placement. Document serialization constraints and boundary rules.
  • Config options: Show the next.config.ts snippet. Use subsections for each behavioral aspect.

Rules

  1. Lead with what it does. First sentence defines the API. No preamble.
  2. Show working code immediately. A minimal usage example appears right after the opening sentence, before ## Reference.
  3. Use switcher for tsx/jsx pairs. Always include both. Always include filename="path/to/file.ext".
  4. Use highlight={n} for key lines. Highlight the line that demonstrates the API being documented.
  5. Tables for simple APIs, subsections for complex ones. If a prop/param needs only a type and one-line description, use a table row. If it needs a code example or multiple values, use a #### subsection.
  6. Behavior section uses > **Good to know**:or## Good to know. Use the blockquote format for brief notes (1-3 bullets). Use the heading format for longer sections. Not "Note:" or "Warning:".
  7. Examples section uses ### Example Name subsections. Each example solves one specific use case.
  8. Version History table at the end. Include when the API has changed across versions. Omit for new APIs.
  9. No em dashes. Use periods, commas, or parentheses instead.
  10. Mechanical, observable language. Describe what happens, not how it feels. "Returns an object" not "gives you an object".
  11. Link to related docs with relative paths. Use /docs/app/... format.
  12. No selling or justifying. No "powerful", "easily", "simply". State what the API does.
Don'tDo
"This powerful function lets you easily manage cookies""cookies is an async function that reads HTTP request cookies in Server Components"
"You can conveniently access...""Returns an object containing..."
"The best way to handle navigation""<Link> extends the HTML <a> element to provide prefetching and client-side navigation"
Show full SKILL.md (308 more words)Show less
  1. Bridge new framework terms with legacy or generic vocabulary. When the API renames or differentiates from a prior concept (Pages-era term, generic web term, REST vocabulary), include one such synonym in the frontmatter description and once in prose. Example: description: "Use Dynamic Segments to read URL parameters and generate routes from dynamic data." mentions "URL parameters" alongside "Dynamic Segments". One synonym, folded into natural prose. No separate "Synonyms" or "Also known as" section, no keyword stuffing. Goal: preserve discoverability for users still searching the old vocabulary even when the framework has moved on.
Don'tDo
"Learn how to use Route Handlers""Build API endpoints with Route Handlers, the App Router replacement for API Routes"
"Configure dynamic route segments""Read URL parameters from dynamic route segments"

Workflow

  1. Ask for reference material. Ask the user if they have any RFCs, PRs, design docs, or other context that should inform the doc.
  2. Identify the API category (function, component, file convention, directive, config).
  3. Research the implementation. Read the source code to understand params, return types, edge cases, and defaults.
  4. Check e2e tests. Search test/ for tests exercising the API to find real usage patterns, edge cases, and expected behavior.
  5. Check existing related docs for linking opportunities and to avoid duplication.
  6. Write using the appropriate category template. Follow the rules above.
  7. Review against the rules. Verify: one sentence opener, immediate code example, correct switcher/filename usage, tables vs subsections, "Good to know" format, no em dashes, mechanical language.

References

Read these pages in docs/01-app/03-api-reference/ before writing. They demonstrate the patterns above.

  • 04-functions/cookies.mdx - Function with methods table, options table, and behavior notes
  • 03-file-conventions/page.mdx - File convention with props subsections and route/URL/value tables
  • 02-components/link.mdx - Component with props summary table and detailed per-prop docs
  • 01-directives/use-client.mdx - Directive with usage section and serialization rules
  • 04-functions/fetch.mdx - Function with troubleshooting section and version history

© vercel, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/write-api-reference of vercel/next.js.

Open the folder on GitHubat commit a32ddfd

Compare with similar skills

Write API Reference next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Write API Reference compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Write API Reference this skillvercel/next.js143k—~2.2kAutomated safety check: PassMIT
React Zmage IntegrationCaldis/react-zmage946—~370Automated safety check: PassMIT
Live Previewvicoa-ai/vicoa496—~755Automated safety check: NotesAGPL-3.0
Writing Docsc15t/c15t1.9k—~872Automated safety check: PassApache-2.0
Markdown Article FormatterJimLiu/baoyu-skills26k7 repos~3.5kAutomated safety check: PassMIT
MarkitdownImCa0/just-laws78114 repos~3.2kAutomated safety check: NotesMIT

Similar skills

  • React Zmage Integration

    Caldis/react-zmage

    A skill your agent uses when adding the react-zmage React image viewer to an existing React, Next.js, MDX, CMS, markdown, or rich text image surface.

    946 GitHub stars~370 tokensUpdated 4 mo ago
    Documents & OfficeAuto-check passed
  • Live Preview

    vicoa-ai/vicoa

    Start a local app in the current user project, expose it through a tunnel, and return preview details in structured Markdown.

    496 GitHub stars~755 tokensUpdated today
    Documents & OfficeAuto-check: notes
  • Writing Docs

    c15t/c15t

    Author or edit c15t documentation in docs//.mdx — the source for both the c15t.com site and the docs bundled into published packages.

    1.9k GitHub stars~872 tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Markdown Article Formatter

    JimLiu/baoyu-skills

    Reformats plain text or Markdown articles with frontmatter, a title, a summary, headings, bold, lists and code blocks, and saves a separate formatted copy.

    26k GitHub starsUsed in 7 repos~3.5k tokens
    Documents & OfficeAuto-check passed
  • Markitdown

    ImCa0/just-laws

    Convert files and office documents to Markdown. An agent skill from ImCa0/just-laws.

    781 GitHub starsUsed in 14 repos~3.2k tokens
    Documents & OfficeAuto-check: notes
  • Obsidian Markdown

    Atmosphere/atmosphere

    Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax.

    3.8k GitHub starsUsed in 20 repos~1.3k tokens
    Documents & OfficeAuto-check passed

More from vercel/next.js

All 27 skills in this repo
  • Gh Stack

    vercel/next.js

    Official

    Manages stacked PRs and splits multi-part work into reviewable branches with gh-stack.

    143k GitHub starsUsed in 7 repos~2.3k tokens
    Auto-check passed
  • Sandbox Bench

    vercel/next.js

    Official

    Benchmark React or Next.js changes on Vercel Sandbox VMs with paired A/B statistics: react PR/commit vs base, or Next.js PR/commit vs base, measured end-to-end through the bench/render-pipeline app…

    143k GitHub stars~4.1k tokensUpdated today
    Auto-check passed
  • Next Dev Loop

    vercel/next.js

    Official

    Verify Next.js runtime behavior after editing app code. An agent skill from vercel/next.js.

    143k GitHub starsUsed in 9 repos~2.3k tokens
    Auto-check passed
  • Docs Diagrams

    vercel/next.js

    Official

    Draw diagrams for the Next.js docs in the style of the ones already published there: the light/dark PNGs an mdx references with <Image srcLight="/docs/light/<name.png" srcDark="/docs/dark/<name.png".

    143k GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • Official

    Turn on Cache Components in a Next.js app and resolve the blocking routes it surfaces.

    143k GitHub starsUsed in 6 repos~8.3k tokens
    Auto-check passed
  • React Sync

    vercel/next.js

    Official

    Build local React changes in the bundle variants consumed by Next.js, sync them into a local Next.js checkout, and test the resulting integration.

    143k GitHub stars~486 tokensUpdated today
    Auto-check passed

Works with

Questions about Write API Reference

What does Write API Reference do?

Produces API reference documentation for Next.js APIs: functions, components, file conventions, directives, and config options. js, published by the product's own GitHub organization.js APIs: functions, components, file conventions, directives, and config options.

When should I use Write API Reference?

Write API Reference fits situations like: paths like docs/01-app/03-api-reference/; keywords like API reference.

How do I install Write API Reference in Claude Code?

Run `npx skills add vercel/next.js --skill write-api-reference -a claude-code`. Or copy the skill folder (.agents/skills/write-api-reference in vercel/next.js) into .claude/skills/write-api-reference in your project. Claude Code loads it when a task matches its description.

How do I install Write API Reference in Codex?

Run `npx skills add vercel/next.js --skill write-api-reference -a codex`. Or copy the skill folder (.agents/skills/write-api-reference in vercel/next.js) into .agents/skills/write-api-reference in your project. Codex loads it when a task matches its description.

Can I use Write API Reference in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add vercel/next.js --skill write-api-reference -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/write-api-reference, .gemini/skills/write-api-reference, .github/skills/write-api-reference and .opencode/skills/write-api-reference in your project.

What does Write API Reference need to run?

SKILL.md names no scripts, command-line tools or credentials: Write API Reference is instructions for the agent only.

Does Write API Reference access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Write API Reference safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Write API Reference use?

Write API Reference is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Write API Reference use?

About 2.2k tokens (SKILL.md is roughly 8.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Write API Reference?

Skills that share tags, products or a category with Write API Reference: React Zmage Integration (Caldis/react-zmage, 946 stars), Live Preview (vicoa-ai/vicoa, 496 stars), Writing Docs (c15t/c15t, 1.9k stars) and Markdown Article Formatter (JimLiu/baoyu-skills, 26k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Write API Reference?

vercel (a GitHub organization, an official publisher) maintains it in vercel/next.js, which has 143,241 GitHub stars. The repository holds 27 skills in this directory. The repository was last updated on October 8, 2026.

Source: vercel/next.js on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.