weather-cli-demo-3

Performs non-destructive cross-artifact consistency and quality analysis across spec, plan, and tasks. Also supports remediation mode to apply fixes. Use when running /sddp-analyze or when compliance auditing is needed.

Defines preservation, format, and section rules for SDD specification artifacts (spec.md, plan.md, tasks.md, checklists). Use when editing feature-artifact files under specs/<feature-folder>/ to prevent accidental corruption of cross-referenced IDs, priorities, and gating state.

Runs the full feature-delivery SDD pipeline end-to-end without user interaction. When called without arguments, auto-selects the first unchecked epic from specs/project-plan.md. Requires Autopilot enabled in config, a Product Document, and a Technical Context Document. Use when running /sddp-autopilot.

Strategies for auditing specifications and reducing ambiguity. Use when running `/sddp-clarify` or whenever an agent needs to critique a requirement.

Clarify product, technical, and operational specs with targeted questions and write accepted answers into spec.md.

Create/refine project `specs/dod.md` as the canonical Deployment & Operations Document.

Generates requirements quality checklists ('Unit Tests for English') that validate quality, clarity, and completeness in a given domain. Use when running /sddp-checklist or when quality verification of requirements is needed.

Orchestrates decomposition of implementation plans into actionable, dependency-ordered task lists. Use when running /sddp-tasks or when task generation from a plan is needed.

Executes the implementation plan by processing and completing all tasks defined in tasks.md phase-by-phase. Use when running /sddp-implement or when code implementation from a task list is needed.

Standard patterns and practices for code implementation. Use when writing code in the `/sddp-implement` phase to ensure consistency, safety, and maintainability.

Creates implementation plans with technical context, architecture decisions, data models, API contracts, and project instructions alignment checks. Use when designing a technical approach for a feature, choosing technologies, defining data structures, or when resolving NEEDS CLARIFICATION markers in plans.

Orchestrates the implementation planning process — generating plan artifacts, architecture decisions, and design documents from a feature specification. Use when running /sddp-plan or when implementation planning is needed.

Analyzes bootstrap artifacts (PRD, SAD, optionally DOD) and decomposes the product into a prioritized, dependency-ordered sequence of epics — coarse-grained deliverable increments, each intended to be implemented as a standalone pipeline run starting at `/sddp-specify`. Use when running /sddp-projectplan or when project-level epic planning is needed after `/sddp-systemdesign`, optionally after `/sddp-devops`, and before `/sddp-init`.

Centralizes rules for quality checks, consistency analysis, and checklist management. Use when running `/sddp-analyze`, generating or verifying checklists, or defining what constitutes 'Done' for a phase.

Executes Quality Control checks. It evaluates requirements, runs static analysis, executes tests, and feeds bug tasks back into the implementation loop if any check fails.

Guides agents through the Spec-Driven Development (SDD) lifecycle: specification authoring, technical planning, task decomposition, and implementation execution. Use when working on features that follow a structured development process, when creating specs, plans, or tasks, when the user mentions SDD, spec-driven, specification workflow, or when gating rules between phases need enforcement.

Writes product, technical, and operational specifications with prioritized work items, requirement families, and success criteria. Use when creating a spec, writing requirements, defining user stories or objectives, authoring a PRD for a new feature, or when handling NEEDS CLARIFICATION markers in specifications.

Creates a feature specification from a natural language description — capturing WHAT users, systems, or operators need and WHY. Use when starting a new feature, when the user mentions /sddp-specify, specification, or feature requirements.

Create or refine a project-level Software Architecture Document (`specs/sad.md`) as the canonical Technical Context Document.

Decomposes implementation plans into actionable, developer-ready task lists organized by phase and prioritized work item. Use when breaking down a plan into tasks, creating task lists, organizing implementation work into phases, or when generating dependency graphs for parallel execution.