Now v5 · proudly sponsored by Anthropic · Claude for Open Source

Prove your AI built the right thing.

Imagine your own expert software engineering team, ready to use all the industry best practices - at your fingertips.

That's SDLC Studio: it gives your AI agent a team that plans, builds and independently reviews the work - and proves it's done. Across every AI coding agent.

In its fifth major version · 4,000+ unit tests · benchmarked across three model tiers · it builds itself through its own pipeline

Specs
Executable acceptance criteria
Enforced planning
Independent review
1
SPEC

Define the what and why.

2
CRITERIA

Make requirements verifiable.

  • AC-1 create a project
  • AC-2 is persisted
  • AC-3 bad name rejected
  • AC-4 audit recorded
3
PLAN

Plan the work. Link everything.

Task ATask BTask CTask D
4
REVIEW

Independent review against criteria.

  • AC-1Pass
  • AC-2Pass
  • AC-3Pass
Review ✓ Approved
5
EVIDENCE

Traceable evidence in your repo.

  • Tests
  • Artifacts
  • Logs
  • Links
repo / main
src/project/service.py +62 -2
115 def create_project(name):
116   if not name:
117     raise ValueError("name required")
118   project = Project(name)
119 +  audit.log("project_created")
120   return project
Evidence
tests/test_project_service.py
reports/coverage.xml
logs/test-run.log
docs/traceability.md
〉_ MIT licensed·Runs in your repo

Agent-agnostic - one install, the same discipline

Claude CodeCursorOpenAI CodexGitHub CopilotopencodeGemini CLI
The proven loop, now agentic

Everyone's discovering agentic loops. We've run this one for decades.

The software lifecycle has always been a loop - specify, build, prove, learn, repeat. SDLC Studio didn't invent a new one; it taught AI to run the proven one. Say "Plan the next sprint" and it ranks the backlog by priority or WSJF (cost of delay over story points) into a meaningful increment; "Run the sprint" builds, tests and reviews every story for your approval. And like a real team, it closes with a retrospective and gets better each iteration.

WSJF prioritisationStory pointsSized incrementsDefinition of doneIndependent reviewRetrospectivesLessons learned
sdlc-studio
YouPlan the next sprint
Read 23 open stories, ranked by WSJF (cost of delay / points). Proposed increment: 6 stories, 21 points - one coherent slice.plan ready
YouRun the sprint
US0012 delete a taskbuilt · verified · reviewed ✓
US0013 confirm before deletebuilt · verified · reviewed ✓
US0014 undo a deletebuilt · verified · reviewed ✓
6 / 6 delivered - ready for your sign-off
Retro captured 3 lessons - the next sprint reads them, and gets sharper.
The hard part, answered

The failure modes of AI coding,
each met with a mechanism.

Not a faster engine - the discipline around it. Where other tools align the agent on intent, SDLC Studio also argues back with facts.

Agents ignore the spec

A spec the agent produced and is trusted to honour drifts within days. Here acceptance criteria are executable and get run, and reconcile recomputes status from a census of the files - a claim that does not match reality fails a gate.

Review does not scale

Volume of AI-authored change buries review. The two-role gate makes author-review separation mechanical and pushes an adversarial pass to a fresh context - you ratify evidence, not every line.

One workflow fits nobody

A fixed ceremony is too heavy for a fix, too light for a release. The two-backlog model and sizing let a change flow at the weight it warrants - lite for a small repo, the full gate where it earns its keep.

Nobody can prove it worked

By release, nobody - the model included - can say what "done" meant. Here evidence is a build artefact: the verify report, the review record, the mutation ledger. The proof outlives the sprint.

No other spec-driven tool ships this

It's not just a tool. It's a team.

SDLC Studio grows a project-specific engineering team from your PRD, stack and risk - and they both build the work and review it. The teammate who reviews a change is never the one who wrote it. Your AI stops marking its own homework.

L

Lena

Product

Guards the why. Won't let a story ship that doesn't serve the goal it was written for.

D

Dani

Engineering

Builds it. Test-first and ledger-first - won't ship a path that isn't proven.

S

Sam

QA

Proves it. Turns every acceptance criterion into a test that actually runs.

I

Imran

Security

Vetoes card data outside the vault.

+ grown from your PCI scope

Out of the box: Dani, Sam and Lena - the Three Amigos. Run persona generate --team and it writes named seats whose non-negotiables come from your domain: a payments QA paranoid about idempotency, a games QA about frame budgets. Edit a card and it's yours - generation never overwrites it. Meet the team →

