home / skills / vercel / next.js / authoring-skills

authoring-skills skill

/.agents/skills/authoring-skills

This skill helps you create, structure, and maintain agent skills under .agents/skills by guiding frontmatter, content, and naming conventions.

npx playbooks add skill vercel/next.js --skill authoring-skills

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.0 KB
---
name: authoring-skills
description: >
  How to create and maintain agent skills in .agents/skills/. Use when
  creating a new SKILL.md, writing skill descriptions, choosing frontmatter
  fields, or deciding what content belongs in a skill vs AGENTS.md.
  Covers the supported spec fields, description writing, naming conventions,
  and the relationship between always-loaded AGENTS.md and on-demand skills.
user-invocable: false
---

# Authoring Skills

Use this skill when creating or modifying agent skills in `.agents/skills/`.

## When to Create a Skill

Create a skill when content is:

- Too detailed for AGENTS.md (code templates, multi-step workflows, diagnostic procedures)
- Only relevant for specific tasks (not needed every session)
- Self-contained enough to load independently

Keep in AGENTS.md instead when:

- It's a one-liner rule or guardrail every session needs
- It's a general-purpose gotcha any agent could hit

## File Structure

```
.agents/skills/
└── my-skill/
    ├── SKILL.md          # Required: frontmatter + content
    ├── workflow.md        # Optional: supplementary detail
    └── examples.md        # Optional: referenced from SKILL.md
```

## Supported Frontmatter Fields

```yaml
---
name: my-skill # Required. Used for $name references and /name commands.
description: > # Required. How Claude decides to auto-load the skill.
  What this covers and when to use it. Include file names and keywords.
argument-hint: '<pr-number>' # Optional. Hint for expected arguments.
user-invocable: false # Optional. Set false to hide from / menu.
disable-model-invocation: true # Optional. Set true to prevent auto-triggering.
allowed-tools: [Bash, Read] # Optional. Tools allowed without permission.
model: opus # Optional. Model override.
context: fork # Optional. Isolated subagent execution.
agent: Explore # Optional. Subagent type (with context: fork).
---
```

Only use fields from this list. Unknown fields are silently ignored.

## Writing Descriptions

The `description` is the primary matching surface for auto-activation. Include:

1. **What the skill covers** (topic)
2. **When to use it** (trigger scenario)
3. **Key file names** the skill references (e.g. `config-shared.ts`)
4. **Keywords** a user or agent might mention (e.g. "feature flag", "DCE")

```yaml
# Too vague - won't auto-trigger reliably
description: Helps with flags.

# Good - specific files and concepts for matching
description: >
  How to add or modify Next.js experimental feature flags end-to-end.
  Use when editing config-shared.ts, config-schema.ts, define-env-plugin.ts.
```

## Content Conventions

### Structure for Action

Skills should tell the agent what to **do**, not just what to **know**:

- Lead with "Use this skill when..."
- Include step-by-step procedures
- Add code templates ready to adapt
- End with verification commands
- Cross-reference related skills in a "Related Skills" section

### Relationship to AGENTS.md

| AGENTS.md (always loaded)               | Skills (on demand)                                                     |
| --------------------------------------- | ---------------------------------------------------------------------- |
| One-liner guardrails                    | Step-by-step workflows                                                 |
| "Keep require() behind if/else for DCE" | Full DCE pattern with code examples, verification commands, edge cases |
| Points to skills via `$name`            | Expands on AGENTS.md rules                                             |

When adding a skill, also add a one-liner summary to the relevant AGENTS.md section with a `$skill-name` reference.

### Naming

- Short, descriptive, topic-scoped: `flags`, `dce-edge`, `react-vendoring`
- No repo prefix (already scoped by `.agents/skills/`)
- Hyphens for multi-word names

### Supplementary Files

For complex skills, use a hub + detail pattern:

```
pr-status-triage/
├── SKILL.md         # Overview, quick commands, links to details
├── workflow.md      # Prioritization and patterns
└── local-repro.md   # CI env matching
```

Overview

This skill explains how to create and maintain agent skills in the .agents/skills/ directory. It helps you decide when to split content out of the always-loaded agent file into on-demand skills and how to structure metadata, naming, and supplementary files for reliable auto-loading and discoverability.

How this skill works

It inspects and prescribes the required frontmatter fields and values the agent runtime recognizes and shows how description text drives auto-activation. It guides how to organize content into a short hub file plus optional detail pages, what belongs in the always-loaded agent file versus an on-demand skill, and how to reference skills from the main agent surface.

When to use it

  • When content is too detailed for the always-loaded agent surface (multi-step workflows or code templates).
  • When information applies only to specific tasks and should load on demand.
  • When you need a self-contained troubleshooting or diagnostic procedure.
  • When adding step-by-step verification commands and examples for a pattern.
  • When you want to keep short guardrails in the always-loaded file but expand details separately.

Best practices

  • Make the description the primary matching surface: state what it covers, when to use it, key file names, and matching keywords.
  • Lead with 'Use this skill when...' and include concrete, numbered steps and verification commands.
  • Use only the supported frontmatter fields and avoid unknown fields to ensure runtime compatibility.
  • Name skills short and topic-scoped with hyphens for multi-word names (no repo prefixes).
  • Add a one-line summary in the always-loaded agent file that references the skill by name.

Example use cases

  • Documenting an end-to-end feature flag change with file list, code snippets, and verification commands.
  • Providing a DCE pattern with full code examples, edge cases, and CI checks separate from guardrails.
  • Creating a triage hub that links to workflows, repro steps, and prioritization guidance.
  • Packaging a local reproduction guide for flaky CI that includes environment setup and debug commands.

FAQ

Which frontmatter fields are allowed?

Only use the recognized fields listed by the runtime: name, description, argument-hint, user-invocable, disable-model-invocation, allowed-tools, model, context, and agent.

How do I make a skill auto-load reliably?

Write a specific description that includes the topic, trigger scenarios, key filenames, and likely keywords so the matcher can trigger the skill when relevant.