deliverBuild a closed design from `docs/design/<slug>/` in one run on one tracker issue: agree a high-level overview of the work, implement it milestone by milestone — each milestone something the user can see and try, not read — stop to bring back every gap, divergence or better idea the design did not se
designThink a feature through with the user before building it, and leave a design folder: what is being built, what was decided and rejected, and why.
explain-prExplains the current branch's pull request in plain language — what it actually does and why, where the changes that matter are, what can be skimmed, and what could go wrong — so the owner can get his bearings before (or instead of) reading the diff. When the PR is one node of a stacked chain, expla
featureUse for a medium feature that spans multiple files or layers and benefits from a spec and plan before implementation. Examples: adding a new domain flow end-to-end, building a multi-step UI wizard, integrating a third-party service, or any work where requirements need to be clarified before coding s
fix-pr-commentsAct on the unresolved review threads on this task's PRs, stacked chains and submodules included: fix what is clear, ask in chat about what needs a choice, verify, reply and resolve.
fixUse when fixing a specific bug, small tweak, lint error, or compilation error. Also use when the user says "fix this", "fix that bug", "make it work", or any variation of wanting a specific issue resolved quickly. Do NOT use for: a full green-the-repo verification sweep (the project's verify skill);
pipelineThe engine behind the dev pipeline entry points (/dev:fix, /dev:task, /dev:feature, /dev:build, /dev:deliver): phases, approval gate, implementer dispatch, plan completion audit, finalization, and the project contracts (`verify`, `git-workflow`) it relies on. Load it when an entry point tells you to
prunePhase 3 of the dev pipeline — a subtractive self-review of the change just made. Removes the helper that duplicates an existing one, the single-caller indirection, the abstraction with no producer, the code the change orphaned, and — after implementation only — the test that carries no signal. It ma
review-and-fixRun /dev:review and /dev:fix-pr-comments in rounds until review calls the branch finished — each run in a subagent, with you relaying only what the owner has to decide.
reviewReview this branch's diff — fix what nobody would argue with, post the rest that survives a refutation pass as inline PR comments.
rightsizeReports where a solution is bigger than its problem. For every new mechanism a design, plan or change brings, it asks what requirement the mechanism buys, where that requirement came from, and whether a pattern borrowed from elsewhere still has its reason here, and it names the simpler version and w
setupConfigure a project for the dev pipeline: write, or check against the contract, its `verify` skill and the owner's language.
taskUse for a well-scoped implementation task: adding an endpoint, creating a component, refactoring a module, wiring up a new service, or any clearly-defined unit of work that benefits from a lightweight plan but doesn't need a full spec. Do NOT use for bug fixes (/dev:fix), medium features needing a s
update-packagesUpdate every package in the repository in verified batches, and surface dependencies that were deprecated, renamed or abandoned.