← ClaudeAtlas

plan-executorlisted

Execute a staged plan document end to end — compile its recommendation into an acceptance contract, implement each stage, verify every one in a fresh git clone, and on failure freeze the evidence, diagnose it from three independent angles, apply the best admissible fix and re-verify from a clean state, looping until the plan is green or the budget runs out. Use this whenever the user points at a plan, review, report, ADR, design doc or issue and asks to "execute it", "run this plan", "make this happen", "carry out the recommendation", "do §6", "make the acceptance tests pass", or "keep fixing and re-running until it's green" — including when they just paste a path to a document with a staged recommendation and say go. Also use for long unattended runs that must survive usage limits and resume, and for any request to auto-fix failures found while executing a plan rather than stopping at the first red. If no plan document exists yet, produce one first with the architecture-research-report skill, then execute it
nguyenvanphituoc/shapeup-sdlc-plugin · ★ 2 · AI & Automation · score 75
Install: claude install-skill nguyenvanphituoc/shapeup-sdlc-plugin
# Plan executor A plan of this kind — an architecture-research-report with a staged §6, a review with a recommendation, an ADR with a migration sequence — is already most of a machine-executable specification. It has ordered stages, an exit criterion per stage, and usually a section saying what _not_ to do. What it lacks is a runtime that will not let itself be talked out of the exit criteria. That is what this skill adds. ## The one rule everything else serves **Progress is derived by re-running acceptance, never claimed by whoever did the work.** A stage is done because a command exited as the contract said it would, in a clone that has never seen this run's working tree. Not because an agent said so, not because a prior session's notes say so. Everything else here — why the contract is a separate file, why the clean room is a fresh clone, why a fix that edits a test is rejected, why resuming is cheap — follows from that one rule. It is also the rule these plans were written about. Day 1's finding was a repository that read green while a clone of it failed four checks, because the fix lived in an uncommitted working tree. Day 2's was a register that would happily accept a fabricated reduction, because the rule against it was prose. A harness that executes those plans and then reports success on its own say-so has learned nothing from either. ## Phase 0 — Find the plan, or make one You need a document with a staged recommendation. If the user named one, read it whole