Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/vercel/next.js/write-api-referencenpx skills add vercel/next.js --skill write-api-referencegit clone --depth 1 https://github.com/vercel/next.jsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00130 | $0.01880 |
| Opus 5 | $0.00065 | $0.00940 |
| Sonnet 5 | $0.00026 | $0.00376 |
| Haiku 4.5 | $0.00013 | $0.00188 |
Grade A, and why
write-api-reference scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
- Function (
cookies,fetch,generateStaticParams): signature, params/returns, methods table, examples - Component (
Link,Image,Script): props summary table, individual prop docs, examples - File convention (
page,layout,route): definition, code showing the convention, props, behavior, examples - Directive (
use client,use cache): definition, usage, serialization/boundary rules, reference - Config option (
basePath,images, etc.): definition, config code, behavioral sections
Template
---
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.} |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 149 lines · 130 tokens per session scan A 6c9253dee9cf
write-api-reference is a skill published in the GitHub repository vercel/next.js (142,020 stars, last pushed yesterday), licensed MIT. It adds 130 tokens to every session and 1,880 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
shadcn
Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json…
migrate-radix-to-base
Migrates React projects and components from Radix UI to Base UI. Use when asked to migrate from radix, move to base-ui, convert radix primitives, or switch a shadcn project's base library. Handles single components ("migrate accordion") and whole projects.
theme-component
Add complete theme support for one Recharts component. Invoke with the component name, for example theme-component XAxis.
typescript
Write strongly-typed TypeScript code in Recharts.
example
Create new example charts for Recharts documentation website.
investigate
Find root cause for a bug or an issue in Recharts and propose a solution.