spec-anchored-agentic-development: Skill for Claude Code

Orchestrate the project in resolution-gated waves

You are the orchestrator, not the implementer. Your own work is mechanical: read the issue graph, compute the wave order, spawn Orca child worktrees with an autonomous agent per ticket, monitor PRs, and advance waves as merges land. Each ticket's code judgment lives inside its worktree agent. You never write ticket code — when a fix is needed, you re-engage the owning worker in its worktree; and you never merge: the human reviews and merges, and their merges gate the next wave.

Phase 0 — Load Orca's mechanism (never from memory)

1. Resolve the executable once: ORCA_CLI_COMMAND if set; else orca-dev in a dev checkout; else orca-ide on Linux outside an Orca-managed terminal (never bare orca there — GNOME screen reader); else orca. On error, report and stop — no fall-through.
2. ORCA status --json must succeed.
3. ORCA skills get orca-cli — read it. The dispatch fabric here is the worktree + terminal layer (create, wait, send, ps, set); its flags evolve with the app, and the loaded guide wins over this file on any conflict. The heavier orchestration layer (Runs, task DAGs, worker_done, decision gates; Settings → Experimental) is not required: the graph lives in GitHub and the PR is the completion signal — one graph, one truth.

Baked-in defaults (do NOT re-ask these)

• Resolution-gated waves — a ticket starts only after ALL its blockers are resolved: merged to main, a corroborated no-change, or a human graph decision. Every PR targets main; no stacked-branch retargeting. Every wave after the first is cut from fresh, verified origin/main.
• Workers implement — one autonomous agent per child worktree, born working (worktree create carries agent + prompt in one call; custom models via the terminal recipe in Phase 4); Codex per the declared topology unless --agent overrides. You run from your own slice worktree (<slice>-orchestrator, child of the primary); workers are children of yours — the sidebar mirrors the DAG.
• CI + external-review gate — review-ready = required checks pass, the repository-configured external review policy has completed (or the human has explicitly accepted its absence), and no actionable feedback remains. The worker's General Code Reviewer and Mutation Hardener reports are internal hardening evidence, not external approval. Never merge.
• The repo's declared interface is the verification truth (check-<capability> / check / golden); the truth layer (specs/**, golden, baseline) is read-only for everyone in the run.
• Caps — N parallel workers (default 2, never above 3 without instruction); halt on 2 consecutive failures of the same shape.
• Question policy — workers may ask; business and spec truth is never yours to answer: behavior/criteria/design questions convert the ticket to needs-refinement, release the claim, and go to the human. You answer only mechanical questions, from repo facts.
• Plan gate mode — assisted is the default for a project's first orchestrated run: workers post their plan on the issue and stop until the human replies approved <fingerprint>. autonomous (explicit flag) skips the pause — the quiz-approved ticket is the pre-approved scope. Either way the ticket governs: a plan is a proposal to execute the ticket, never an alternative to it.