SDD Planning Skill

Transform specifications into actionable technical plans.

When to Use

• Spec exists but plan doesn't

• Designing system architecture

• Breaking down features into components

• After research is complete

Planning Protocol

Step 1: Understand Requirements

Read spec.md , note functional/non-functional requirements, review research findings.

Step 2: Design Architecture

Identify components, define responsibilities, design interfaces, plan data flow.

Step 3: Select Technology

Evaluate against requirements, consider existing stack, document rationale.

Step 4: Plan Implementation

Break into phases (Setup → Core → Integration → Polish), identify dependencies, estimate effort.

Step 5: Assess Risks

Identify technical risks, plan mitigations, note assumptions.

Output Format

Generate plan.md with:

Technical Plan: [Task ID]

Overview

Architecture (Mermaid diagram)

Components (table: name, responsibility, dependencies)

Technology Stack (with rationale)

API Design

Data Models

Security Considerations

Performance Targets

Implementation Phases (Setup → Core → Integration → Polish)

Risks (probability, impact, mitigation)

Testing Strategy (unit, integration, E2E)

Open Questions

References

• assets/diagram-templates.md — Architecture diagram patterns (Mermaid templates)

• references/estimation-heuristics.md — Task sizing guidelines, common pitfalls, and estimation by task type

• .sdd/templates/decision-matrix.md — When to use Brief vs Full SDD planning

Integration

• Input from: sdd-research skill, sdd-explorer subagent

• Output to: /tasks command, sdd-implementer subagent

• Use the ask question tool for architectural decisions with significant tradeoffs