create-skill

# Create a New Skill Author a SKILL.md file that agentic systems can consume to execute a specific procedure. ## When to Use - Codifying a repeatable procedure that agents should follow - Adding a new capability to the skills library - Converting a guide, runbook, or checklist into agent-consumable format - Standardizing a workflow across projects or teams ## Inputs - **Required**: Task the skill should accomplish - **Required**: Domain classification — one of the domains catalogued in `skills/_registry.yml` (the registry is the authoritative, current list), e.g.: `r-packages`, `jigsawr`, `containerization`, `reporting`, `compliance`, `mcp-integration`, `web-dev`, `git`, `general`, `citations`, `data-serialization`, `review`, `bushcraft`, `esoteric`, `design`, `defensive`, `project-management`, `devops`, `observability`, `mlops`, `workflow-visualization`, `swarm`, `morphic`, `alchemy`, `tcg`, `intellectual-property`, `gardening`, `shiny`, `animal-training`, `mycology`, `prospecting`, `crafting`, `library-science`, `travel`, `relocation`, `a2a-protocol`, `geometry`, `number-theory`, `stochastic-processes`, `theoretical-science`, `diffusion`, `hildegard`, `maintenance`, `blender`, `visualization`, `3d-printing`, `lapidary`, `versioning` - **Required**: Complexity level (basic, intermediate, advanced) - **Optional**: Source material (existing guide, runbook, or working example) - **Optional**: Related skills to cross-reference ## Procedure ### Step 1: Create Directory Each skill lives in its own directory: ```bash mkdir -p skills/<skill-name>/ ``` Naming conventions: - Use lowercase kebab-case: `submit-to-cran`, not `SubmitToCRAN` - Start with a verb: `create-`, `setup-`, `write-`, `deploy-`, `configure-` - Be specific: `create-r-dockerfile` not `create-dockerfile` **Expected:** Directory `skills/<skill-name>/` exists, and the name follows lowercase kebab-case starting with a verb. **On failure:** If the name does not start with a verb, rename the directory. Check for naming conflicts: `ls skills/ | grep <keyword>` to ensure no existing skill has an overlapping name. ### Step 2: Write YAML Frontmatter ```yaml --- name: skill-name-here description: > One to three sentences plus key activation triggers. Must be clear enough for an agent to decide whether to activate this skill from the description alone. Max 1024 characters. Start with a verb. license: MIT allowed-tools: Read Write Edit Bash Grep Glob # optional, experimental metadata: author: Philipp Thoss version: "1.0" domain: general complexity: intermediate language: R | TypeScript | Python | Docker | Rust | multi tags: comma, separated, lowercase, tags --- ``` **Required fields**: `name`, `description` **Optional fields**: `license`, `allowed-tools` (experimental), `metadata`, `compatibility` **Metadata conventions**: - `complexity`: basic (< 5 steps, no edge cases), intermediate (5-10 steps, some judgment), advanced (10+ steps, significant domain knowledge) - `language`: primary language; use `multi` for cross-language skills - `tags`: 3-6 tags for discovery; include the domain name **Expected:** YAML frontmatter parses without errors, `name` matches the directory name, and `description` is under 1024 characters with clear activation triggers. **On failure:** Validate YAML by checking for matching `---` delimiters, proper quoting of version strings (e.g., `"1.0"` not `1.0`), and correct `>` multi-line folding syntax for the description field. ### Step 3: Write the Title and Introduction ```markdown # Skill Title (Imperative Verb Form) One paragraph: what this skill accomplishes and the value it provides. ``` The title should match the `name` but in human-readable form. "Submit to CRAN" not "submit-to-cran". **Expected:** A top-level `#` heading in imperative form followed by a concise paragraph stating what the skill accomplishes. **On failure:** If the title reads as a noun phrase rather than a verb phrase, rewrite it. "Package Submission" becomes "Submit to CRAN." ### Step 4: Write "When to Use" List 3-5 trigger conditions — concrete scenarios where an agent should activate this skill: ```markdown ## When to Use - Starting a new R package from scratch - Converting loose R scripts into a package - Setting up a package skeleton for collaborative development ``` Write from the agent's perspective. These are the conditions the agent checks to decide activation. > **Note**: The most important trigger conditions should also appear in the `description` frontmatter field, since that is read during the discovery phase before the full body is loaded. The `## When to Use` section provides additional detail and context. **Expected:** 3-5 bullet points describing concrete, observable conditions under which an agent should activate this skill. **On failure:** If triggers feel vague ("when something needs to be done"), rewrite from the agent's perspective: what observable state or user request would trigger activation? ### Step 5: Write "Inputs" Separate required from optional. Be specific about types and defaults: ```markdown ## Inputs - **Required**: Package name (lowercase, no special characters except `.`) - **Required**: One-line description of the package purpose - **Optional**: License type (default: MIT) - **Optional**: Whether to initialize renv (default: yes) ``` **Expected:** Inputs section clearly separates required from optional parameters, each with a type hint and default value where applicable. **On failure:** If a parameter's type is ambiguous, add a concrete example in parentheses: "Package name (lowercase, no special characters except `.`)". ### Step 6: Write "Procedure" This is the core of the skill. Each step follows this pattern: ```markdown ### Step N: Action Title Context sentence explaining what this step accomplishes. \```language concrete_code("that the agent can execute") \``` **Expected:** What success looks like. Be specific — file created, output matches pattern, command exits 0. **On failure:** Recovery steps. Don't just say "fix it" — provide the most common failure cause and its resolution. ``` **Writing effective steps**: - Each step should be independently verifiable - Include actual code, not pseudocode - Put the most common path first, edge cases in "On failure" - 5-10 steps is the sweet spot. Under 5 may be too vague; over 12 should be split into multiple skills. - Reference real tools and real commands, not abstract descriptions **Writing for translation**: - Target ~400 lines maximum for English skills. German expands 10-20%, and some CJK translations expand further — a 400-line English source stays under 500 after translation. - Avoid idioms and culturally-specific examples that translate poorly. - Keep prose concise and direct — shorter sentences translate better. **Expected:** Procedure section contains 5-12 numbered steps, each with concrete code, an `**Expected:**` outcome, and an `**On failure:**` recovery action. **On failure:** If a step lacks code, add the actual command or configuration. If Expected/On failure is missing, write it now — every step that can fail needs both. ### Step 7: Write "Validation" A checklist the agent runs after completing the procedure: ```markdown ## Validation - [ ] Criterion 1 (testable, binary pass/fail) - [ ] Criterion 2 - [ ] No errors or warnings in output ``` Each item must be objectively verifiable. "Code is clean" is bad. "`devtools::check()` returns 0 errors" is good. **Expected:** A markdown checklist (`- [ ]`) with 3-8 binary pass/fail criteria that an agent can verify programmatically or by inspection. **On failure:** Replace subjective criteria with measurable ones. "Well-documented" becomes "All exported functions have `@param`, `@return`, and `@examples` roxygen tags." ### Step 8: Write "Common Pitfalls" 3-6 pitfalls with cause and avoidance: ```markdown ## Common Pitfalls - **Pitfall name**: What goes wrong and how to avoid it. Be specific about the symptom and the fix. ``` Draw from real experience. The best pitfalls are ones that waste significant time and are non-obvious. The 3-6 cap holds for the life of the skill: when a later evolution wants a seventh pitfall, [evolve-skill](../evolve-skill/SKILL.md) evicts the pitfall with the lowest rediscovery cost instead of appending past the cap. **Expected:** 3-6 pitfalls, each with a bold name, a description of what goes wrong, and how to avoid it. **On failure:** If pitfalls feel generic ("be careful with X"), make them specific: name the symptom, the cause, and the fix. Draw from actual failure scenarios encountered during development or testing. ### Step 9: Write "Related Skills" Cross-reference 2-5 skills that are commonly used before, after, or alongside this one: ```markdown ## Related Skills - `prerequisite-skill` - must be done before this skill - `follow-up-skill` - commonly done after this skill - `alternative-skill` - alternative approach to the same goal ``` Use the skill `name` field (kebab-case), not the title. **Expected:** 2-5 related skills listed with kebab-case IDs and brief descriptions of the relationship (prerequisite, follow-up, alternative). **On failure:** Verify each referenced skill exists: `ls skills/<skill-name>/SKILL.md`. Remove any references to skills that have been renamed or removed. ### Step 10: Add to Registry Edit `skills/_registry.yml` and add the new skill under the appropriate domain: ```yaml - id: skill-name-here path: skill-name-here/SKILL.md complexity: intermediate language: multi description: One-line description matching the frontmatter ``` Update the `total_skills` count at the top of the registry. **Expected:** New entry appears in `skills/_registry.yml` under the correct domain, and `total_skills` count matches the actual number of skill directories on disk. **On failure:** Count skills on disk with `find skills -name SKILL.md | wc -l` and compare against `total_skills` in the registry. Verify the `id` field matches the directory name exactly. ### Step 11: Add Citations (Optional) If the skill is based on established methodologies, research papers, software packages, or standards, add citation subfiles to the `references/` directory: ```bash mkdir -p skills/<skill-name>/references/ ``` Create two files: - **`references/CITATIONS.bib`** — Machine-readable BibTeX (source of truth) - **`references/CITATIONS.md`** — Human-readable rendered references for GitHub browsing ```bibtex % references/CITATIONS.bib @article{author2024title, author = {Author, First and Other, Second}, title = {Paper Title}, journal = {Journal Name}, year = {2024}, doi = {10.xxxx/xxxxx} } ``` ```markdown <!-- references/CITATIONS.md --> # Citations References underpinning the **skill-name** skill. 1. Author, F., & Other, S. (2024). *Paper Title*. Journal Name. https://doi.org/10.xxxx/xxxxx ``` Citations are optional — add them when provenance tracking matters (academic methods, published standards, regulatory frameworks). **Handling `references/` in translations**: Prose descriptions in `references/EXAMPLES.md` should be translated. `references/CITATIONS.bib` stays in English (BibTeX is language-neutral). Translations may symlink to the English `references/` directory if its content is code-only. **Expected:** Both files exist and `.bib` parses as valid BibTeX. **On failure:** Validate BibTeX syntax with `bibtool -d references/CITATIONS.bib` or an online validator. ### Step 12: Validate Skill Run local validation checks before committing: ```bash # Check line count (must be ≤500) lines=$(wc -l < skills/<skill-name>/SKILL.md) [ "$lines" -le 500 ] && echo "OK ($lines lines)" || echo "FAIL: $lines lines > 500" # Check required frontmatter fields head -20 skills/<skill-name>/SKILL.md | grep -q '^name:' && echo "name: OK" head -20 skills/<skill-name>/SKILL.md | grep -q '^description:' && echo "description: OK" ``` **Expected:** Line count ≤500, all required fields present. That flat 500 is the ceiling this repository enforces on i18n mirrors; the English source itself is held to a DERIVED, stricter ceiling once mirrors exist or will exist (`node scripts/check-skill-line-ceiling.js <skill-name>`, `CONTRIBUTING.md` § local checks, #855) — a scaffolded translation adds provenance frontmatter on top of English's body, so an English file at exactly 500 lines puts a freshly-scaffolded mirror over its own 500-line limit. Run that script, not the flat check above, before treating an English file near 500 lines as safe. **On failure:** If over 500 lines, apply progressive disclosure — extract large code blocks (>15 lines) to `references/EXAMPLES.md`: ```bash mkdir -p skills/<skill-name>/references/ ``` Move extended code examples, full configuration files, and multi-variant examples to `references/EXAMPLES.md`. Add cross-reference in SKILL.md: `See [EXAMPLES.md](references/EXAMPLES.md) for complete configuration examples.` Keep brief inline snippets (3-10 lines) in the main SKILL.md. The CI workflow at `.github/workflows/validate-skills.yml` enforces these limits on all PRs. ### Step 13: Sync Discovery Symlinks > **Scope: the maintainer's machine.** `--fix` also writes the global `~/.claude/skills/` hub and removes stale almanac-owned links there. An external contributor commits the one project-level link by hand instead (`ln -s ../../skills/<skill-name> .claude/skills/<skill-name>`), as `CONTRIBUTING.md` § Adding a skill says; the script's global half runs on the maintainer's side at merge. Run the idempotent sync script so Claude Code discovers the skill as a `/slash-command` at both discovery layers. It reads the registry and ensures every registered skill has its repo-internal relative link and its global absolute link, skipping any that already exist — on this machine, do not hand-roll `ln -s` per skill: ```bash bash scripts/sync-discovery-symlinks.sh --report # preview drift bash scripts/sync-discovery-symlinks.sh --fix # create/repair links ``` **Expected:** `--report` prints `OK: hub in sync`; `ls -la .claude/skills/<skill-name>/SKILL.md` resolves to the skill file. **On failure:** The two links the script creates are `.claude/skills/<skill-name> -> ../../skills/<skill-name>` (relative, project) and `~/.claude/skills/<skill-name> -> <almanac>/skills/<skill-name>` (absolute, global). If discovery still fails, use `readlink -f .claude/skills/<skill-name>` to debug resolution — Claude Code expects a flat structure at `.claude/skills/<name>/SKILL.md`. See [Symlink Architecture](../../guides/symlink-architecture.md). ### Step 14: Scaffold Translations > **Required for all skills.** This step applies to both human authors and AI agents following this procedure. Do not skip — missing translations accumulate into stale backlog. > **Scope: the maintainer's repository, after the English is committed and final.** On an external pull request this step is the maintainer's, run once at merge — a scaffold copies the English bytes at the moment it runs, so one made while the PR is still being revised strands every mirror after the next push (#765 finding 2). A contributor leaves this step out; `CONTRIBUTING.md` § Adding a skill says which steps are theirs. Scaffold translation files for the four translated locales (`de`, `zh-CN`, `ja`, `es`) as soon as the English commit is final: ```bash for locale in de zh-CN ja es; do