Case study · AI-assisted specification pipeline

A plain-language app idea in. A certified, build-ready spec for AI coding agents out.

PROJECT_WORKBENCH is a single-operator workbench I built with AI coding agents. It audits a client's answers, freezes scope on a human approval, generates one Master PRD where every requirement traces back to something the client said, has it certified by an independent reviewer, and packages handoff files for Claude Code, Codex, Cursor, Lovable and Replit.

PROJECT_WORKBENCH overview: every stage certified, pilot done, final ZIP exported.
The workbench after a complete run of the sample order: both QC gates certified, final package exported, 28 of 50 allowed model calls used.
The sample order · Elm Street Clinic Front Desk (Premium)

One invented clinic, run end to end

A six-role family clinic (patients, receptionists, nurses, clinicians, a billing clerk and a practice manager) wants to replace phone booking, paper intake forms, hand-sent reminders and a no-show notebook. I wrote the order myself; it is a demonstration, not client work. Everything below is the pipeline's own output for it.

34requirements, each with a cited source
47numbered, approved decisions
79pass/fail acceptance checks
7workflow diagrams
4agent handoffs: Claude Code, Codex/Cursor, Lovable, Replit
2independent QC certifications
How it works

Nine stages, one human gate

Each stage is a separate model call with its own structured output, validated on the server. An automated pilot drives the stages within a hard budget of model calls, and pauses, saying why, whenever a client decision or an approval is needed. It never approves anything itself.

01

Intake

The client's answers to 11 questions, stored verbatim and cited downstream as intake.F01 to F11.

02

Intake audit

Turns answers into numbered decisions, assumptions and open questions, and checks them against each other.

03

Certification

Passes only when zero questions remain unanswered.

04 · human

Approval

The one act that freezes scope. Changes after this go through a rebaseline, never a silent edit.

05

Master PRD

One spec. Every requirement lists its approved sources, pass/fail criteria and milestone.

06

Master QC

A reviewer in a fresh context files typed findings; repairs are surgical, then rechecked.

07

Companions

A handoff file per coding agent, derived from the accepted Master.

08

Package QC

A second certification over the whole package.

09

Export

Final ZIP with spec, handoffs, ledgers and diagrams. Drafts are stamped so they can't pass as final.

Traceability, shown not claimed

Follow one requirement from the client's words to the coding agent

The clinic's no-show rule, followed through every artifact the pipeline produced. The same chain exists for all 34 requirements.

The client saidintake.F08
"…a flag after three no-shows in six months is automatic and only a receptionist can book for a flagged patient…"
The audit decidedDEC-014 · Approved
A patient with three no-shows within six months is automatically flagged; only a receptionist can book a further appointment for that patient while flagged.
The Master specifiesREQ-016
The system automatically flags a patient on the third no-show within a rolling six-month window and automatically lifts the flag once fewer than three no-shows remain in that trailing window; while flagged, only a receptionist can create a new booking for that patient.
DEC-014ASM-009BR-12Milestone M6: No-Show & Absence Handling
It is testable3 acceptance checks
  • Given a patient's third no-show falls within the trailing six months, the flag is set without staff action. pass / fail if it requires a manual step
  • Given re-evaluation finds fewer than three no-shows in the trailing six months, the flag is removed automatically. pass / fail if it stays set
  • While flagged, a patient-initiated booking attempt is rejected and a receptionist-initiated booking still succeeds. pass / fail if the patient can self-book while flagged
The agent is toldAGENTS.md
The rolling six-month, three-no-show flag sets and lifts automatically, with no manual override step (DEC-014, ASM-009, BR-12, REQ-016).
It is drawnWorkflow diagram
The patient self-booking workflow lists the flag as a condition and cites REQ-016. See the diagram ↓
The visual pack

Scope at a glance, then every workflow

Scope map. What version 1 builds, what is deferred (each tied to a decision), and what stays out of the product entirely.
Screens by role. Each screen sits under the role the specification names for it, with the requirements behind its actions.

Seven workflow diagrams

Each draws only what the Master states: the steps in order, the conditions listed for that workflow, the failure state, and the requirements it satisfies.

Interactive

The traceability map

Every requirement against its decisions, assumptions and business rules, grouped by milestone. It ships inside the client package as a single HTML file.

sample/diagrams/traceability-map.htmlOpen full screen ↗
The operator's view

The workbench, stage by stage

A read-only assistant sits beside every stage. It can explain why Approve is blocked or what a finding is asking for; it cannot change, run or record anything, and never sees keys.

Measured, with the method

What it costs to run, and what I fixed

Three demonstration orders, one per package, run end to end on the pipeline's own stages (baseline on claude-sonnet-5, 2026-09-18 and 19).

BasicStandardPremium
SubjectDog walker's slotsTheatre box officeClinic front desk
Provider calls212136
of which format repairs448
Provider time42 min42 min70 min
Requirements / flows / screens15 / 6 / 535 / 7 / 634 / 8 / 7
Estimated calls on a clean rerun~14~17~20

I traced every inflated number to a named cause and fixed it in the pipeline rather than working around it:

Basic

The pilot had no repair step after Package QC, so it looped on re-certification. It now plans the repair.

Standard

A reconciliation bug dropped the closure record of a client conflict, so the pause could never clear. Fixed.

Premium

The audit hit its output ceiling. The ceiling was raised.

About $1.86 per completed order on Sonnet-class models at list API rates (measured 2026-09-05). One early order that never converged cost $11.87. The cost driver was QC convergence, not model choice; I fixed it with acceptance rules and repair strategy, not a cheaper model.

Codebase (2026-09-24): ~74,000 lines of TypeScript and ~78,500 lines of tests across 165 test files (vitest and Playwright), 774 commits over about five weeks. The source is private; I'm happy to walk through it live.

The deliverable

What the client receives

The exact final package the pipeline exported for the sample order. Download the ZIP, or read any file on GitHub.

Delivered to the team's tracker

Delivering to Azure DevOps Boards

On 2026-09-28 I loaded the sample order's certified Master into an Azure DevOps Boards project: one Epic for the product, one Feature per milestone, one User Story per requirement. Each story carries its acceptance criteria word for word, and its tags list the REQ id and every approved source it cites.

1Epic
8Features, one per milestone
34User Stories, each under its Feature
79acceptance criteria, in the stories' Acceptance Criteria field
Azure Boards backlog for the sample order: the Epic, milestone Features and requirement stories with their source tags.
Counts verified by querying the project after the load. The traceability tags mean a developer or agent picking up any story can see which client decision it came from. Also exported as a CSV in Azure Boards' import format.