| name | _template |
| description | TEMPLATE ONLY — not a real skill and never invoked. Copy this directory to .claude/skills/<your-skill-name>/, rename it, set `name` to match the new directory, and rewrite every section against docs/skill-generation-standard.md. Write the real description to the Portability contract: front-load what the skill DOES in the first ~90 characters, keep it ONE strict-YAML-valid line (single-quote it like this one and double internal apostrophes, 'like this'), parsed value under 1024 characters. |
_template (reference skill)
This is a template, not a shipped skill. It lives at .claude/skills/_template/
and is deliberately ignored by scripts/validate-skills.py. Do not invoke it.
To create a skill: copy this directory, rename it, and fill in every section below.
Full rules: docs/skill-generation-standard.md.
Purpose
State, in one paragraph, what the real skill produces and the value it delivers.
Example: "Produces a normalized spreadsheet and summary tab from a messy export."
Use When
- Use when: the user's request matches the concrete trigger the skill is built for.
- Use when: an adjacent-but-in-scope variation of that request appears.
- Do NOT use when: the request looks similar but belongs to another skill or a
plain response — name that case explicitly so the model doesn't over-trigger.
Inputs to Inspect
- The repo files, docs, code, tests, and prior artifacts the real skill must read
before acting. List them concretely so context precedes action.
Workflow
- Gather and validate the inputs the skill needs (see Inputs to Inspect).
- Perform the core transformation, reading
references/ detail files on demand.
- Produce the deliverable exactly as specified in Output Format.
- Run the Validation Checklist before declaring done.
Output Format
Describe the exact deliverable: file path(s) and naming, report structure, or data
schema. Be specific enough that two runs produce consistent shapes.
Validation Checklist
Gotchas
- Keep
SKILL.md under 500 lines; push detail into references/.
- Keep the frontmatter
description trigger-oriented and under 1024 chars.
- Directory name and frontmatter
name must stay identical.
Stop Conditions
- Stop and ask if required input is missing or the request is ambiguous.
- Stop and confirm before any irreversible or destructive action (delete, deploy,
overwrite, spend).
- Before a documentation/project-state append under the standard-§5 approved-write
exception (Exception 1): show the exact target path and exact content, wait for the
explicit content-specific yes, and write only what was approved. A declined,
ambiguous, or changed approval means NO write.
- Every side effect outside Exception 1 remains manual-only
(
disable-model-invocation: true) unless it is an ordinary approved source/test edit
inside a separately classified and separately activated TALI route with every §5
precondition satisfied. Delete or rename; Git mutation; package installation; network,
API, webhook, or MCP access; database write or seeding; deployment, provisioning,
spending, or live-state mutation; protected-surface change; security-control change;
governance change; architecture change; and every other §5 FORBIDDEN UNDER TALI class
remain forbidden and must hand off to the owning policy. A generic approval does not
convert any forbidden operation into a TALI operation. This template activates no route.
Supporting Files
evals/evals.json — required for every real skill; the copy in this template
directory (evals/evals.json) is the canonical starting point.
evals/trigger-evals.json — add when the skill's trigger overlaps another skill.
references/, assets/, scripts/ — add only when they reduce errors (progressive
disclosure). Use "None" here if the skill is self-contained.