And the other cast - who the product is for: Alan Cooper-style personas (primary, secondary, negative) plus stakeholder cards with veto lines, modelling the people who use it now and the ones who will. Personas →

Three documents, one owner each

What, how, and how you'll know.

Before a line is planned, the team writes down the three things that decide whether the work is right. Each is a real, editable Markdown file - and each is owned by one of the Three Amigos.

PRD · what & why

Lena, Product. The product requirements: the features, who they serve, the non-negotiables. Authored with you, or reverse-engineered from existing code.

PRD →

TRD · how

Dani, Engineering. The technical design: architecture, stack with real rationale, API and data models, ADRs - plus an architecture assessment on brownfield.

TRD →

TSD · how we prove it

Sam, QA. The test strategy: coverage targets, test levels and the quality gates that block a build - the bar the whole pipeline is measured against.

TSD →

The specification layer is the biggest lever you can pull. How the three stack →

The five stages

Spec → criteria → plan → review → evidence.

The discipline the tools hold the agent to, at every step.

01

Spec

A PRD, epics and stories - authored with you, or extracted from existing code and checked against its tests.

02

Criteria

Every story carries Given/When/Then criteria with executable Verify: lines.

03

Plan

A request becomes sized work only via refine; a sprint is gated before a line of code is written.

04

Review

An independent reviewer - never the author - signs off. A self-review cannot clear the gate.

05

Evidence

Criteria are run, drift is reconciled, tests are mutation-checked. Proven, not asserted.

Done is a fact, not a claim

You cannot just write
Status: Done

A story reaches Done only when its executable acceptance criteria pass and an independent reviewer signs it off. The tools recompute status from the files, so a hand-edited status is caught by conformance.

Executable acceptance criteria →

verify_ac run --id US0433
# the story's Verify: lines are executed
[APL] US0433: ac=3 pass=3 fail=0 manual=0

# and the Done gate reads the report
transition --id US0433 --status Done
   executable criteria pass
   independent sign-off recorded
  US0433 → Done
Where other tools give up

A new idea, or a 20-year-old codebase.
It meets your code where it is.

Most vibe-coding and spec-driven tools assume a blank slate - and fall apart on the code you already have. SDLC Studio adopts it: it reads your existing codebase, extracts a testable specification, and validates it against your real tests before it changes a line.

+

New project - greenfield

An interview turns your idea into a PRD, epics and stories - the spec written with you, before any code exists.

Existing code - brownfield

prd generate reads your codebase and extracts a testable spec; SDLC Studio then writes tests from it and runs them against your real code (code verify) - the spec is trusted only once they pass. The discipline arrives without a rewrite.

One product, many repos

A centralised vision,
across every repository.

A product is rarely one repo - a web app, an API, a mobile backend, a shared library. The Product Vision Document sits above the PRDs: one writable master that maps every product feature to the repo that owns it, projected read-only into each child repo and kept honest by a drift check. Coordinate a whole product without the vision rotting in a handover doc.

The Product Vision Document →

sdlc-studio/product/pvd.md
# one master, mapping features to the repos that own them
PF0007 Single sign-on   → auth-service   (PRD §3)
PF0011 Task sync        → taskflow-api   (CR0042)
PF0014 Offline mode     → taskflow-mobile (RFC0009)

# projected read-only into every child repo
pvd sync    3 repos
pvd drift   no projection is stale
The difference, in one glance

Three ways to build with AI.
Only one proves it.

Vibe coding is fast and blind. Spec-driven tools plan, then trust the agent to honour it. SDLC Studio plans, estimates, builds, reviews independently and proves - then learns from it.

PracticeVibe codingprompt & hopeSpec-driven toolsplan, then trustSDLC Studioplan, prove, learn
A written specification
Adopts existing code - spec extracted & validated against its testsno test-validated extraction
Planning enforced before any code
Acceptance criteria that run, not just prose~prose only
Estimation & sizing - story points + cost forecast
Velocity tracked, forecasts the next sprint
Independent review - the author is never the reviewer
Evidence kept as a build artefact
Status recomputed from the files - no drift
Retrospective + lessons - gets better each sprint
Works across every AI coding agent~no discipline~often one tool

See the full comparison →

6 agents
one install, the same discipline
Executable
"done" is a test that runs, not a claim
0 self-reviews
clear the Done gate

Make what your AI builds provable.

One line to install. Then say what you want - the discipline holds.

$ curl -fsSL https://raw.githubusercontent.com/DarrenBenson/sdlc-studio/main/install.sh | bash

Prefer to read it first? Inspect the script or pin a checksummed release →