write-skill
write-skill
Goal
Create or revise short, executable SKILL.md files that agents can follow reliably under context pressure. Each skill should define its outcome, required behavior, main procedure, assumptions, outputs, and failure handling.
Required Behavior
- Keep every skill focused on one reusable capability.
- Include YAML front matter with
nameand a trigger-focuseddescription. - Keep
Goal,Required Behavior, andProcedurein every skill. - Make the first 20-40 lines enough to understand when to use the skill, what it must do, and what it must not do.
- Target 75-150 lines for
SKILL.md; move reference material out of the main path. - Separate mandatory behavior from optional guidance.
- Use
must,never,prefer, andmayconsistently. - Put exceptions next to the rule they modify.
- Do not assume optional tools, files, subagents, project conventions, or other skills exist.
- Include fallback behavior when missing inputs, unavailable tools, or ambiguity are likely.
- Put examples and rationale after the main procedure, or omit them.
More from jssee/agents
slicing
Use when a chosen approach or clear build target needs to become ordered, demo-able slices. Natural follow-up to `shaping`, but also works from any clear description of what to build. Trigger on "break this down", "what's V1", "plan the rollout", "MVP then iterate", "ship incrementally", or work with multiple pieces that need sequencing.
10shaping
Use when working through a fuzzy idea before implementation. Always asks clarification questions first, then produces a requirements table, one or more viable shapes, a fit-check matrix, and a recommendation. Trigger on "not sure which approach", "should we build X or Y", "what's the scope", "tradeoffs", "before we start", or any request where multiple directions are possible.
10commit
Use when committing local changes while preserving clean, reviewable git history.
9simplify
Use when code has been recently written or modified and needs refinement for clarity, consistency, and maintainability before committing
3reducing-entropy
Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion.
3diagnose
Use when a bug, failure, exception, flake, or performance regression needs disciplined root-cause work. Triggers on "diagnose this", "debug this", "why is this broken/slow/throwing/failing", or any report of incorrect runtime behavior.
2