plan-modulelisted

Use this skill when the user says things like "plan the next module", "plan module 3", "break this module into phases", "create the execution plan for [module]", or is ready to start building a module the roadmap already defines. Not for creating the roadmap or a project's agent docs — use scaffold. Not for building a module that already has a plan file — use execute-plan. Turns one module of an existing development roadmap into a phase-based execution spec an automated coding agent can build from — `docs/guides/feature_[module]_plan.md`, with 2–4 dependency-ordered phases, at most 3–4 tasks each, plain-English test scenarios under every task, and a mandatory verification gate closing each phase. Reads scope, sub-modules, and dependency order out of `docs/development-roadmap.md` rather than inventing them, and confirms the phase cut before writing.
melconcoast/code-idea · ★ 1 · AI & Automation · score 75

Install: claude install-skill melconcoast/code-idea

# plan-module Turns one module of the development roadmap into the phase-based execution spec a coding agent builds from — the plan file itself, not advice about planning. ## When this runs - The roadmap defines a module and the user is ready to start building it - A module was planned earlier, work has since moved, and the plan needs re-cutting around what changed - Never as a project's first step — `docs/development-roadmap.md` must already exist; if it doesn't, hand off to `scaffold` ## Core philosophy — bake this into every output - **The roadmap is the input contract, not a suggestion.** Scope, sub-modules, dependency order, and every `Out of scope:` line come from the module's own block. Widening scope at plan time is how a roadmap stops meaning anything — if the block is wrong, fix the block first and say so. - **Plan the decided, not the desirable.** A module gated by a `Status: Pending` entry in `docs/decisions.md` gets planned up to that boundary and no further. Never resolve a parked decision by quietly planning past it. - **Every task carries its own proof.** A development task with no scenario beneath it is not a task, it's a wish. Scenarios are plain English — observable behavior a reader can check — never test code. - **No implementation code in the plan.** Not a snippet, not a schema, not a function signature. The plan states what must become true; `execute-plan` decides how. Naming an endpoint, table, or data shape in *Details* is right; writing it out is