Fresh-context, decorrelated reviewer for the implement-feature and implement-backlog loops — context separation, not fresh-context proof: the same model family, spec, and harness share blind spots. Bash is granted for read/verify commands (test runners may write caches and build output). The invariant is non-authoring…
After implementing, generate a complete reference walkthrough of the changes made — every dimension (what, how, why), anchored in the spec, plan, and diff — as a self-contained interactive HTML page in docs/walkthroughs/.
Orchestrate a whole project (or slice) of GitHub issues into resolution-gated waves of Orca child worktrees — one autonomous worker per ticket — and babysit every PR through CI, the applicable-lens review, and third-party feedback until the human merges. Waves are resolution-gated — merged PRs, corroborated no-change…
Prepare a repository's verification infrastructure for this system — the three-command interface (check / check- / golden), the metric-class gates (stack-agnostic — the class is the requirement, the tool is an instance), the golden harness skeleton, minimum CI, and the ratchet baseline. Brownfield-safe: detect…
Shape work through a relentless interview — interrogate an idea, a transcript, existing code, or an existing spec until shared understanding; or sharpen a task until it's implementable. Works the question frontier in rounds — every currently-askable question at once, numbered, each with a recommended answer — the…
Break a capability spec (or the shaping conversation that produced it, or a parent issue) into tracer-bullet tickets — vertical slices anchored on the spec's pointed stable IDs (typed, never renumbered), each declaring its blocking edges. Quizzes the human on the breakdown, then publishes to a local tickets.md or to…
Write or update the capability spec from an interview — turns a /shape session (or provided notes/transcript) into specs/ / .md on the template. Does not interview back; gaps become open questions (OQ- -###), never guesses. Every BR/AC carries a stable typed ID (BR- -###, AC- -###) issued in continuation; existing IDs…
Use when the reviewer subagent is reviewing a diff that implements work defined by a capability spec or an approved plan (protocol Phase 3). Checks two things: does the diff do what the spec requires, and does the diff do what the approved plan said it would. Catches silent drift between intent and implementation.…
Use when the reviewer subagent is reviewing a diff that touches a domain rule, a calculation, a sensitive numeric value, the audit trail, source-of-rule attribution, stage/responsibility boundaries, or past-period rules. Checks the diff against the system constitution (architecture/constitution.md). This is the…
Use when the reviewer subagent is reviewing a diff for correctness/logic, simplicity/reuse, test quality, or type design — the default reviewer dimension for the implement-feature and implement-backlog loops. Domain-rule, audit-trail, and spec-conformance concerns are NOT here — route those to…
EXPLICIT INVOCATION ONLY — run via /implement-backlog or when the user names this skill. Unattended adapter of the shared implementation protocol: autonomous loop over increment issues (bugfix, tech-debt, rule adjustment, reference-data update proposals, feature-within-scope). New capabilities and large features are…
EXPLICIT INVOCATION ONLY — run via /implement-feature or when the user names this skill. Never auto-trigger on general coding requests. Supervised-local adapter of the shared implementation protocol: code work from existing ratified specs, issues, or backlog items, with the human in the session satisfying every gate.
EXPLICIT INVOCATION ONLY — the orchestrated-worker adapter of the shared implementation protocol. Invoked as the FIRST MESSAGE of an Orca child worker: /implement-orchestrated issue # --mode assisted|autonomous. One ticket, one worktree, one PR. Never auto-trigger; never use for local supervised work.
Reviews implementation plans before any code is written. Use when the reviewer subagent is judging whether a plan's approach/architecture is sound — approving it or sending it back with approach-level concerns. Used by implement-backlog (Phase 2, as the gate that replaces the human) and available to implement-feature…
Review tickets (GitHub issues) as executable contracts before dispatch — self-containedness, criteria pointed at the spec, explicit scope and dependencies, size, test scenarios, risk notes. Report-only, [BLOCKER]/[SHOULD]/[NIT]. Use on a generated batch before the quiz (/spec-to-tickets) and before scheduling waves…