1. What is Specification-Driven Development?
Specification-Driven Development (SDD) is a software engineering methodology where every line of code is preceded by a formal specification. Unlike traditional "code first, document later" approaches, SDD inverts the process: you specify what the software should do, validate those specifications, plan the implementation, and only then write code — with tests written before the implementation.
Think of it as the intersection of Behavior-Driven Development (BDD), Test-Driven Development (TDD), and formal methods — optimized for the era of AI-assisted development.
"Vibe Coding is inspiration, but it's not programming. The real magic happens when creativity meets rigor."
An SDD Framework is a toolset that enforces this methodology. It provides commands, skills, quality gates, and automated checks to ensure that specifications are complete, unambiguous, and verified at every step of the development pipeline.
2. Why SDD Matters in the Age of AI Coding
With the rise of AI coding assistants (Claude Code, Cursor, GitHub Copilot, Gemini), developers can generate code faster than ever. But speed without structure creates a new category of problems:
- Specification debt — code exists without anyone knowing what it should do
- Test gaps — AI generates code but not comprehensive tests
- Security blind spots — AI doesn't automatically audit for OWASP vulnerabilities
- Architecture drift — incremental AI-generated changes that erode system design
- Estimation chaos — no structured way to estimate AI-assisted projects
SDD addresses every one of these problems by making specifications the single source of truth. The code serves the spec, not the other way around.
3. Vibe Coding vs. SDD: The Core Difference
| Aspect | Vibe Coding | SDD |
|---|---|---|
| Starting point | "Let me try this..." | Formal Gherkin specification |
| Tests | Maybe, after coding | Always, before coding (TDD) |
| Quality assurance | Manual review | 6 automated quality gates |
| Security | Afterthought | OWASP audit integrated |
| Estimation | "Probably 2 days" | 4 formal models (FP, COCOMO, AI Poker, Historical) |
| Documentation | README if lucky | Living docs, ADRs, OpenAPI auto-generated |
| Reproducibility | Low | High — specs are the blueprint |
4. The 6-Phase SDD Pipeline
The Don Cheli SDD Framework implements a 6-phase pipeline where each phase has mandatory quality gates. No shortcuts allowed.
Phase 1: Specify
Write formal specifications in Gherkin syntax (Given/When/Then). The framework auto-generates DBML database schemas from your specs. This is the foundation of everything.
Feature: User Authentication
Scenario: Successful login with valid credentials
Given a registered user with email "dev@example.com"
When they submit valid credentials
Then they receive a JWT token
And the token expires in 24 hours
Phase 2: Clarify
The framework's Auto-QA system analyzes your specs and detects ambiguities, missing edge cases, and contradictions. You resolve them before writing a single line of code. This uses Nyquist Validation to ensure specification completeness.
Phase 3: Plan
Generate a technical blueprint with architecture decisions, technology choices, and project constitution validation. The framework's 15 reasoning models (Pre-mortem, 5 Whys, Pareto, Inversion, etc.) help you make better decisions.
Phase 4: Breakdown
Decompose the blueprint into TDD tasks with parallelism markers. Each task follows the RED → GREEN → REFACTOR cycle. The framework identifies which tasks can run in parallel for maximum efficiency.
Phase 5: Implement
Execute the TDD cycle in Docker. Write a failing test (RED), make it pass (GREEN), then refactor. The framework's 7 specialized AI agents (Planner, Architect, Executor, Reviewer, Tester, Documenter, Estimator) assist at each step.
Phase 6: Review
A 7-dimension peer review evaluates: performance, security, architecture, code quality, test coverage, documentation, and spec compliance. Only after passing all dimensions does the code merge.
5. The 3 Iron Laws
The Don Cheli SDD Framework enforces three non-negotiable principles:
- TDD (Test-Driven Development) — All code requires tests. RED → GREEN → REFACTOR. No exceptions. This is not a suggestion; it's an Iron Law enforced at every quality gate.
- Debugging — Root cause first. The framework enforces a structured debugging process: Reproduce → Isolate → Understand → Fix → Verify. No guessing.
- Verification — Evidence before assertions. "Tests pass" always beats "I think it works." Every claim must be backed by automated proof.
6. SDD Frameworks Compared
Here's how the major frameworks in the ecosystem compare:
| Feature | BMAD | GSD | spec-kit | Don Cheli |
|---|---|---|---|---|
| Commands | ~20 | ~80 | ~10 | 72+ |
| Skills | ~15 | ~15 | ~6 | 43 |
| Reasoning models | — | — | — | 15 |
| Quality gates | — | 1 | 4 | 6 |
| Mandatory TDD | — | — | — | Iron Law |
| OWASP Audit | — | — | — | Yes |
| Multilingual | — | — | — | ES/EN/PT |
7. Getting Started with Don Cheli SDD
Install the framework in under a minute:
# Via npx (fastest)
npx don-cheli-sdd init
# Or clone the repo
git clone https://github.com/doncheli/don-cheli-sdd.git
cd don-cheli-sdd && bash scripts/instalar.sh --global
# Initialize in your project
/dc:init --type service --name "my-api"
# Start your first task
/dc:start
The framework supports Claude Code (full 72+ commands), Google Gemini (14 skills, 9 workflows), Cursor IDE (via .cursorrules), and any agent via AGENTS.md.
It's free, open source, and Apache 2.0 licensed. Made in Latin America for the world.
Ready to stop guessing and start engineering?
Join hundreds of developers using Don Cheli SDD to build better software.
Get Started on GitHub →