From sdd
Creates change directory with SPEC.md (type-specific), dynamic phased PLAN.md for features, bugfixes, refactors, epics, and updates INDEX.md using project settings.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sdd:change-creationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a complete change specification package consisting of:
Create a complete change specification package consisting of:
changes/YYYY/MM/DD/<change-name>/SPEC.md with proper frontmatter, type-specific sections, and domain updatesPLAN.md with dynamically generated phases| Context | Responsibility |
|---|---|
| Skills (main context) | All planning, spec creation, domain docs - interactive, needs user input |
| Agents (subagent) | Execution only - non-interactive, implements approved plans |
This skill handles all spec and plan creation. Implementation agents only execute the approved plan.
Domain documentation is specified in SPEC.md during planning, not discovered during implementation:
Implementation simply executes these specifications.
Plans are generated dynamically based on:
sdd/sdd-settings.yaml (delegate to the project-settings skill for the settings schema — it returns the component list with name, type, and type-specific settings)Schema: schemas/input.schema.json
Accepts change metadata (name, type, title, domain), optional workflow context, and content from spec solicitation or external integration.
Schema: schemas/output.schema.json
Returns paths to created SPEC.md and PLAN.md files, and whether the index was updated.
Validate name is a valid directory name:
Validate type is one of: feature, bugfix, refactor, epic
Ensure required parameters are provided:
name, type, title, description, domainYYYY/MM/DDchanges/YYYY/MM/DD/<name>/.claude-plugin/plugin.jsonsdd/sdd-settings.yamlmkdir -p changes/YYYY/MM/DD/<name>/
Create changes/YYYY/MM/DD/<name>/SPEC.md using type-specific template.
---
title: <title>
type: <type>
status: active
domain: <domain>
issue: <issue or "TBD">
created: YYYY-MM-DD
updated: YYYY-MM-DD
sdd_version: <plugin_version>
affected_components:
- <component-1>
- <component-2>
decomposition_id: <uuid> # Only if provided
---
Use the template for the change type. Each template is a complete markdown document to use as the SPEC.md body (after the frontmatter above).
| Type | Template | Notes |
|---|---|---|
feature | templates/spec-feature.md | Thorough, self-sufficient technical spec |
bugfix | templates/spec-bugfix.md | Focused on symptoms, root cause, and fix |
refactor | templates/spec-refactor.md | Current state, proposed design, behavior preservation |
epic | templates/spec-epic.md | Parent spec with child change breakdown |
Epic Directory Structure:
After creating the epic's own SPEC.md and PLAN.md, create child change directories:
changes/YYYY/MM/DD/<epic-name>/
├── SPEC.md
├── PLAN.md
└── changes/
├── <child-change-1>/
│ ├── SPEC.md
│ └── PLAN.md
└── <child-change-2>/
├── SPEC.md
└── PLAN.md
Each child change uses the standard feature spec template with parent_epic: ../SPEC.md in frontmatter.
Create changes/YYYY/MM/DD/<name>/PLAN.md using dynamic phase generation.
sdd/sdd-settings.yamlaffected_components)techpacks.dependencyOrder for the active tech pack to get the topological order of component types. Filter to only affected components while preserving dependency order.techpacks.readManifest and read components.<type>.agent for each affected component type. For standards, invoke techpacks.routeSkills(phase: plan-generation, component_type: <type>).lifecycle.testing.agent and lifecycle.verification.agent from the manifest.---
title: <title> - Implementation Plan
change: <name>
type: <type>
spec: ./SPEC.md
status: draft
created: YYYY-MM-DD
sdd_version: <plugin_version>
---
Use the template for the change type. Each template is a complete markdown document to use as the PLAN.md body (after the frontmatter above).
| Type | Template | Notes |
|---|---|---|
feature | templates/plan-feature.md | Dynamic phases based on affected components |
bugfix | templates/plan-bugfix.md | 4 phases: investigation, fix, test, review |
refactor | templates/plan-refactor.md | 4 phases: preparation, refactor, test, review |
epic | templates/plan-epic.md | Change order and dependency graph |
Add entry to changes/INDEX.md:
## Active Changes section (create if missing)- [<title>](YYYY/MM/DD/<name>/SPEC.md) - <type> - <description>
Note: Links are relative within the changes/ directory.Return:
spec_path: changes/YYYY/MM/DD/<name>/SPEC.md
plan_path: changes/YYYY/MM/DD/<name>/PLAN.md
index_updated: true
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:
Epics group multiple feature-type changes under a single goal. The creation workflow (Steps 1-8 above) handles epic SPEC.md and PLAN.md generation using the epic type templates. This section covers epic-specific tracking, implementation, and failure handling.
Epics are tracked in sdd/workflows/<id>-<name>/workflow.yaml:
items:
- id: 01-user-management
title: User Management
type: epic
status: pending
children:
- id: 01-registration
change_id: user-auth-1
title: Registration
type: feature
status: pending
type: epic and a children arrayFor each child change, in dependency order:
git checkout -b epic/<epic-name>/<change-name>If a child change fails review:
If requirements change mid-epic:
title - Change nametype - feature, bugfix, refactor, or epicstatus - active (after merge)domain - Primary domainissue - Tracking issue reference (required)created - Creation dateupdated - Last update datesdd_version - SDD plugin version (required)active, deprecated, superseded, archivedAlways use Given/When/Then:
Each criterion must be independently testable.
Input:
name: user-authentication
type: feature
title: User Authentication
description: Allow users to sign up, sign in, and manage sessions
domain: Identity
issue: PROJ-123
affected_components: [component-a, component-b, component-c]
glossary_terms:
- term: Session Token
definition: Credential representing an authenticated user session
action: add
domain_definitions:
- file: session.md
description: Session management and token lifecycle
action: create
Output:
spec_path: changes/2026/01/21/user-authentication/SPEC.md
plan_path: changes/2026/01/21/user-authentication/PLAN.md
index_updated: true
Input:
name: fix-session-timeout
type: bugfix
title: Fix Session Timeout
description: Sessions expire prematurely after 5 minutes instead of 30
domain: Identity
issue: BUG-456
root_cause: Token expiry calculation uses seconds instead of minutes
affected_files:
- path/to/affected-file
- path/to/other-file
affected_components: [<component-type>]
Output:
spec_path: changes/2026/01/21/fix-session-timeout/SPEC.md
plan_path: changes/2026/01/21/fix-session-timeout/PLAN.md
index_updated: true
npx claudepluginhub liorcohen/sdd --plugin sddGenerates dynamic phased implementation plans from approved specs for execution coordination, agent assignments, and dependencies in /sdd workflows.
Creates OpenSpec change proposals by analyzing codebase for affected files, dependencies, and risks. Generates tasks and test strategies from proposals. Use for planning features in OpenSpec projects.
Creates specs and phased file-level implementation plans for features, bugs, refactors by researching codebase with search, graph queries, and context files.