commitGroup pending changes into granular commits with structured what/why bodies and metadata trailers, sync drifted docs, capture durable decisions and contracts into the project ledger, and push by default (say "commit only" to skip the push). Use when the user asks to commit, or signals implementation
reflectConsolidate the run journal that scope, scope-review, build, ship, and their quick variants write at the end of every run into cited claims about how the skills themselves behaved, rank the recurring friction threads across repositories, and hand off one chosen thread as a scope brief with an eval c
scope-quickTurn a ship review's findings, or a small request, into minimal change sets in .dev/{plan-name}/spec.md with no interview, no argued decisions, and no subagents, so build can start at once. Use when the user asks for a quick scope, wants review findings fixed without a full scope run, or has a small
scope-reviewReview and auto-refine a settled spec before build starts - a fresh-context agent panel checks the plan against the actual repo for infeasible change sets, missing failure paths, semantic contradictions, and untestable scenarios, then verified findings are applied to spec.md (and, where they touch s
scopeSpec a change by interviewing for the real problem, arguing every design decision against alternatives, and writing a self-contained spec with a change plan at .dev/{plan-name}/spec.md. Use to plan work before implementation, to turn accepted review findings into new change sets, or to audit the dec
ship-quickRe-ship a small change with one validation run, one reviewer that checks the previous review's findings are fixed, and a pull request update followed to green, with no gauntlet, no lens panel, and no remediation loop. Use when the user asks for a quick ship, or wants fixes for an earlier ship review
shipRun the quality pass that ships a change in three phases - phase 1 is a deterministic harden gauntlet (the repo's own static analysis, security scan, dead code, duplication, dependency rules, coverage-weighted complexity, test flakiness, mutation testing) that loops fresh-context fix agents until ev
to-pitchPackage a completed change - its spec, implementation notes, and verification evidence - into a local or shareable buy-in document. Use once implementation is done and the change needs buy-in or visibility beyond the author, not for trivial one-line fixes.
to-quizRender a context/intuition/what-was-done document with a graded comprehension quiz on finished work. Use when the user wants a local or shareable comprehension check before a change merges.
yoloTake one task from request to an open pull request in a single unattended run - the scope, build, and ship stages run back to back in this session with every quality loop intact, and every question those stages would put to the user is answered by their own recommendation and recorded for the PR rev