From sdd
Generates dynamic phased implementation plans from approved specs for execution coordination, agent assignments, and dependencies in /sdd workflows.
npx claudepluginhub liorcohen/sdd --plugin sddThis skill uses the workspace's default tool permissions.
Plans are stored alongside their specs:
Creates change directory with SPEC.md (type-specific), dynamic phased PLAN.md for features, bugfixes, refactors, epics, and updates INDEX.md using project settings.
Generates structured implementation plans from feature descriptions or requirements, grounded in repo patterns and research. Deepens existing plans via interactive sub-agent review.
Generates PLAN.md execution plan from SPEC.md, task directory, or existing plan file; creates phases/*.md, KNOWLEDGE.jsonl, artifacts/, and backups.
Share bugs, ideas, or general feedback.
Plans are stored alongside their specs:
changes/YYYY/MM/DD/<id>-<name>/<NN-change-name>/PLAN.md
This keeps all change documentation (spec + plan) together in one location.
Plans are created as part of the /sdd workflow:
/sdd I want to create a new feature/sdd I want to approve the spec/sdd I want to approve the plan/sdd I want to start implementingPlan creation requires an approved SPEC.md as input — it does not run independently.
Schema: schemas/input.schema.json
Accepts change ID, path to approved SPEC.md, and workflow ID.
Schema: schemas/output.schema.json
Returns path to created PLAN.md and review status.
| File | Purpose | Contains | Does NOT Contain |
|---|---|---|---|
| SPEC.md | What to build and how | Requirements, design, API contracts, implementation details, test cases | Execution order, agent assignments |
| PLAN.md | Execution coordination | Phases, agent assignments, dependencies, expected files, progress tracking | Implementation details, code patterns, specific coding tasks |
Key principle: Because plans focus on execution coordination (not implementation details), the SPEC.md must be comprehensive enough that an implementer can complete each phase by reading only the spec. Plans reference specs; they don't duplicate them.
Acceptable in plans:
Not appropriate in plans:
SPEC.md is a complete technical specification. It must be:
Key sections:
Domain documentation is specified in SPEC.md during planning, not discovered during implementation.
The SPEC.md file includes a ## Domain Updates section that explicitly lists:
specs/domain/glossary.mdspecs/domain/definitions/specs/architecture/The SPEC.md file includes a ## Testing Strategy section that defines:
This approach ensures:
Plans are generated dynamically based on the SPEC.md's Components section.
SPEC.md is the source of truth for required components.
The planning skill:
## Components section from SPEC.mdsdd/sdd-settings.yaml for existing component details (delegate to the project-settings skill for the settings schema — it returns typed component objects with name, type, and type-specific settings like server_type, databases, provides_contracts)If SPEC.md says a component is needed but it's not in sdd-settings.yaml yet, that's expected - the component will be created during implementation.
DO NOT ask tech stack questions during planning. Component discovery already determined what's needed.
## Components sectionsdd/sdd-settings.yaml for details## Components lists new components not yet in sdd-settings.yaml, prepend a "Phase 1: Component Scaffolding" phase and shift subsequent phase numbers. If all components already exist, omit the scaffolding phase. This applies to all change types (feature, refactor).techpacks.dependencyOrder for the active tech pack namespace to get the topological order of component types. Use this order for phase sequencing.techpacks.readManifest and read components.<type>.agent for each affected component type. For standards, invoke techpacks.routeSkills(phase: plan-generation, component_type: <type>) — the skills router returns the relevant standards for each component.lifecycle.testing.agent and lifecycle.verification.agent from the manifest for the testing and review phases.| Test Type | When | Agent |
|---|---|---|
| Unit tests | During implementation (TDD) | Component's assigned agent (from manifest) |
| Integration tests | After all implementation phases | lifecycle.testing.agent from manifest |
| E2E tests | After all implementation phases | lifecycle.testing.agent from manifest |
Plans include sections for tracking implementation progress:
This enables:
Each phase should result in a reviewable PR:
| Metric | Target | Maximum |
|---|---|---|
| Lines changed | < 400 | 800 |
| Files changed | < 15 | 30 |
| Acceptance criteria | < 5 | 8 |
If a phase exceeds limits:
For type: epic changes, delegate to the change-creation skill with type: epic. It handles the full epic lifecycle: directory structure, parent and child SPEC.md/PLAN.md creation, workflow tracking, and implementation sequencing.
---
title: Implementation Plan: [Change Name]
change: [change-name]
type: feature
spec: ./SPEC.md
issue: [PROJ-XXX]
created: YYYY-MM-DD
sdd_version: [X.Y.Z]
---
# Implementation Plan: [Change Name]
## Overview
**Spec:** [link to spec]
**Issue:** [link to issue]
## Affected Components
<!-- Read from SPEC.md ## Components section (source of truth) -->
<!-- May reference sdd-settings.yaml for existing component details -->
- <component-type-a>
- <component-type-b>
- <component-type-c>
## Phases
<!-- Phases are generated dynamically based on affected components -->
<!-- Domain updates are executed from SPEC.md before code phases -->
<!-- INCLUDE Phase 1 ONLY if SPEC.md lists new components not in sdd-settings.yaml. OMIT entirely if all components already exist. -->
### Phase 1: Component Scaffolding (if new components)
**Agent:** Read the agent assigned to the scaffolding-related component type from the manifest via `techpacks.readManifest`. Use the `components.<type>.agent` field.
**Standards:** Invoke `techpacks.routeSkills(phase: project-scaffolding)` to load scaffolding standards.
**Outcome:** New component directories and boilerplate created, `sdd-settings.yaml` updated
**Deliverables:**
- Component directories scaffolded per SPEC.md Components section
- sdd-settings.yaml updated with new component entries
### Phase N: [Component Implementation]
<!-- Repeat for each affected component in dependency order. Read agent and standards from manifest. -->
**Agent:** Read `components.<type>.agent` from the tech pack manifest via `techpacks.readManifest`.
**Component:** `<component-type>`
**Standards:** Invoke `techpacks.routeSkills(phase: implementation, component_type: <type>)` to load relevant standards.
**Outcome:** Component functionality complete per SPEC.md
**Deliverables:**
- Implementation matching spec requirements
- Unit tests passing (if applicable)
### Phase N+1: Integration & E2E Testing
**Agent:** Read `lifecycle.testing.agent` from the manifest.
**Standards:** Invoke `techpacks.routeSkills(phase: testing)`.
**Outcome:** All integration and E2E tests passing
**Deliverables:**
- Test suites passing
### Phase N+2: Review
**Agent:** Read `lifecycle.verification.agent` from the manifest.
**Standards:** Invoke `techpacks.routeSkills(phase: verification)`.
**Outcome:** Implementation verified against SPEC.md and standards
## Dependencies
- [External dependencies or blockers]
## Tests
<!-- Extensive test list - tests define WHAT, not HOW -->
### Unit Tests
- [ ] `test_[behavior_description]`
### Integration Tests
- [ ] `test_[integration_description]`
### E2E Tests
- [ ] `test_[user_flow_description]`
## Risks
| Risk | Mitigation |
|------|------------|
| [Risk] | [How to mitigate] |
---
title: Implementation Plan: [Change Name]
change: [change-name]
type: bugfix
spec: ./SPEC.md
issue: [BUG-XXX]
created: YYYY-MM-DD
sdd_version: [X.Y.Z]
---
# Implementation Plan: [Change Name]
## Overview
**Spec:** [link to spec]
**Issue:** [link to issue]
## Affected Components
<!-- List components where the bug manifests -->
- [component]
## Phases
### Phase 1: Investigation
**Agent:** Read `components.<type>.agent` from the tech pack manifest via `techpacks.readManifest` (based on affected component type).
**Standards:** Invoke `techpacks.routeSkills(phase: implementation, component_type: <type>)`.
**Outcome:** Root cause identified and documented in SPEC.md
**Deliverables:**
- Documented root cause
- Clear reproduction steps
### Phase 2: Implementation
**Agent:** Read `components.<type>.agent` from the tech pack manifest via `techpacks.readManifest`.
**Standards:** Invoke `techpacks.routeSkills(phase: implementation, component_type: <type>)`.
**Outcome:** Bug fixed with regression test per SPEC.md
**Deliverables:**
- Working fix
- Regression test passing
### Phase 3: Integration Testing
**Agent:** Read `lifecycle.testing.agent` from the manifest.
**Standards:** Invoke `techpacks.routeSkills(phase: testing)`.
**Outcome:** All tests passing, no regressions
**Deliverables:**
- All tests passing
### Phase 4: Review
**Agent:** Read `lifecycle.verification.agent` from the manifest.
**Standards:** Invoke `techpacks.routeSkills(phase: verification)`.
**Outcome:** Fix verified against SPEC.md acceptance criteria and standards
## Tests
<!-- Extensive test list - tests define WHAT, not HOW -->
### Regression Tests
- [ ] `test_[bug_does_not_recur]`
### Unit Tests
- [ ] `test_[fixed_behavior]`
## Notes
- Prioritize minimal, focused changes
- Update this plan as investigation reveals more details
---
title: Implementation Plan: [Change Name]
change: [change-name]
type: refactor
spec: ./SPEC.md
issue: [TECH-XXX]
created: YYYY-MM-DD
sdd_version: [X.Y.Z]
---
# Implementation Plan: [Change Name]
## Overview
**Spec:** [link to spec]
**Issue:** [link to issue]
## Affected Components
<!-- List components being refactored -->
- [component]
## Phases
### Phase 1: Preparation
**Agent:** Read `components.<type>.agent` from the tech pack manifest via `techpacks.readManifest` (based on affected component type).
**Standards:** Invoke `techpacks.routeSkills(phase: implementation, component_type: <type>)`.
**Outcome:** Test coverage verified, affected areas documented per SPEC.md
**Deliverables:**
- Test coverage report
- Affected area documentation
### Phase 2: Implementation
**Agent:** Read `components.<type>.agent` from the tech pack manifest via `techpacks.readManifest`.
**Standards:** Invoke `techpacks.routeSkills(phase: implementation, component_type: <type>)`.
**Outcome:** Refactoring complete per SPEC.md following component standards, all tests passing
**Deliverables:**
- Refactored code following component standards
- All existing tests passing
### Phase 3: Integration Testing
**Agent:** Read `lifecycle.testing.agent` from the manifest.
**Standards:** Invoke `techpacks.routeSkills(phase: testing)`.
**Outcome:** No behavior changes, all tests passing
**Deliverables:**
- All tests passing
- No behavior changes verified
### Phase 4: Review
**Agent:** Read `lifecycle.verification.agent` from the manifest.
**Standards:** Invoke `techpacks.routeSkills(phase: verification)`.
**Outcome:** Refactoring goals verified, no regressions, standards compliance confirmed
## Tests
<!-- Extensive test list - tests define WHAT, not HOW -->
<!-- For refactors, existing tests should already cover behavior -->
### Existing Tests (must pass)
- [ ] All unit tests pass before refactor
- [ ] All unit tests pass after refactor
### Performance Tests (if applicable)
- [ ] `test_[performance_not_degraded]`
## Notes
- All tests must pass before and after refactoring
- No functional changes should be introduced
- Update this plan as implementation progresses