Writing Skills
Use when creating or editing a skill in this library — the lean format, progressive disclosure, and how to prove a skill works. For AUTHORING skills, not using them.
Handoff
Use when a session is ending or work is passing to a fresh session or another agent — so the next one resumes without re-deriving goal, state, decisions, and the next step. Skip for a finished, self-contained task that needs no continuation.
Executing Plans
Use when you have a plan directory from writing-plans (a 00-index map plus per-task contract files) and need to execute it to done, gating every task on its Evaluator. Per-task gating, not a concurrency ban: sequential by default, independent tasks can fan out. Skip for a single task — just do it.
Receiving Code Review
ALWAYS invoke when review feedback arrives — from a human or another agent — on code you wrote, before you respond or act on any finding. Verifying each finding against the code first is mandatory; agreeing or editing without checking is the mistake. Push back with evidence when a finding is wrong; refuse performative agreement.
Architecture Decisions
Use when making a significant, hard-to-reverse technical decision — a datastore, sync vs async, a framework, a public contract, a security model — to record it as an ADR before building on it. Skip for easily-reversible choices.
Requesting Code Review
Use when a non-trivial change reaches a done boundary — before calling it complete, committing, merging, or opening a PR, not only when you already want fresh eyes. Skip a trivial mechanical diff (rename, version bump, config one-liner) — self-review instead.
Test Driven Development
ALWAYS invoke before writing implementation code for any feature or bugfix with real logic or behavior — the failing test comes first, and writing code before the test is the mistake. Fires hardest whenever you feel the pull to skip the test \"just this once.\" The ONE exception: throwaway spikes, pure config, or content with no logic.
Zoom Out
Use when you're about to work in a region of the codebase you don't know well — map the relevant modules and their callers in the project's own vocabulary before changing anything. Skip when you already understand the area.
Interview Me
Use whenever a request, plan, or design is unclear or underspecified — in any phase, before you build on it. Answers from the codebase first, asks only what it can't determine. Skip for trivial or already-precise requests.
Coding Standards
Use once per project, or when conventions drift, to set the standards agents and humans follow — domain vocabulary, patterns to use, things to never do. Skip if the project already has clear, followed standards.
Using Task Branches
Use before starting repo edits or implementation, or when work needs isolation from the current checkout - ensure a meaningful task branch, harness workspace, or git worktree exists according to user/project preference. Skip for read-only work or when the current branch/workspace is already dedicated to this task.
Dispatching Parallel Agents
Use when more than one piece of work sits in front of you and they don't touch the same files — separate failing tests, unrelated bugs, parallel research threads. Skip when one task needs another's output (sequence them with executing-plans), or when there's just one thing to do.
Verifying Completion
ALWAYS invoke before claiming work is complete, fixed, passing, or done — and before any commit or PR. Running the actual check and reading its output is mandatory; "should work" without a run is the mistake. Fires whenever you feel the pull to declare success without running anything — and if you can't run the check, say so rather than claim done.
Data Model
Use when designing the data a system stores and how it relates — entities, attributes, relationships, and the invariants that keep it correct. Skip for a feature that adds no persistent state.
Security Audits
Use when a change touches a trust boundary — authentication, authorization, attacker-controlled input, secrets, or data exposure — and needs a security review before it ships. Skip for a change with no security surface.
Feasibility Check
Use before committing to a project or initiative — to decide whether the goal is achievable within the real constraints, and surface the risks that could sink it. Points the riskiest unknowns at a prototype.
Refactor Architecture
Use when an existing codebase has architectural friction — changes touch many files, modules are shallow, seams leak — and you want to improve its structure. Skip for new design (use system-architecture) or a quick local fix.
System Architecture
Use after the requirements are set, when a non-trivial system needs designing before it's built — components, boundaries, data flow, and the seams that keep it testable. Skip for a small feature; its structure lives in the plan.
Release Readiness
Use after a change is merged and before it ships to production — a portable pre-deploy gate for what you can reason about on any platform. Skip for a change that doesn't ship to a running system.
Writing Plans
Use when you have an alignment brief or a clear multi-step task and need an executable plan before implementing — a per-task plan directory each task loads independently. Skip for single-step or trivial work — just do it.
Prototyping
Use when a design or feasibility question is genuinely uncertain and cheaper to answer by building a throwaway than by arguing — a tricky bit of logic, a layout choice, a library's real behaviour. Skip when you already know the answer.
Ui Ux Design
Designs user-facing flows, states, interface hierarchy, visual direction, and evidence-backed alternatives. Use when creating or revising an interface before implementation, especially when visual choices need comparison. Skip for backend-only or already-decided cosmetic edits.
Scope It
Use after the goals are set and before design — to draw a project's boundary: what's in, what's explicitly out, and the smallest cut that still meets the goal. Skip for a single feature; use interview-me.
Using Augments
Use when starting any task or conversation, or whenever you're unsure which skill fits — the router that points you to the one for the current step. Does no work itself. Not for dispatched subagents executing a scoped task — they run the task, not re-orient.
Finishing A Branch
Use when a change's checks are verified green and you're ready to wrap the branch — clean commits, a real PR description, and a merge/keep/discard decision. If done or tested is only asserted, not yet run, verify first (verifying-completion). Skip mid-development — this is the wrap-up.
Spec It
Use when you have a goal or feature and need detailed requirements before design — what it must do, how each is verified, and the assumptions and risks. Captures the WHAT, not the HOW; grill unknowns with interview-me first.
Define Goals
Use at the start of a new project or initiative — before scoping or building — to pin down what success means and its measurable criteria. Skip for a single feature; use interview-me for feature requirements.
Yagni
Use the moment you reach for more than the task needs — a new abstraction, interface, config knob, or dependency, or anything kept \"for later\" — OR when the simple path tempts you to under-deliver: a stub, a TODO, or the smallest diff that patches a symptom while a sibling caller stays broken. Build only what the task needs, and make it run. Distinct from test-driven-development, which proves c…
Post Mortem
Use after a failure escaped to production or was caught late — a regression, outage, data corruption, or a defect found long after it shipped — to find why the process let it through, not just fix the code. Also for an end-of-cycle retrospective on work that went badly. Skip a bug you can simply fix — that is debugging.
Debugging
ALWAYS invoke before proposing or applying ANY fix to a bug, test failure, or unexpected behavior — this is the default, and reaching for a fix without it is the mistake. Includes a flaky/intermittent test (an unexplained bug to root-cause, not a green to trust). Root-cause through a reproduction you can run, never guess-and-patch. The ONE exception: a one-line error whose cause you can see and f…