create-plan

Create Plan

Produces a structured implementation plan from a specification or requirements document, organized into phases with milestones, dependencies, effort estimates, and a risk register.

Prerequisites

• Apply the shared SDLC conventions in skills/sdlc/references/shared.md.
• If no argument is provided, locate the feature directory under .sdlc/features/ whose frontmatter issue field references $ISSUE_NUMBER.
• .sdlc/features/N-<slug>/specification.md (must have passed review with findings verdict approved), or a specification/requirements document provided in context or as a file path ($1)
• .sdlc/features/N-<slug>/lifecycle.md (optional, if a lifecycle document was produced): include state machine implementation, invariant enforcement, and retention policy work as deliverables in the plan
• .sdlc/features/N-<slug>/telemetry.md (optional, if a telemetry plan was produced): include analytics instrumentation as deliverables in the plan
• .sdlc/features/N-<slug>/observability.md (optional, if an observability plan was produced): include logging, metrics, tracing, and alerting as deliverables in the plan
• Team size and velocity context (if available)

Steps

1. Read the specification or requirements, and the lifecycle, telemetry, and observability plans if present.
2. Determine the plan structure (see Plan Structure). Scale it to the work first: for effort under roughly five person-days, produce a short unified plan with phases, goals, and deliverables, one effort line, and no split directory, gantt, or effort table.
   • Identify the distinct concerns the work spans from the spec (e.g., database/models, API, CLI, SDK, frontend).
   • Ask the user whether to produce a unified plan (plan.md) or a split plan set (plan/ directory, one file per concern plus an index.md). Use the question tool when available; otherwise ask conversationally and wait for the answer.
   • When the user picks split, confirm the concern list and one-word slugs (lowercase, hyphenated) that will name each plan/<concern>.md file.
   • Under automation ($OUTCOME_YAML set, no interactive user), default to unified and note the choice in the plan. If the spec clearly names multiple independent components and a split is obviously warranted, you may still default to unified; the structure can be split later during review.
3. Identify all units of work and group them into logical phases. For a split plan, group phases within each concern; for a unified plan, group them globally.
4. Define phase goals (milestones) and their success criteria.
5. Map dependencies between phases and external factors as a Mermaid flowchart TD (Phase Dependencies), so parallel tracks and unintended serialization are visible immediately. For a split plan, capture cross-concern dependencies in plan/index.md the same way.
6. Estimate effort for each phase (person-days or story points).
7. Identify risks and mitigations.
8. Record assumptions that the plan depends on but has not verified. Risks in the risk register often encode assumptions (e.g., "the third-party API will be available by Phase 2", "the team will have the required capacity", "the database migration will not require downtime"). For each assumption that carries meaningful risk, promote it via /create-assumption so it is tracked and can be validated before implementation.
9. Propose a timeline if team capacity is known: render it as a Mermaid gantt (one section per phase, or per concern for a split plan) when calendar dates are estimable; otherwise keep a duration-only table. A short plan for small work omits the timeline entirely.
10. Validate best-effort: render each mermaid block with mmdc (or npx -y @mermaid-js/mermaid-cli) when available. A missing tool is skipped; a render failure is a defect to fix before handoff.
11. Write the output:
    • Unified: .sdlc/features/N-<slug>/plan.md.
    • Split: .sdlc/features/N-<slug>/plan/index.md plus one .sdlc/features/N-<slug>/plan/<concern>.md per concern.