sdd

Plugin sdd from marketplace sdd-commons in jangid/sdd-commons. Commands read from the repo's manifest — 1 month ago.

Skills (10)

• implement

  Executes implementation from an approved plan and design specs. Works through tasks in order, uses TDD inner loop, detects stuck states, and executes spike tasks. Triggers replan when assumptions break. Use after the implementation plan is approved. Do not use without an approved plan — run plan fir

• migrate

  Migrates SDD artifact structures between versions (v1→v2→v3→v4). Handles research directory restructuring, requirements splitting with ID remapping, plan archival, plan vocabulary rename, v3 convention adoption, and the v3→v4 copy-verify-flip-cleanup to the per-workstream `docs/ws/<id>/` layout. Use

• orchestrate

  Driver skill that runs the nine SDD phase skills as a single-operator orchestration loop with per-stage external review. Drives DISCUSS → KICKOFF → LOOP → DONE: brainstorm an idea to shared understanding, write a research kickoff, then for each stage dispatch an isolated pipeline subagent and an iso

• plan

  Reads approved design specs from docs/spec/ and creates a concrete implementation plan with ordered tasks, dependencies, and milestones. Tasks are typed (implement, spike, verify). Plan includes replan triggers. Use after specs are approved and before writing code. Skip while specs are unapproved, o

• replan

  Structured replanning when assumptions break during implementation. Triggered by stuck detection, spike findings that invalidate the plan, verification failures, or user-requested scope changes. Reads current state, identifies what changed, and produces a revised plan. Use when the current plan is n

• requirements

  Guides requirements gathering for a new project or feature using Spec-Driven Development (SDD). Produces structured requirements in docs/requirements/ (split by domain) through iterative Q&A with the user. Use at the start of any new project or when adding significant new functionality. Can referenc

• research

  Time-boxed exploration to reduce uncertainty before committing to requirements or design. Produces structured findings in docs/research/RS-NNN-{topic}/. Use when facing unfamiliar APIs, unknown libraries, architectural unknowns, or feasibility questions. Skip when the domain is well-understood.

• review

  Structured external review at SDD phase boundaries — runs in a separate session from the working session to catch coherence gaps, scope omissions, and readability issues that in-session verification layers miss. Produces an inline verdict with tiered findings. Use at phase transitions, especially re

• specs

  Reads approved requirements from docs/requirements/index.md and category files in docs/requirements/{category}/*.md, then produces feature design specs in docs/spec/. Each spec defines contracts, interfaces, and verification criteria — not implementation code. Use after requirements are approved and

• verify

  Holistic validation after implementation — goes beyond "tests pass" to verify quality gates, acceptance criteria, user-perspective behavior, and regressions. Produces docs/verification.md. Use after all plan tasks are complete. Skip while tasks remain incomplete; not a substitute for per-task testin

Subagents (3)

• chunk-verifier

  Independent read-only second executor of the SDD chunk-close layer — re-runs Check 1 (spec/implementation type alignment) and Check 3 (test coverage per spec) for one plan chunk, runs the project quality gates, and closes with a CHUNK_VERDICT token. Use when an implement dispatch has returned and it

• red-team

  Adversarial read-only executor that attacks the weakest acceptance criteria of a verified cycle — constructs inputs or commands that violate them and closes with a RED_VERDICT token, counting a break only when it is reproducible. Use when the SDD verify pipeline has returned COMPLETE at the verify s

• reviewer

  Out-of-session external reviewer for an SDD artifact at a phase boundary — reads the deliverable and its upstream input cold, reports tiered findings, and closes with a VERDICT token. Use when an artifact at a stage gate needs review from a context that never saw it being written.