spec-executelisted

# Execute a Spec Orchestrate a planned spec to done. **You delegate; subagents write code.** Your leverage is prompt quality, sibling references, and consistency gates - not hand-writing code. ## Prime directive - consistency The spec is the contract. Two sessions executing the same spec must produce convergent output; the mechanism is both reading the same plan phase + the same skill files + the same sibling files, never orchestrator-authored instructions. Speed and creative variants are bugs. Full doctrine: `spec-orchestration` rule. ## Preconditions (refuse, don't work around) - **No open question stands.** Read the plan's `## Open questions`; one standing question stops the whole run and the refusal names each - `spec-answer` is the path. An ambiguity that can be resolved is not a question; it is unfinished work. - The spec is approved for its mode: `supervised` - plan present, coverage complete; `autonomous` - `status: approved` via `spec-approve`. - Clean tree (`git status --porcelain`); dirty - stop and surface, never sweep foreign work in. ## Phase A - Deep learning (never skip) 1. Read the spec end-to-end (requirements + plan), multiple passes. Read the feature doc it changes. 2. Read the project rules and the profile (branch model, verification commands, PR platform, `execution_mode`). 3. Inventory siblings: for every artefact in the plan, pin the concrete sibling file path. No sibling for an artefact - halt and ask the owner; never improvise a new pattern. 4