felipefontoura/pi-sdd-kit/sdd-plan

SDD Plan

Convert explored ideas into a product or project plan.

Purpose

PLAN is the bridge between open-ended IDEA exploration and feature-level REQUIREMENTS. It is optional for very small work and recommended for medium projects with multiple features, modules, or phases.

Workflow

1. Load the SDD reference.

• Read ../_shared/references/sdd-practical.md.
• Apply the Language Policy: respond and write artifacts in the user's initial chat language while keeping skill instructions and templates in EN-US.
• Read ../_shared/references/templates.md when drafting the artifact.
• Use package-level templates/plan.md as the user-facing template when available.
• Load relevant .ai/steering/*.md files when present, especially product.md, tech-stack.md, conventions.md, and principles.md.
• If .ai/strategy/handoff/strategy-brief.md exists, read it as optional upstream context; use it to reduce rediscovery, but do not require it or bypass plan approval.

1. Gather context.

• Read .ai/sdd/ideas/*.md relevant to the requested project or feature set.
• Read existing .ai/sdd/PLAN.md when updating.
• Inspect .ai/sdd/specs/ if feature specs already exist.
• Briefly inspect project README or product docs when available.
• When a strategy handoff is used, reflect it in plan source/context notes and call out any unresolved readiness gaps.

1. Clarify planning scope.

• Ask one question at a time.
• Cover vision, personas, MVP boundary, feature map, dependencies, constraints, and open decisions.
• Keep this at project/roadmap level; do not design implementation details.

1. Draft the plan.

• Use the Plan Template from ../_shared/references/templates.md.
• Organize features by MoSCoW phases:
• Phase 1 — MVP / Must Have
• Phase 2 — Essentials / Should Have
• Phase 3 — Nice to Have / Could Have
• Include feature IDs such as F01, F02, F03.
• Include dependencies only when they affect sequencing.
• Include Open Decisions for unresolved strategy or scope questions.

1. Review with the user.

• Present the complete draft.
• Ask for explicit approval or requested changes.
• Revise until approved.

1. Save draft and guide next step.

• Save drafts to .ai/sdd/PLAN.md with > Status: Draft and .status as plan:draft when useful for collaboration.
• After explicit approval, update .ai/sdd/PLAN.md to approved and set .status to plan:approved if a project-level .status is used.
• Create .ai/sdd/INDEX.md if useful for tracking feature specs.
• Recommend creating requirements.md for the first Phase 1 feature.

Output

• .ai/sdd/PLAN.md
• Optional .ai/sdd/INDEX.md

Quality Bar

• The plan must make MVP boundaries clear.
• Feature IDs must be specific enough to become spec directories.
• Dependencies must reflect real sequencing constraints, not arbitrary order.
• Open Decisions must capture unresolved ambiguity instead of hiding it.

Critical Rules

• Do not write code in this skill.
• Do not create feature-level requirements unless the user explicitly changes phase.
• Do not over-plan small one-screen work; recommend going directly to PRD when PLAN would be wasteful.
• Do not mark a plan approved without explicit user approval.
• Draft plans may be saved, but they do not authorize feature implementation.
• Do not silently change feature-spec .status values from this skill unless the user explicitly requested a project-level plan status update.