Skill Authoring
Critical rules
- Put all activation guidance in frontmatter
description. The body loads only after activation. - Description formula:
[Third-person capability]. Use this skill when [triggers]. Do not use when/for [near misses]. - Keep
descriptionunder 1024 characters. No ellipsis (.../…) or placeholders. - Keep
SKILL.mdroughly under 150 lines. Move conditional detail intoreferences/. - Cross-skill references use skill names only (
fn-args-deps). Never relative paths to another skill'sSKILL.md. - Add a resource pointer only after its file exists. Keep references one level deep.
- Before finalizing, read references/quality-checklist.md and run the validators below.
Workflow
- Record two or three realistic tasks (inputs, outputs, success criteria) and two or three strong near misses.
- Inspect nearby skills so you reuse boundaries instead of duplicating policy.
- Write the
descriptionbefore the body. Include realistic phrasing and material near misses. - Build the post-activation body: Critical rules → Workflow → Resources → Validation → Constraints.
- Before drafting long examples or type-specific shapes, read references/skill-types.md and references/examples.md.
- Create
references/,assets/, orscripts/when detail is reusable or would crowd the main file. - Compress: shorten wording, split overloaded bullets, delete duplicated When-to-Use from the body.
- Validate (see Validation). Revise only evidence-backed gaps.
Resources
- references/quality-checklist.md — evidence checklist before publish. Read before finalizing.
- references/skill-types.md — reference / technique / discipline / pattern shapes. Read when choosing structure.
- references/examples.md — WRONG vs CORRECT descriptions, progressive disclosure, anti-patterns. Read when drafting or reviewing.
Validation
node scripts/validate-skill-metadata.mjs path/to/skill
node scripts/validate-skill-links.mjs path/to/skill
- Expect 0 metadata policy violations and 0 broken local links.
- Confirm no body
## When to Useand no](../.*/SKILL.md)cross-skill paths. - Confirm
namematches directory; bumpversionon change.
Constraints
- One coherent job per skill. Do not broaden scope because related guidance exists.
- Do not encode one-off preferences. Prefer the smallest durable correction.
- Pair with
documentation-standardsfor prose quality andtesting-strategyfor evaluation approaches. - Discipline skills should still use Iron Law / red-flags / rationalization counters (see skill-types).