sdd-methodology

Spec-driven development provides a repeatable lifecycle with gating rules between sequential phases: Specify, Clarify, Plan, Tasks, Implement, and QC. It structures feature delivery by producing auditable artifacts like specs, plans, contracts, and qc-report.md to ensure alignment and quality across teams.

You implement a phase-gated workflow by enforcing the Specify → Clarify → Plan → Tasks → Implement → QC sequence. The lifecycle requires clear artifact outputs at each phase, using .completed and .qc-passed markers in the specs workspace to gate progression and ensure quality control before moving forward.

You need formal specification and task decomposition when managing software projects requiring strict quality control and scalable feature delivery. This methodology applies to projects where ad-hoc delivery causes alignment issues, using canonical specs like prd and sad to establish governance before implementation.

Yes, spec-driven development scales to larger feature sets by producing auditable artifacts that ensure traceability across teams. It establishes project governance through canonical specs registered in the workspace config, maintaining alignment and quality control throughout the feature delivery lifecycle.

Artifacts generated include specs, plans, tasks, contracts/, checklists/, and qc-report.md. The lifecycle also uses .completed and .qc-passed markers within the specs workspace to enforce gating rules between the Specify, Plan, Implement, and QC phases, ensuring auditable traceability.

You should use a gated methodology instead of ad-hoc feature delivery to ensure alignment and quality across teams. A gated approach enforces a repeatable lifecycle with sequential artifact checks, preventing unverified tasks from passing implementation and ensuring structured project governance from specification to quality control.