Author Skill

author-skill — write skills that trigger and teach

This is the meta skill: it authors and edits the other skills in the rsc catalog. A skill is two things bolted together — a description that fires at the right moment, and a body that makes the agent better once it fires. Most skills fail on the first. Treat them as two separate engineering problems with two separate quality bars.

Where the SDD chain (specify → plan → … → ship) builds product, author-skill builds the tools that build product. Use it whenever a skill is born or edited.

Not this skill — delegate: a product feature specced or planned → ../specify/SKILL.md, ../plan/SKILL.md. An autonomous agent or tool-calling loop → ../building-agents/SKILL.md. Generic project docs or a wiki article → the ../harness/SKILL.md 02-DOCS engine. Bootstrapping a workspace or profiling the user → ../init/SKILL.md.

Read 02-DOCS/wiki/harness/user-profile.md and speak in the register its technical_level records (technical terms, or plain words with analogies); ../init/SKILL.md sets it, and orient owns the voice. With no profile, use analogies and ask once "technical or with analogies?" — skill authoring is itself a technical act, so a non-technical author needs each convention explained, not just named.

What a skill is (the anatomy)

skills/<id>/
├── SKILL.md              the body: frontmatter (name + description + origin) then the prose
├── references/           progressive-disclosure detail, loaded only when the body points to it
│   └── <topic>.md
├── evals/
│   ├── cases.yaml        trigger + capability test cases
│   └── README.md         how to run the evals, honestly
└── scripts/              optional; verify.sh + helpers for skills with a checkable artifact
    └── verify.sh

The frontmatter decides if the skill loads. The body decides how good the agent is once it does.

The description — the single highest-leverage line

The description sits in context on every turn the skill is installed, invoked or not. The body is only paid for when the skill fires; the description is paid for always. So length here is a cost, never a credit. A vague description is a skill that never fires; an over-broad one hijacks unrelated turns. Get this right before anything else.

Rules, all enforced:

1. Third person, present tense. "Use when authoring a new skill…" — never "I help you…" or "You should…". The agent is reading about the skill.
2. Discriminative, not exhaustive. Lead with a Use when … clause naming the situation, then only the capabilities that separate this skill from its neighbours. Do not append a Triggers: '…', '…' phrase list: the model matches on meaning, so a keyword bank in three languages buys nothing and is charged on every turn. The test is discrimination, not coverage — could a reader pick this skill over its nearest sibling from this line alone?
3. Draw the boundary. End with a NOT <x> (that is <sibling>) clause, naming a sibling that actually exists under skills/. Negative space prevents hijacking as much as positive matching causes firing.
4. Aim ≤ 350 characters; 1024 is the schema-enforced hard limit. One physical line, wrapped in double quotes, internal quotes escaped or avoided. If it does not parse, the skill does not load.
5. origin: risco on its own line. This marks it as ours.

# Good — situation, the few capabilities that discriminate, a real boundary
description: "Use when X happens or the user shows symptom Y — doing A, fixing B, choosing C. NOT Z (that is `sibling`)."

# Bad — first person, no situation, no boundary; competes with every sibling on every turn
description: "I help you write great skills and make them work."

The full recipe, the budget tactics, and a worked before/after → references/description-recipe.md.

Progressive disclosure — the body is an index, not an encyclopedia

The body is loaded in full whenever the skill fires, so every line competes for the agent's attention. Write the smallest body that still routes correctly: 400 lines is a ceiling, not a target, and there is no floor — a skill that does its job in 60 lines beats the same skill padded to 200. Push anything long, reference-like, or rarely-needed into references/<topic>.md and link it inline at the point of use ("full table → references/foo.md").

Decide where a paragraph lives:

Every file under references/ must be linked from the body. An unlinked reference is never loaded, so it is dead weight in the package — link it or delete it.

The hybrid structure — when each piece earns its place

• SKILL.md — always. Frontmatter + focused body.
• references/ — only when the body genuinely needs offloaded depth. Do not create an empty references/ to look complete; a single-file skill is fine.
• evals/ — always. cases.yaml + README.md. A skill with no evals is unverifiable and does not ship.
• scripts/verify.sh — only when the skill produces a checkable artifact (code, config, copy with a ban-list). Process skills — those judged on the safety rails they install in the agent's behavior, like the SDD-phase skills or this one — do not ship a verify.sh; their evals carry a capability scenario instead.

Orientation footer (required in every new skill)

Every new skill MUST end with the orientation footer so the harness never leaves the user in seco. Append verbatim:

## Orientación (siempre)

Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)

The full protocol lives once in the orient skill; the footer only references it.

The authoring workflow

Run in order. Each step gates the next.

1. Name & scope. One skill, one job. Pick a short kebab-case <id> that is the job, not the domain. If you can not say the job in one sentence, the scope is wrong — split it. Check no sibling already owns this; if one half-owns it, decide edit the sibling vs new skill before writing.
2. Draft the description. Per the rules above. This first, because writing it forces the scope clear. → references/description-recipe.md.
3. Outline the body. Method, rules, decision points. Mark what becomes a reference.
4. Write the body in the rsc voice (see below). Tag every code/example fence with a language. Add a checklist or decision table only where the flow actually branches — not as decoration. Add a short anti-patterns table.
5. Extract references for anything long or branch-specific, and link each one inline.
6. Write the evals — cases.yaml then README.md. → references/eval-authoring.md.
7. Wire it into the rsc plumbing (tags, recommends, npm run manifest, and indexing any artifact in 02-DOCS/wiki/index.md — the Knowledge map; root CLAUDE.md keeps only a short pointer). → references/rsc-conventions.md.
8. Self-audit against the rubric (below). Fix every miss or justify it.

The rsc voice

Match the catalog, do not invent a new register:

• Direct, second-person-to-the-agent instruction ("Read the profile first", "Cut any section with no job").
• A rule gets stated where it applies, with a one-line why that makes it obviously absolute — not a lecture, and not a shouted NON-NEGOTIABLE.
• Concrete over abstract: a number, a path, a Bad→Good pair beats an adjective.
• Original prose. Mine ideas from anywhere; the words are Eric's. Do not reproduce another ecosystem's signature artifacts or phrasing — no borrowed "1% chance" urgency blocks, no copied rationalization wording, no *-reviewer-prompt.md files, no verbatim flowcharts. The rsc identity is its own.
• Cross-reference siblings by name or ../<sibling>/SKILL.md, only ones that actually exist.

Match the form to the failure

Before you write an instruction, name the failure it's meant to prevent — then pick the form that actually fixes that failure. The instinct is to write a prohibition ("don't do X") for everything. That instinct is wrong for most failures, and measurably counter-productive for one class: a prohibition aimed at output shape tends to summon the very thing it forbids (the model attends to the named token), and can do worse than saying nothing at all. Match deliberately:

So: an anti-patterns table earns its place when it names concrete failure modes the flow above does not already state. A table that re-lists rules from the body is pure cost — delete it and move each rule to its step. And when you catch yourself writing "don't make it X" about the shape of an output, rewrite it as the shape to hit.