Authoring Skill Content
Overview
Guide the authoring of effective SKILL.md files, agent definitions (agents/*.md), and supporting resources within a bundle-plugin. Good content is the difference between skills that agents consistently find and follow — and ones that get ignored or misinterpreted.
Core principle: Write for the agent's experience. Every instruction should be discoverable (good description), loadable (right size), and followable (clear, motivated instructions). Skills are the first-class source of truth in a bundle-plugin — docs and README must not contradict skill content (see bundles-forge:auditing — references/source-of-truth-policy.md).
Skill type: Hybrid — follow the execution flow rigidly (Entry Detection → Path steps → Validation), but apply writing guidance flexibly based on context. The process is discipline-enforcing; the content decisions are pattern-based.
Announce at start: "I'm using the authoring skill to help [write / complete / improve / adapt] [skill / agent] content."
Entry Detection
Determine the authoring path from context:
| Context |
Path |
skill-inventory from blueprinting, or user requests writing new SKILL.md / agent definition from scratch |
Path 1: New Content |
| User provides an existing/external skill to add into a project, or asks to adapt a skill to match project conventions |
Path 2: Integrate Content |
scaffold-output directories exist but SKILL.md body has < 10 non-empty lines |
Path 3: Complete Content |
User provides existing in-project skill-md to improve, or optimization-spec from optimizing with specific changes |
Path 4: Improve Content |
When the target is an agent definition (agents/*.md) rather than a skill, follow the same path logic but use the agent authoring conventions from references/agent-authoring-guide.md.
Step 0: Project Context (all paths)
Before writing any content, verify scope and detect the project context:
- Triage: should this be a skill? — Before writing, verify the content warrants a skill:
- One-off, project-specific conventions → belongs in CLAUDE.md / AGENTS.md, not a skill
- Mechanically enforceable constraints (regex, schema validation) → automate with scripts, not documentation
- Standard practices well-documented by the platform → don't duplicate, cross-reference instead
- Skip this check when arriving from
bundles-forge:blueprinting (triage already done during design)
- Detect project root — look for
skills/ directory + package.json above the target
- If project exists, read 2-3 existing SKILL.md files to extract the project's conventions:
- Description style (verb form after "Use when", scoping patterns)
- Section structure (which headings, in what order)
- Cross-reference format (
project:skill-name prefix)
- Token efficiency patterns (use of
references/, line counts)
- If no project (standalone authoring), use the conventions from
references/skill-writing-guide.md directly
Path 1: New Content
Write skill or agent content from scratch.
- Gather requirements — from
skill-inventory and design document context (blueprinting), user description, or conversation context. Identify: skill purpose, triggering scenarios, expected inputs/outputs, relationship to other skills. When a design document is available, leverage its project overview, target users, and use cases to write more targeted descriptions and overviews
- Load writing guide — read
references/skill-writing-guide.md (frontmatter conventions, description rules, instruction style)
- Write frontmatter —
name (kebab-case matching directory), description (start with "Use when...", under 250 chars, triggering conditions only)
- Write Overview — 1-3 sentences: what the skill does, core principle, skill type declaration (rigid / flexible / hybrid)
- Write the process — step-by-step execution flow. Use imperative form. Explain why, not just what. Include at least one concrete example per key instruction
- Write Common Mistakes — table of pitfalls and fixes (at least 3 entries)
- Write Inputs / Outputs / Integration — declare artifact IDs, calling relationships, and pairing skills
- Check external dependencies:
- Declaration syntax — if the skill references MCP tools or CLI commands, read
references/skill-writing-guide.md "External Tool References" section for allowed-tools declaration, fallback patterns, and CLI vs MCP guidance
- Prerequisites section — if
allowed-tools declares external CLI tools (not git, python, node, npm, npx, bash, or paths under bin//scripts/), confirm the body includes a ## Prerequisites section with a Tool/Check/Install table. Read references/skill-writing-guide.md "Prerequisites Writing" for the standard format
- Evaluate token budget — if body exceeds 300 lines, extract heavy sections to
references/. Front-load critical instructions in the first ~5,000 tokens — after context compaction, only this portion survives
- Run validation (see Post-Action Validation below)
Path 2: Integrate Content
Adapt an existing/external skill to fit a project's conventions and workflow.
- Read the incoming skill — understand its purpose, triggering scenarios, and current structure
- Read project conventions (from Step 0) — identify gaps between the incoming skill and project patterns
- Load writing guide — read
references/skill-writing-guide.md (frontmatter conventions, description rules, instruction style)
- Adapt frontmatter — rewrite
description to match project style (verb form, scoping), ensure name follows project kebab-case convention
- Adapt body structure — restructure sections to match project patterns (Overview, Process, Common Mistakes, Inputs/Outputs/Integration)
- Wire Integration section — add cross-references to existing project skills, declare Inputs/Outputs that connect to the project's workflow graph
- Adapt instruction style — align with project conventions (imperative form, reasoning over directives, example density)
- Evaluate token budget — ensure the adapted skill fits project token norms
- Run validation (see Post-Action Validation below)
Path 3: Complete Content
Fill in scaffolded skill stubs with substantive content.
- Read scaffold structure — identify which directories and stub files exist
- Read project conventions (from Step 0) — match the style of already-completed skills
- Load writing guide — read
references/skill-writing-guide.md (frontmatter conventions, description rules, instruction style)
- Complete frontmatter — fill in
description (triggering conditions, "Use when...", under 250 chars). If name is already set, verify it matches directory name
- Write Overview — core principle + skill type declaration
- Write the process — step-by-step flow based on the skill's intended purpose from the design document or user context
- Write remaining sections — Common Mistakes, Inputs/Outputs/Integration
- Create supporting resources if needed —
references/ for heavy content, assets/ for templates. Read references/skill-writing-guide.md "Supporting Resources" section for thresholds. Front-load critical instructions in the first ~5,000 tokens — after context compaction, only this portion survives
- Run validation (see Post-Action Validation below)
Path 4: Improve Content
Enhance existing in-project content based on user feedback or optimization specs.
- Read existing content — understand current structure, strengths, and gaps
- Identify improvement targets — from user request,
optimization-spec, or self-diagnosis:
- Description not triggering reliably → rewrite following description rules
- Token budget exceeded → extract to
references/, cut redundancy, front-load critical instructions in the first ~5,000 tokens
- Missing sections → add Overview, Common Mistakes, Inputs/Outputs
- Instruction style issues → reframe directives as reasoning, add examples
- Load writing guide if needed — read
references/skill-writing-guide.md (frontmatter conventions, description rules, instruction style)
- Apply changes — make targeted improvements. Preserve what works; don't rewrite content that already follows conventions
- Verify Integration section — ensure cross-references still resolve after changes, artifact IDs match consuming skills
- Run validation (see Post-Action Validation below)
Post-Action Validation
After completing any path, validate the authored content:
- Run lint —
bundles-forge audit-skill <skill-directory> on each authored/modified skill
- If audit script is unavailable: review against
references/quality-checklist.md manually
- Act on findings — fix Critical immediately, fix Warning if straightforward, report Info as suggestions
- Report results — tell the user/calling skill what was validated and any remaining warnings
Common Mistakes
| Mistake |
Fix |
| Description summarizes workflow |
Describe triggering conditions only — agents shortcut to description |
| Piling on MUST/ALWAYS/NEVER |
Explain why the rule exists — understanding beats compliance |
| Putting everything in SKILL.md |
Extract heavy content (100+ lines) to references/; keep body under 500 lines |
| No examples, only abstract rules |
Add at least one concrete example per key instruction |
| Writing for humans, not agents |
Use imperative form, clear structure, explicit output formats |
| Description too narrow |
Be pushy — list related scenarios, edge cases, alternative phrasings |
| Description too broad |
Scope to the right context (e.g., "bundle-plugins" not just "any project") |
| Skipping project conventions |
Always read existing skills first when working in an established project |
| Not wiring Integration section |
Every skill needs Called by / Calls / Pairs with to connect to the workflow graph |
| No defensive instructions for rigid skills |
For rigid/hybrid skills, add explicit loophole closers, rationalization tables, and red-flag lists — see Defensive Writing in references/skill-writing-guide.md |
| Forgetting validation |
Always run bundles-forge audit-skill after authoring — catches issues before they propagate |
Inputs
skill-inventory (optional) — list of skills and agent definitions to write, from bundles-forge:blueprinting design document
scaffold-output (optional) — scaffolded skill directories needing content (from blueprinting pipeline or standalone scaffolding)
skill-md (optional) — existing SKILL.md or agent definition to improve, complete, or adapt
optimization-spec (optional) — specific content changes requested by bundles-forge:optimizing (e.g., rewrite description, reduce tokens, restructure sections)
Outputs
skill-content — completed or improved SKILL.md files following authoring conventions (frontmatter, description, body structure, token efficiency)
agent-content (optional) — completed agents/*.md definitions following agent authoring conventions
Integration
Called by:
- bundles-forge:blueprinting — dispatched as Phase 2 (content writing) in the blueprinting pipeline (write all skills + agent definitions)
- bundles-forge:optimizing — content rewriting for description, token, and structural improvements
- User directly — for standalone SKILL.md or agent definition authoring
Pairs with:
- bundles-forge:scaffolding — scaffolding generates directory structure, authoring fills it with content
- bundles-forge:auditing — auditing validates authored content for quality, cross-references, and security
1---2name: authoring3description: Use when writing, completing, improving, or adapting SKILL.md and agents/*.md in a bundle-plugin — integrating external skills, filling scaffolded stubs, or rewriting for better triggering and token efficiency4---5
6# Authoring Skill Content
7
8## Overview
9
10Guide the authoring of effective SKILL.md files, agent definitions (`agents/*.md`), and supporting resources within a bundle-plugin. Good content is the difference between skills that agents consistently find and follow — and ones that get ignored or misinterpreted.
11
12**Core principle:** Write for the agent's experience. Every instruction should be discoverable (good description), loadable (right size), and followable (clear, motivated instructions). Skills are the first-class source of truth in a bundle-plugin — docs and README must not contradict skill content (see `bundles-forge:auditing` — `references/source-of-truth-policy.md`).
13
14**Skill type:** Hybrid — follow the execution flow rigidly (Entry Detection → Path steps → Validation), but apply writing guidance flexibly based on context. The process is discipline-enforcing; the content decisions are pattern-based.
15
16**Announce at start:** "I'm using the authoring skill to help [write / complete / improve / adapt] [skill / agent] content."
17
18## Entry Detection
19
20Determine the authoring path from context:
21
22| Context | Path |
23|---------|------|
24| `skill-inventory` from blueprinting, or user requests writing new SKILL.md / agent definition from scratch | **Path 1: New Content** |
25| User provides an existing/external skill to add into a project, or asks to adapt a skill to match project conventions | **Path 2: Integrate Content** |
26| `scaffold-output` directories exist but SKILL.md body has < 10 non-empty lines | **Path 3: Complete Content** |
27| User provides existing in-project `skill-md` to improve, or `optimization-spec` from optimizing with specific changes | **Path 4: Improve Content** |
28
29When the target is an agent definition (`agents/*.md`) rather than a skill, follow the same path logic but use the agent authoring conventions from `references/agent-authoring-guide.md`.
30
31## Step 0: Project Context (all paths)
32
33Before writing any content, verify scope and detect the project context:
34
350. **Triage: should this be a skill?** — Before writing, verify the content warrants a skill:
36 - One-off, project-specific conventions → belongs in CLAUDE.md / AGENTS.md, not a skill
37 - Mechanically enforceable constraints (regex, schema validation) → automate with scripts, not documentation
38 - Standard practices well-documented by the platform → don't duplicate, cross-reference instead
39 - Skip this check when arriving from `bundles-forge:blueprinting` (triage already done during design)
401. **Detect project root** — look for `skills/` directory + `package.json` above the target
412. **If project exists**, read 2-3 existing SKILL.md files to extract the project's conventions:
42 - Description style (verb form after "Use when", scoping patterns)
43 - Section structure (which headings, in what order)
44 - Cross-reference format (`project:skill-name` prefix)
45 - Token efficiency patterns (use of `references/`, line counts)
463. **If no project** (standalone authoring), use the conventions from `references/skill-writing-guide.md` directly
47
48## Path 1: New Content
49
50Write skill or agent content from scratch.
51
521. **Gather requirements** — from `skill-inventory` and design document context (blueprinting), user description, or conversation context. Identify: skill purpose, triggering scenarios, expected inputs/outputs, relationship to other skills. When a design document is available, leverage its project overview, target users, and use cases to write more targeted descriptions and overviews
532. **Load writing guide** — read `references/skill-writing-guide.md` (frontmatter conventions, description rules, instruction style)
543. **Write frontmatter** — `name` (kebab-case matching directory), `description` (start with "Use when...", under 250 chars, triggering conditions only)
554. **Write Overview** — 1-3 sentences: what the skill does, core principle, skill type declaration (rigid / flexible / hybrid)
565. **Write the process** — step-by-step execution flow. Use imperative form. Explain why, not just what. Include at least one concrete example per key instruction
576. **Write Common Mistakes** — table of pitfalls and fixes (at least 3 entries)
587. **Write Inputs / Outputs / Integration** — declare artifact IDs, calling relationships, and pairing skills
598. **Check external dependencies:**
60 - **Declaration syntax** — if the skill references MCP tools or CLI commands, read `references/skill-writing-guide.md` "External Tool References" section for `allowed-tools` declaration, fallback patterns, and CLI vs MCP guidance
61 - **Prerequisites section** — if `allowed-tools` declares external CLI tools (not `git`, `python`, `node`, `npm`, `npx`, `bash`, or paths under `bin/`/`scripts/`), confirm the body includes a `## Prerequisites` section with a Tool/Check/Install table. Read `references/skill-writing-guide.md` "Prerequisites Writing" for the standard format
629. **Evaluate token budget** — if body exceeds 300 lines, extract heavy sections to `references/`. Front-load critical instructions in the first ~5,000 tokens — after context compaction, only this portion survives
6310. **Run validation** (see Post-Action Validation below)
64
65## Path 2: Integrate Content
66
67Adapt an existing/external skill to fit a project's conventions and workflow.
68
691. **Read the incoming skill** — understand its purpose, triggering scenarios, and current structure
702. **Read project conventions** (from Step 0) — identify gaps between the incoming skill and project patterns
713. **Load writing guide** — read `references/skill-writing-guide.md` (frontmatter conventions, description rules, instruction style)
724. **Adapt frontmatter** — rewrite `description` to match project style (verb form, scoping), ensure `name` follows project kebab-case convention
735. **Adapt body structure** — restructure sections to match project patterns (Overview, Process, Common Mistakes, Inputs/Outputs/Integration)
746. **Wire Integration section** — add cross-references to existing project skills, declare Inputs/Outputs that connect to the project's workflow graph
757. **Adapt instruction style** — align with project conventions (imperative form, reasoning over directives, example density)
768. **Evaluate token budget** — ensure the adapted skill fits project token norms
779. **Run validation** (see Post-Action Validation below)
78
79## Path 3: Complete Content
80
81Fill in scaffolded skill stubs with substantive content.
82
831. **Read scaffold structure** — identify which directories and stub files exist
842. **Read project conventions** (from Step 0) — match the style of already-completed skills
853. **Load writing guide** — read `references/skill-writing-guide.md` (frontmatter conventions, description rules, instruction style)
864. **Complete frontmatter** — fill in `description` (triggering conditions, "Use when...", under 250 chars). If `name` is already set, verify it matches directory name
875. **Write Overview** — core principle + skill type declaration
886. **Write the process** — step-by-step flow based on the skill's intended purpose from the design document or user context
897. **Write remaining sections** — Common Mistakes, Inputs/Outputs/Integration
908. **Create supporting resources** if needed — `references/` for heavy content, `assets/` for templates. Read `references/skill-writing-guide.md` "Supporting Resources" section for thresholds. Front-load critical instructions in the first ~5,000 tokens — after context compaction, only this portion survives
919. **Run validation** (see Post-Action Validation below)
92
93## Path 4: Improve Content
94
95Enhance existing in-project content based on user feedback or optimization specs.
96
971. **Read existing content** — understand current structure, strengths, and gaps
982. **Identify improvement targets** — from user request, `optimization-spec`, or self-diagnosis:
99 - Description not triggering reliably → rewrite following description rules
100 - Token budget exceeded → extract to `references/`, cut redundancy, front-load critical instructions in the first ~5,000 tokens
101 - Missing sections → add Overview, Common Mistakes, Inputs/Outputs
102 - Instruction style issues → reframe directives as reasoning, add examples
1033. **Load writing guide** if needed — read `references/skill-writing-guide.md` (frontmatter conventions, description rules, instruction style)
1044. **Apply changes** — make targeted improvements. Preserve what works; don't rewrite content that already follows conventions
1055. **Verify Integration section** — ensure cross-references still resolve after changes, artifact IDs match consuming skills
1066. **Run validation** (see Post-Action Validation below)
107
108## Post-Action Validation
109
110After completing any path, validate the authored content:
111
1121. **Run lint** — `bundles-forge audit-skill <skill-directory>` on each authored/modified skill
113 - **If audit script is unavailable:** review against `references/quality-checklist.md` manually
1142. **Act on findings** — fix Critical immediately, fix Warning if straightforward, report Info as suggestions
1153. **Report results** — tell the user/calling skill what was validated and any remaining warnings
116
117## Common Mistakes
118
119| Mistake | Fix |
120|---------|-----|
121| Description summarizes workflow | Describe triggering conditions only — agents shortcut to description |
122| Piling on MUST/ALWAYS/NEVER | Explain why the rule exists — understanding beats compliance |
123| Putting everything in SKILL.md | Extract heavy content (100+ lines) to `references/`; keep body under 500 lines |
124| No examples, only abstract rules | Add at least one concrete example per key instruction |
125| Writing for humans, not agents | Use imperative form, clear structure, explicit output formats |
126| Description too narrow | Be pushy — list related scenarios, edge cases, alternative phrasings |
127| Description too broad | Scope to the right context (e.g., "bundle-plugins" not just "any project") |
128| Skipping project conventions | Always read existing skills first when working in an established project |
129| Not wiring Integration section | Every skill needs Called by / Calls / Pairs with to connect to the workflow graph |
130| No defensive instructions for rigid skills | For rigid/hybrid skills, add explicit loophole closers, rationalization tables, and red-flag lists — see Defensive Writing in `references/skill-writing-guide.md` |
131| Forgetting validation | Always run `bundles-forge audit-skill` after authoring — catches issues before they propagate |
132
133## Inputs
134
135- `skill-inventory` (optional) — list of skills and agent definitions to write, from `bundles-forge:blueprinting` design document
136- `scaffold-output` (optional) — scaffolded skill directories needing content (from blueprinting pipeline or standalone scaffolding)
137- `skill-md` (optional) — existing SKILL.md or agent definition to improve, complete, or adapt
138- `optimization-spec` (optional) — specific content changes requested by `bundles-forge:optimizing` (e.g., rewrite description, reduce tokens, restructure sections)
139
140## Outputs
141
142- `skill-content` — completed or improved SKILL.md files following authoring conventions (frontmatter, description, body structure, token efficiency)
143- `agent-content` (optional) — completed `agents/*.md` definitions following agent authoring conventions
144
145## Integration
146
147**Called by:**
148- **bundles-forge:blueprinting** — dispatched as Phase 2 (content writing) in the blueprinting pipeline (write all skills + agent definitions)
149- **bundles-forge:optimizing** — content rewriting for description, token, and structural improvements
150- User directly — for standalone SKILL.md or agent definition authoring
151
152**Pairs with:**
153- **bundles-forge:scaffolding** — scaffolding generates directory structure, authoring fills it with content
154- **bundles-forge:auditing** — auditing validates authored content for quality, cross-references, and security
155