Skip to content
SDLC Studio

The specification layer

Before a single story is planned, SDLC Studio writes down what to build, how to build it, and how you will know it works. Three documents, one owned by each member of your team:

Document Answers Owned by (Three Amigos)
PRD - Product Requirements What & why Lena, the Product seat
TRD - Technical Requirements How Dani, the Engineering seat
TSD - Test Strategy What if - how we prove it Sam, the QA seat

These are the biggest levers you can pull. Every epic, story and acceptance criterion downstream is only as good as the three documents it descends from, and each one is a real artefact you can read, edit and version - plain Markdown under sdlc-studio/, not a hidden prompt.

How they stack

Section titled “How they stack”
        PRD  (what & why)      sdlc-studio/prd.md
         │
         ▼
        TRD  (how)             sdlc-studio/trd.md
         │
         ▼
        TSD  (how we prove it) sdlc-studio/tsd.md
         │
         ▼
   Personas → Epics → Stories → Code

The TRD is gated on the PRD (you cannot design a solution to a problem you have not stated), and the TSD sets the coverage targets the whole pipeline is later measured against. The PRD is the richest input persona generate --team reads to grow your project’s team (the generator can also run standalone from a bare repo), and all three feed the epic and story decomposition into sized, testable work.

Create, generate, review

Section titled “Create, generate, review”

Every spec document supports the same modes, and which of the first two you use is decided by whether the code already exists:

  • create - greenfield. An interactive conversation builds the document from scratch. Best when you are starting something new.
  • generate - brownfield. SDLC Studio reads your existing codebase and reverse-engineers the document, marking every inferred claim with a confidence marker - [HIGH] / [MEDIUM] / [LOW] on the PRD, and [INFERRED] on the TRD and TSD.
  • review - re-check a document against the current code and update it, so a spec cannot silently drift from reality.

One product, many repos: the PVD

Section titled “One product, many repos: the PVD”

A single repository never needs more than a PRD - its PRD is the top of the tree. When several repos form one product (shared features, an inter-repo API, coordinated releases), the coordination itself needs an owner. That is the Product Vision Document: the product layer above the PRD that maps each product feature to the repo that owns it, kept honest by a read-only projection into every child repo.

Where to next

Section titled “Where to next”