write-a-skill
This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.
Write a Skill
Process
- Clarify scope -- ask the user (use AskUserQuestion when available; otherwise present as numbered options):
- "What type of skill?" — Options: "Pure instructions (no scripts)", "Instructions + helper scripts", "Wrapper around CLI tool"
- "Does it need pre-loaded context?" — Options: "Yes — auto-run commands on load (Recommended)", "No — gather context during workflow"
- Explore existing skills --
lsthe skills repo, read similar skills for conventions - Draft -- create
SKILL.md - Review with user -- confirm coverage, ask what's missing
Structure
skill-name/
├── SKILL.md # Required. All instructions live here.
└── scripts/ # Optional. Executable helpers only.
└── scan-secrets.sh
Keep everything in SKILL.md. Only use scripts/ for executable files (.sh, .py) that are called via Bash.
SKILL.md Template
---
name: skill-name
description: One sentence what it does. Use when [triggers]. Don't use when [anti-triggers].
---
# Skill Name
## Workflow
[numbered steps]
## Rules
[hard constraints]
## Error Handling
[if X -- do Y]
Frontmatter Fields
| Field | Required | Notes |
|---|---|---|
name |
yes | kebab-case, matches directory |
description |
yes | Agent's only signal for when to load this skill |
Description Rules
The description is the only thing the agent sees when choosing which skill to load.
- Max 1024 chars
- First sentence: what it does
- Second sentence:
Use when [triggers] - Third sentence (optional):
Don't use when [anti-triggers]
Good: Groups unstaged changes into atomic commits by concern. Use when user says "atomic commits" or wants to split changes before pushing.
Bad: Helps with commits.
Examples
Minimal skill -- pure instructions, fits in ~20 lines:
---
name: grill-me
description: Interview the user relentlessly about a plan. Use when user says "grill me".
---
[instructions...]
Pre-loaded context -- ! prefix auto-runs commands on load:
## Pre-loaded context
- Status: !`git status`
- Diff: !`git diff HEAD`
Avoids wasting a turn fetching context the agent always needs.
Rules
- No time-sensitive info (versions, dates) in skills
- Include error handling for foreseeable failure modes
- Test the skill by invoking it before shipping
Anti-patterns
- Description without triggers:
"Helps with testing."-- useless - Hardcoded versions or dates that go stale
- No error handling for skills that run Bash commands
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40