v3.1.0 — convert to a plugin and add the plan-module skill

[melconcoast]

Releases 3.0.0 and 3.1.0 together as a single v3.1.0 tag. Master is still at 2.0.1, so this carries the plugin conversion and the new skill.

What's in it

The plugin conversion (3.0.0, never tagged on its own) — the repo becomes a Claude Code plugin, the skill is renamed code-idea → scaffold and moves to skills/scaffold/, and docs/roadmap.md becomes docs/development-roadmap.md with a module/sub-module structure that is now always generated. CI gains gates on skill metadata and the tag/plugin.json version match. This is the breaking half — see the 3.0.0 CHANGELOG entry.

plan-module (3.1.0) — the plugin's second skill, and the roadmap's downstream consumer. It reads one ## Module <n> block out of docs/development-roadmap.md and writes docs/guides/feature_<module>_plan.md: 2–4 phases in dependency order, at most 3–4 development tasks each, 1–3 plain-English scenarios per task, and a mandatory Task X.V gate closing every phase. Four-state checkboxes ([ ] [x] [~] [-]), progress counted in closed items and never as a percentage.

The roadmap is the contract between the two skills. **Tasks:** became a pointer rather than a placeholder — not yet planned until plan-module runs, then see docs/guides/… — Phase <n> — and scaffold Step 5 now guards against a re-run resetting a live pointer and orphaning a plan file.

Verification

CI gates checked locally: name matches directory for both skills, single-line descriptions at 860 and 1006 characters (limit 1024), 61 and 119 lines (ceiling ~150), plugin.json at 3.1.0, zero broken markdown links.

Beyond the mechanical checks, 15 behavioral scenarios from examples/test-scenarios.md were run against the installed 3.1.0 plugin in fresh headless sessions — the first time any of them have actually been executed rather than reasoned about:

• S60 / S56 — the trigger boundary. scaffold's four phrases all still fire scaffold; plan-module's four all fire plan-module. The two descriptions compete for the same requests, so this was the main regression risk. Clean.
• S57 / S43 / S64 — anti-triggers. Abstract questions get an explanation and no skill; "build task 3" / "execute the plan" against a repo in flight fire nothing.
• S58 — no roadmap: stops, names scaffold, invents no decomposition of its own.
• S47 / S52 / S59 / S63 / S50 / S53 / S54 — output integrity on a generated plan file: no code or assertions anywhere, roadmap pointers flipped to exactly the planned sub-modules, [0/N Closed] counters with the gate task counted, correct snake_case filename, phases cut on sub-module boundaries, the product.md business rule asserted in its own words.
• S48 — the data-loss path. Re-planning a module in flight preserved every closed item with its annotation and appended to the Progress Log rather than rewriting it.

Known gap (not blocking)

S48 surfaced a spec ambiguity worth a follow-up: when a [-] skipped task's capability is reinstated elsewhere in a re-cut, plan-template.md and SKILL.md don't say whether the original becomes [~] (reframed) or keeps [-] as the historical record. The run chose the latter, which honors the never-un-do-finished-work rule either way — but the spec should pick one, since execute-plan will parse these glyphs.

🤖 Generated with Claude Code