spec-driven
Spec-Driven Change Workflow (OpenSpec)
A change moves through four authored artifacts, an execution phase, and a closing phase. Each artifact answers a different question, and each builds on the one before it:
proposal.md → specs/**/*.md → design.<side>.md → tasks.<side>.md → apply → archive
WHY WHAT HOW WORK BREAKDOWN EXECUTE RECONCILE & SHIP
The whole point of doing this up front is that decisions get cheaper the earlier you make them. The proposal pins down why and what scope; the specs pin down observable behavior; the design pins down technical approach; the tasks turn all of that into a checklist someone can execute and track. Skipping straight to code loses the contract these documents create with each other — most notably the Capabilities contract between the proposal and the specs. And the lifecycle only closes at archive: until the implemented change is merged and its delta specs are folded into the shipped specs, the source of truth is not yet updated.