My process·An agentic SDLC, end to end

From idea to a spec engineering can build.

How I design with agents: every decision written down with its source, every idea tested as working code, and a person at every gate.

The system·What it is made of

Decisions in one place, work run one way, on the product's design system.

What the system is made of Me, giving direction and the final call, above three boxes: Wiki (the why), Factory (the how), Design system (the building blocks). Decisions are cited from the wiki into the Factory, work goes out from the Factory to the design system, and findings flow back from the design system to the wiki. Me Direction and final call Wiki The why Factory The how Design system The building blocks Decisions cited Work goes out Findings flow back

Wiki. Every decision, open question and requirement, each traced to its source.

Factory. My agent workflow: step-by-step plans, automated checks and a separate review pass, with any model in any seat. Today Claude, OpenAI and Gemini.

Design system. Built on the product's own components, so the work fits right in.

The flow·At a glance

From scattered sources to a build-ready spec in five steps.

The flow at a glance On the left, four source boxes stacked: PM requirements, meetings and Slack, live production code, research and docs. They join one shared line, with an arrow into the wiki. Then left to right: wiki, prototype, gap analysis, dev spec, with me signing off between the wiki and the prototype and the rulings between the gap analysis and the dev spec. Below the prototype hangs a dashed side box, user validation: users test the prototype, and what they find returns to it as the next version. Below the dev spec hangs a dashed side box, Dev. A dashed line returns from the dev spec to the wiki, labelled findings back into the wiki. Findings back into the wiki 01 Inputs PM Requirements Meetings · Slack Transcripts, threads Live code What production does Research · docs Google Docs, tickets 02 Wiki Decisions · questions 03 Prototype Coded · versioned 04 Gap analysis PM's spec vs prototype 05 Dev spec Dev coding agent Me Rulings Users Next version User validation Dev

Users validate the coded prototype before anything becomes a spec. Agents write the code and the drafts; I read, decide and sign off at each gate, and every decision is written down with its reason.

Step 01Inputs

Every decision starts from what is already true, the live code first.

The live code

What production does today, read before anything is decided.

A spec that contradicts the codebase is a spec engineering has to argue with. When a requirement says “as the panels work today”, I read the panels in code.

  • Requirements from the PMWhat the phase needs to cover. Not pixels, not interaction rules.
  • Meetings, calls and SlackKept word for word, with the date, before anyone paraphrases them.
  • Docs, tickets, earlier specsEach saved as a named source, never a loose note.

Step 02Into the wiki

Every decision keeps its chain of custody, from the first word to the spec.

  1. 01Immutable source
    raw/scope-calls-2026-10-16.md
    Immutable raw source

    Added 2026-10-16. My words in one working session, quoted verbatim, typos kept.

    Never edited. When a newer source replaces it, it is marked superseded, not changed.

  2. 02One home in the wiki
    wiki/decisions.md
    D-217Decided

    What a phase builds is set by its dev spec, not by how far the prototype got.

    source: raw/scope-calls-2026-10-16.md

    The only place the decision can be edited, with a status and a line back to its source.

  3. 03Copies are stamped
    dev-spec/README.md
    derived from D-217 @2026-10-20

    Each change to the PM's draft carries a note: (ruled: D-217).

    Dev specs, QA lists and briefs are made from the decision, never edited as the truth.

  4. 04Checked every time a source is added
    wiki check
    • The same fact in two homes
    • A copy with no date stamp
    • A link to a decision that does not exist
    • A copy older than its decision

    The first three fail the check. A stale copy is flagged for me to verify.

Agents read these pages before every round, so the next session starts from the same truth as the last one, not from a chat history.

Step 03Prototype

Users test a working prototype before any spec is locked.

  • 01
    Coded, and true to the brandBuilt on the product's own design system, so it looks and feels like the product people already know. Users open a live link and do the real task.
  • 02
    What they find goes back into the prototypeIt becomes the next version, so the prototype used for the spec check already includes it.
  • 03
    Findings are saved like any sourceVerbatim and dated, then folded into the wiki. A finding that repeats can be promoted to a requirement.
  • 04
    Nothing is edited into a frozen versionThe reference stays fixed; the answer lands in the next version, and the earlier reasoning stays a click away.
What decides a change

User evidence and my explanation, written down with the ruling. Feedback is saved like any other source.

Steps 04–05Gap analysis to dev spec

The spec goes to dev, ready for a gap analysis tool and a coding agent.

dev-spec/ · one package per phase
  • README.mdStart here: what the phase builds, what it leaves out, and what each file is for.
  • The PM's documentsEach under its own name, structure and IDs kept, with every ruling applied. A change is marked (ruled: D-217) and listed at the end.
  • qa-scope-list.mdWhat QA should not test, because the prototype runs ahead of the phase.
Dev coding agent

The gap analysis tool and Dev coding agent consume the package directly. No wiki is needed, and every change names its decision.

After the round·Context deepens

Every round adds context, so the system can answer more on its own.

First round

What exactly did the PM ask for?

Answered from an immutable source
  1. Immutable sources
  2. Decisions and open questions
A few rounds in

Why does the filter wait for Apply?

Answered from a decision and its source
  1. Immutable sources
  2. Decisions and open questions
  3. Rulings on phase specs
  4. What users found
Many rounds in

Have we tried this before, and what did users say?

Answered from prior decisions, findings and rulings
  1. Immutable sources
  2. Decisions and open questions
  3. Rulings on phase specs
  4. What users found
  5. Patterns across phases
  6. What was tried, and why it changed

Agents read all of it before every round. The deeper it gets, the more questions the system answers without me.

One real round·A regulated-industry product, this month

Four spec documents in, a dev-ready package out, every difference answered.

  1. Specs arrive

    The PM sends four spec documents and a 22-item decision record for the phase. They go into the wiki as sources before anything is compared.

  2. Line by line

    Each line is checked against the frozen prototype version and the live production code. Most of the spec already matched.

  3. Nine rulings

    Nine places where I ruled differently, each with the PM's stated reason and my explanation. Asked and answered one at a time.

  4. The call

    A call with the PM settled what the phase builds. Six rulings ship now; three stay in the prototype as the direction for a later phase.

  5. Frozen

    The version becomes the phase's reference and stops changing, so QA tests a fixed thing. New ideas go in the next version.

  6. Handed over

    The PM receives the four updated documents, plus a scope section and QA scope list. Because the prototype runs ahead on purpose, these keep the build and testing to this phase.

Every change in that package links to the decision behind it. If engineering asks “why”, the answer is one click away and it was written the day it was made.

Why it matters·And how it keeps improving

Working code with a paper trail, built on the product's own design system.

For the team

Nothing is decided silently. Every spec change links to a ruling, every ruling to a reason, every reason to a source. The PM keeps authoring; I keep every decision traced.

For the product

Design starts from live code and ends as code on the real design system. Accessibility is checked at the gate, not at the end. Review happens on a working thing.

Maintained, round by round

Every round feeds back into the system: a mistake becomes a check, repeated work becomes a skill, a pattern goes into the design system. I maintain it continuously, so each round starts from a better system than the last.

Full case study: From Prompting Agents to a Factory That Learns