Core Philosophy & Experimental Goals
Relevant source files
The following files were used as context for generating this wiki page:Spec-Driven Development (SDD) is a methodology that inverts the traditional software development power structure. Instead of specifications being subordinate to code, SDD makes specifications the primary, executable artifact that directly generates working implementations. The goal is to allow organizations to focus on product scenarios rather than writing undifferentiated code. This approach eliminates the gap between specification and implementation by making the specification the central source of truth, with code being its continuously regenerated expression.
This philosophy is built on the idea of "intent-driven development," where the development team's intent is expressed in natural language and then transformed into a structured, unambiguous specification. This process relies heavily on advanced AI model capabilities for interpretation and generation, guided by a structured, multi-step refinement process rather than one-shot code generation. The entire workflow is organized around evolving specifications to maintain and debug software.
Sources: README.md:13-15, 38-45, spec-driven.md:3-19
Core Philosophy
The core philosophy of Spec-Driven Development is founded on four key pillars that guide the entire process from ideation to implementation.
| Pillar | Description |
|---|---|
| Intent-Driven Development | Specifications define the "what" and "why" before the "how." The focus is on user needs and business value, captured in natural language. |
| Rich Specification Creation | Guardrails and organizational principles are used to create precise, complete, and unambiguous specifications that are rich enough to be executable. |
| Multi-step Refinement | The process avoids one-shot code generation from prompts, instead favoring an iterative dialogue with AI to clarify requirements, identify edge cases, and refine plans. |
| Heavy Reliance on AI | The methodology leverages advanced AI capabilities to understand complex specifications, generate implementation plans, and produce code. |
Sources: README.md:41-45, spec-driven.md:18, 28-31
This philosophy is enacted through a structured workflow, often initiated by a series of commands.
The diagram below illustrates the high-level flow of the Spec-Driven Development process.
The Constitutional Foundation
At the heart of SDD is a project constitution.md, a set of immutable principles that govern how specifications are translated into code. This constitution ensures architectural discipline, consistency, and quality across all generated implementations.
Key principles from the constitution include:
- Library-First: Every feature must start as a standalone, testable library.
- CLI Interface: Every library must expose its functionality via a command-line interface for observability and testability.
- Test-First (Non-negotiable): A strict Red-Green-Refactor TDD cycle is mandatory. Tests must be written, approved, and confirmed to fail before any implementation code is written.
- Integration Testing: Prioritizes testing with real dependencies (e.g., actual databases) over mocks.
- Simplicity: Enforces minimal project structures and direct use of frameworks to avoid over-engineering.
Sources: memory/constitution.md, spec-driven.md:239-290
The implementation plan enforces these principles through a series of gates that must be passed before and after the design phase.
This diagram shows how the constitution acts as a gatekeeper during the planning phase.
Development Phases
The SDD methodology is designed to support the full lifecycle of software, from initial creation to long-term maintenance, categorized into three distinct phases.
| Phase | Focus | Key Activities |
|---|---|---|
| 0-to-1 Development ("Greenfield") | Generate from scratch |
|
| Creative Exploration | Parallel implementations |
|
| Iterative Enhancement ("Brownfield") | Brownfield modernization |
|
Sources: README.md:47-59
Experimental Goals
The project's research and experimentation are focused on validating the core hypotheses of Spec-Driven Development across several key areas.
Technology Independence
A primary goal is to prove that SDD is a process independent of any specific technology, programming language, or framework. The aim is to create applications using diverse technology stacks from the same set of specifications.
Sources: README.md:63-65
Enterprise Constraints
This goal focuses on demonstrating that SDD can be used for mission-critical application development by incorporating real-world organizational constraints. This includes adhering to specific cloud providers, mandated tech stacks, internal engineering practices, enterprise design systems, and compliance requirements.
Sources: README.md:67-71
User-centric Development
The project aims to support building applications tailored to different user cohorts and preferences. This also includes accommodating various developer approaches, from "vibe-coding" to rigorous AI-native development workflows.
Sources: README.md:73-75
Creative & Iterative Processes
A key experimental goal is to validate the concept of "parallel implementation exploration," where multiple, diverse implementation approaches can be generated from a single specification. This allows for what-if/simulation experiments to explore different solutions for a business need. The project also aims to provide robust workflows for iterative feature development, upgrades, and system modernization.
The diagram below visualizes the concept of parallel implementation exploration.
Summary
The core philosophy of spec-kit is to elevate specifications to be the primary, executable source of truth in software development, a practice termed Spec-Driven Development. This is achieved through intent-driven design, multi-step AI-powered refinement, and strict adherence to an architectural constitution. The project's experimental goals aim to prove this methodology's effectiveness across different technologies, within enterprise constraints, and for both creative exploration and iterative enhancement, ultimately transforming how software is built and maintained.
Sources: README.md:13-15, 38-45, spec-driven.md:3-26