From sdd
Manages workflow states in sdd/workflows/ via YAML, tracking spec/plan/impl/review phases for session-independent resumption across conversations.
npx claudepluginhub liorcohen/sdd --plugin sddThis skill uses the workspace's default tool permissions.
Manages `sdd/workflows/<id>-<name>/` state - tracking where each item is in the solicitation → review → approval → implementation lifecycle.
Routes SDD change actions to phase-specific skills, orchestrating lifecycle from creation, spec review, planning, implementation, verification, and management with validation checks.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
Share bugs, ideas, or general feedback.
Manages sdd/workflows/<id>-<name>/ state - tracking where each item is in the solicitation → review → approval → implementation lifecycle.
This is process state management, not project task management.
ALL workflow state is persisted in sdd/ files. A new session must be able to resume with ZERO knowledge of what happened before:
Read the files, know the state. This enables aggressive context compaction and allows users to clear sessions freely.
sdd/
├── sdd-settings.yaml
├── archive/
│ ├── external-specs/ # External specs archived here (read-only)
│ │ └── 20260205-1430-feature-spec.md # yyyymmdd-HHmm-lowercased-filename.md
│ ├── revised-specs/ # Specs removed during decomposition revision
│ │ └── 20260205-1430-a1b2c3-user-auth-03-password-reset/
│ │ └── SPEC.md
│ └── workflow-regressions/ # Work archived during phase regression
│ └── 20260205-1430-user-auth-1-impl/
│ ├── changes.patch # Git patch for committed changes
│ ├── stash.patch # Git stash for uncommitted changes
│ ├── src/ # Implementation files
│ └── metadata.yaml # Regression context
└── workflows/ # Multiple concurrent workflows supported
├── a1b2c3-user-auth/ # One workflow (user A, branch feature-x)
│ ├── workflow.yaml # This workflow's state
│ └── drafts/
│ ├── 01-user-management/
│ │ ├── context.md
│ │ ├── 01-api-contracts/
│ │ │ └── context.md
│ │ └── 02-auth-service/
│ │ └── context.md
│ └── 02-notifications/
│ └── context.md
└── x7y8z9-notifications/ # Another workflow (user B, branch feature-y)
├── workflow.yaml
└── drafts/...
The workflow uses four separate status fields for granular tracking:
spec_status: pending → in_progress → ready_for_review → approvedplan_status: pending → in_progress → approvedimpl_status: pending → in_progress → completereview_status: pending → ready_for_review → approvedKey Difference from Previous Design:
The old design had a single status field with immediate spec_approved → plan_review transition. The new design:
spec_status: approved IS a resting state - Phase gating requires ALL specs approved before ANY planning starts| Gate | Condition |
|---|---|
| Start planning | ALL items have spec_status: approved |
| Start implementing | ALL items have plan_status: approved |
| Complete workflow | ALL items have review_status: approved |
| Approve spec | No OPEN questions in Requirements Discovery section |
| Approve spec | No dependencies with spec_status: needs_rereview |
For detailed guidance, read these on-demand:
Schema: schemas/input.schema.json
Accepts operation type and operation-specific parameters for workflow lifecycle management.
Schema: schemas/output.schema.json
Returns workflow ID, current phase, and progress tracking.
Workflow IDs are short, unique identifiers:
a1b2c3, x7y8z9, etc.Change IDs are derived from the workflow name:
<name>-<seq> (e.g., user-auth-1, user-auth-2)name: The workflow's user-chosen nameseq: Sequence number within workflow (1, 2, 3, ...)type: epic and children arraypending until first child startscomplete when all children completechanges/ contains child change foldersdrafts/ to changes/:
context.md in drafts for referencesolicitation-workflow.yamlcomplete:
workflow.yaml items arraysdd/workflows/<id>-<name>/ directory including workflow.yamlchanges/ permanently (that's the source of truth)changes/INDEX.md is updated when items move to changes/ directorysdd/workflows/ - workflow.yaml is the source of truthworkflow_state.ready_for_review() updates changes/INDEX.md with new entry/sdd orchestrator — creates workflows and manages lifecyclespec-solicitation skill — reads context, saves specschange-creation skill — saves plansexternal-spec-integration skill — creates workflows and items from decomposition