v3.2.0 — add execute-plan, closing the scaffold → plan → build chain

[melconcoast]

Stacked on #2 — merge that first, and this PR's base will retarget to master.

plan-module leaves a plan file full of [ ] items and nothing closed them. execute-plan is that missing third step, and with it no skill name in this plugin is reserved-but-unbuilt any more.

The skill

It works a plan file in a strict micro-loop: select the first open task, implement only what its Details names, write the test code its plain-English scenarios describe, run it until green, then update the plan file — before looking at the next task. Never a whole phase at once, because a plan file that stops matching the code it describes is worse than no plan file. Each Task X.V gate runs the whole module's suite rather than that phase's tests alone, then stops to ask before the next phase.

Two things it does that weren't in the original spec, both closing loops nothing else could:

• It bootstraps the test runner. In this chain a project starts with no code, so the first module usually has nothing to run and scaffold has left ## Commands reading "not yet established". Setting up a runner that fits the stack the docs already chose, then writing the real commands back, is what makes [x] mean verified on a greenfield project at all.
• It writes module progress back to the roadmap. Sub-modules move to in progress and done as phases close. Nothing else maintained those statuses, so a finished module read planned forever and the next plan-module run would be aimed at work already built.

One deliberate departure from the spec as written

The spec restated the four-state checkbox vocabulary in full. AGENTS.md and CONTRIBUTING.md make plan-template.md its single source — the same rule that keeps plan-module from restating the roadmap format, for the same reason: change it in one place and the other breaks silently, with nothing erroring. So references/progress-updates.md only says how to apply the two vocabularies it depends on, and declares itself the bug if it ever disagrees with either. Same behavior, one source of truth.

Verification

CI gates locally: three skills, names matching directories, descriptions at 857/861/1007 characters (limit 1024), 63/61/119 lines (ceiling ~150), plugin.json at 3.2.0, zero broken links, execute-plan.skill packages cleanly from the existing skills/*/SKILL.md glob with no workflow change.

Behaviorally, against the installed 3.2.0 plugin in fresh headless sessions:

• S65 — all four execute-plan trigger phrases fire it.
• S81 — the regression guard. All four scaffold phrases and all four plan-module phrases still reach the skill they always did. Three descriptions now compete for the same requests, so this was the main risk. 8/8 clean.
• S69 / S67 / S76 — a full micro-loop run against a real fixture: it built working code, wrote one test per scenario, ran them green, closed exactly one task at a time, recounted progress from the file, listed real paths under ## Files Modified, and wrote the sub-module status back to the roadmap.

Two defects the runs caught, both fixed here

Running it beat reasoning about it, twice:

1. Free-text statuses. The first live run wrote done (server-side only — see Sub-Module 2.2) and [x] Done (rebuilt and re-closed 2026-08-22). Both read as reasonable prose; both break exactly the parse a fifth status word would, and execute-plan is the parser they break. templates.md called the vocabulary closed but never said the value is the word alone. Now stated in both owners, with caveats directed to the Progress Log. Re-ran after the fix — every status came back bare.
2. A plan that disagrees with the repository. Fixture G's Phase 1 is marked closed but its code was never written. The two runs resolved that differently — one rebuilt the phase, one reported and stopped. Stopping is right, and it's mandated now rather than luck: building on a false closure is unsafe, and silently repairing it is worse, since reopening a phase the file calls done is the user's decision and rewriting the record erases the evidence it was wrong.

Also specifies a phase's Status: forms in plan-template.md, which only ever wrote down the open one, and corrects the sample roadmap's Sub-Module 3.1 to done — the sample plan closes Phase 1, so it was internally inconsistent before there was a rule to catch it.

🤖 Generated with Claude Code