sdd-skills

Audit the health of an entire application repository or a selected codebase area using independent specialist reviewers and an evidence-validated synthesis. Use when the user invokes /sdd-code-audit, asks for a comprehensive codebase review beyond one Change, wants an application or subsystem assessed for code quality, architecture, testing, security, performance, reliability, UI/UX, accessibility, operations, or SDD traceability, or wants an interactive improvement plan grounded in current code. This is a read-only point-in-time audit, not the change-local /sdd-review integration gate.

Create, update, or assess Architecture Decision Records for SDD projects. Use when the user invokes /sdd-adr, asks to draft an ADR, asks whether a technical decision needs an ADR, wants to record architecture options and tradeoffs, or when another SDD skill reaches a durable architecture, data, dependency, integration, deployment, security, storage, state-management, or cross-cutting project decision that future work should respect. Keeps ADRs linked to SDD changes, Epics, Stories, implementation evidence, and verification without replacing Epic/Story truth.

Apply or continue an SDD change using a main orchestrator with subagents for non-trivial BDD/TDD implementation, discovery, verification, changed-surface reverse traceability, self-check, and manual UI confirmation. May promote an explicitly selected private Planned Change without separate confirmation; Changes that are not planned stop for planning. Discovers materially relevant skills available in the current runtime, loads and enforces their guidance without assuming a fixed skill catalog, and passes selected guidance into delegated slices. Reads the change proposal, design, and task ledger, updates application code and Epic truth, reconciles implementation and verification evidence, validates subagent claims, and stops for ambiguity or unsafe changes. Use when the user invokes /sdd-apply, asks to apply, implement, continue, review-only, delegate implementation, use available specialist guidance, walk through UI confirmation, or close a SDD change.

Capture, plan, or replan an SDD change. Use when the user invokes /sdd-change --brief to preserve a durable desired outcome without technical planning, /sdd-change --plan to turn a confirmed brief or immediate change request into proposal.md, design.md, and tasks.md, or /sdd-change --replan to revise an active Change after implementation discovers new Requirements, Scenarios, constraints, Epic ownership, or scope concerns. Keeps intent capture separate from just-in-time technical planning while preserving Epic truth, BDD/TDD evidence planning, ADR and optional /sdd-design routing, and implementation-ready task ledgers.

Plan or revise experience-design readiness for a UI-bearing SDD Change. Use `/sdd-design --plan` to converge unresolved flow, responsive, component/state, accessibility, or visual direction before implementation, and `/sdd-design --revise` when implementation, comparison, review, or manual feedback shows that an active Change's accepted experience needs another design pass without changing its accepted behavior. Uses available design and evidence tools without requiring a fixed toolchain, records the approved direction or design delta in existing Change artifacts, and stops before editing application or Storybook source.

Audit a SDD Epic end to end against current implementation reality with subagent delegation, mandatory full reverse traceability, systematic Requirement/Scenario testing, Epic coherence review, missing Story/Requirement/Scenario detection, Story label/reference traceability checks, Change-status and evidence drift detection, and an Epic-local verification report. Use when the user invokes /sdd-epic-verify, asks whether an Epic is still accurate, asks to detect implementation drift across an Epic, asks to test every Story/Requirement/Scenario in an Epic, or wants to know what needs a SDD change, artifact fix, verification pass, or PRD update before continuing.

Explore substantial product, technical, architectural, design, business, workflow, or requirement questions about a space before or during SDD work. Use when the user invokes /sdd-explore or wants a sustained discussion grounded in an idea and its related repositories with a durable private record. Create or resume a living exploration note under the owning idea's planning root, investigate only relevant context, and route mature conclusions toward sdd-prd, sdd-change --brief or --plan, sdd-adr, or another appropriate artifact without implementing application code.

Create and apply a lightweight SDD change in one tracked interactive working session. Use when the user invokes /sdd-interactive or asks for small UI tweaks, minor behavior refinements, polish, narrow bug fixes, or other concrete changes that deserve a durable change record but do not need a full upfront /sdd-change --plan pass. Combines a minimal proposal/design/tasks setup with an immediate /sdd-apply-style loop, including BDD/TDD where practical, Epic/Requirement/Scenario reconciliation, relevant available-skill guidance, verification, manual confirmation tracking, and closeout consistency.

Run a conservative SDD orphan and reverse-traceability audit for an application repo, one Epic, or a changed surface. Use when the user invokes /sdd-orphan-audit, asks to find orphaned tests, unused files, stale functions, dead code candidates, missing Epic references, stale Implemented By or Verified By evidence, files/tests not owned by any Epic, or SDD traceability drift across a project. Starts with current-working-tree and docs/epics evidence, optionally layers stack-specific analyzers when available, writes or prints a report, and never deletes or rewrites code automatically.

Use when the user invokes /sdd-pr or asks to open, manage, review, or steward a pull request for SDD-backed work according to project branch and review policy. Creates a PR through the configured provider when one does not exist, and on later activations checks comments, requested changes, status checks, and review threads; addresses accepted feedback; reconciles post-review changes into Epic truth; preserves review freshness against the current PR head; and asks the user to approve the actual merge only after the loop is clean. Use /sdd-release first for production release handoff preparation and /sdd-pr afterward when that handoff is a PR.

Create, draft, update, review, or reason about private project planning Product Briefs/PRDs and Feature/Capability Briefs for SDD application projects in project planning docs through a lightweight grill-me style product interview. Use when the user invokes /sdd-prd, asks whether a SDD project needs product direction before SDD changes, refines SDD product scope, audience, principles, market/monetization, non-goals, or open questions, or checks drift between PRD direction and SDD changes, Epic directories, embedded Stories, Requirements, Scenarios, implementation, or review results. PRDs are optional for early experiments and expected once a project has momentum beyond experimentation.

Prepare a SDD application release handoff to the project-defined production target. Use when the user invokes /sdd-release, asks to release, promote, cut a release, run release checks, prepare required release communication or version metadata, or open the policy-defined production PR or equivalent handoff. Runs branch-policy and dirty-state preflight, verifies SDD review/readiness and closeout consistency, follows project-local release gates and release-record conventions, commits authorized release metadata, and opens or prepares the configured handoff. Does not merge, deploy, tag, publish, or mutate production state without explicit authorization.

Review a SDD change as the independent local integration gate after /sdd-apply or before closing. Verifies the source-vs-target diff and reverse traceability, proposal, design, task ledger, Epic truth, template adherence, Stories, Requirements, Scenarios, tests, manual confirmation, code quality, security, Idea-side repository and product truth, supporting docs, release communication, branch policy, merge readiness, and closeout consistency. Use when the user invokes /sdd-review, asks to verify a SDD change, run a local PR-style review, prepare integration readiness, address findings, close or finish a change, or perform a policy-defined integration handoff. Use /sdd-release for production-target promotion and release handoff.

Produce a concise read-only re-entry brief for an SDD Space. Use when the user invokes /sdd-space-status or /space-status, says it has been a while since working on an app, asks where work left off, what is active or blocked, which files matter, or what to do next. Wraps the deterministic `sdd status --json` inventory with targeted reading of product context, active Change records, important Epics, review evidence, Git state, and recent local commits.