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-guidenpx skills add vercel/next.js --skill write-guidegit 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.00102 | $0.01288 |
| Opus 5 | $0.00051 | $0.00644 |
| Sonnet 5 | $0.00020 | $0.00258 |
| Haiku 4.5 | $0.00010 | $0.00129 |
Grade A, and why
write-guide 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing Guides
Goal
Produce a technical guide that teaches a real-world use case through progressive examples. Concepts are introduced only when the reader needs them.
Each guide solves one specific problem. Not a category of problems. If the outline has 5+ steps or covers multiple approaches, split it.
Structure
Every guide follows this arc: introduction, example setup, 2-5 progressive steps, next steps.
Each step follows this loop: working code → new requirement → friction → explanation → resolution → observable proof.
Sections: introduction (no heading, 2 paragraphs max), ## Example (what we're building + source link), ### Step N (action-oriented titles, 2-4 steps), ## Next steps (summary + related links).
Headings should tell a story on their own. If readers only saw the headings, they'd understand the guide's takeaway.
Template
---
title: {Action-oriented, e.g., "Building X" or "How to Y"}
description: {One sentence}
nav_title: {Short title for navigation}
---
{What the reader will accomplish and why it matters. The friction and how this approach resolves it. 2 paragraphs max.}
## Example
As an example, we'll build {what we're building}.
We'll start with {step 1}, then {step 2}, and {step 3}.
{Source code link.}
### Step 1: {Action-oriented title}
{Brief context, 1-2 sentences.}
```tsx filename="path/to/file.tsx"
// Minimal working code
```
{Explain what happens.}
{Introduce friction: warning, limitation, or constraint.}
{Resolution: explain the choice, apply the fix.}
{Verify the fix with observable proof.}
### Step 2: {Action-oriented title}
{Same pattern: context → code → explain → friction → resolution → proof.}
### Step 3: {Action-oriented title}
{Same pattern.}
## Next steps
You now know how to {summary}.
Next, learn how to:
- [Related guide 1]()
- [Related guide 2]()
Workflow
- Research: Check available skills for relevant features. Read existing docs for context and linking opportunities.
- Plan: Outline sections. Verify scope (one problem, 2-4 steps). Each step needs a friction point and resolution.
- Write: Follow the template above. Apply the rules below.
- Review: Re-read the rules, verify, then present.
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 · 126 lines · 102 tokens per session scan A 19a5397fd694
write-guide is a skill published in the GitHub repository vercel/next.js (142,020 stars, last pushed yesterday), licensed MIT. It adds 102 tokens to every session and 1,288 once invoked, about $0.0005 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
guide
Create new article guides for Recharts users.
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.
resource-curator
Find, evaluate, and maintain high-quality external resources for JavaScript concept documentation, including auditing for broken and outdated links.