Skip to content
SDLC Studio

The Three Amigos

The “Three Amigos” is a long-standing software practice: before work starts, three viewpoints look at it together - Product (what and why), Engineering (how), and QA (what if it goes wrong). SDLC Studio ships that team as real, named people and wires them into the lifecycle, so the practice happens by default instead of when someone remembers to book the meeting.

Meet the team

Section titled “Meet the team”
Amigo Viewpoint Owns the
Lena - Product What & why PRD
Dani - Engineering How TRD
Sam - QA What if TSD

Each amigo owns one of the three specification documents and reviews every change from that angle - Product for user value and scope, Engineering for feasibility and TRD alignment, QA for testability and TSD alignment.

Do the work, then review the work - never the same instance

Section titled “Do the work, then review the work - never the same instance”

Each amigo has a dual render. It does the work (writes the story, plans the code) and it reviews the work - but never as the same instance on the same unit. A seat never signs off its own homework. Each is consulted as an independent subagent, and their views are synthesised, so a blind spot in one is caught by another.

Grown from your project, not shipped identically

Section titled “Grown from your project, not shipped identically”

Ask for your team and it is generated from your project:

/sdlc-studio persona generate --team

It reads the PRD, the stack and the risk signals, asks the few questions it cannot infer (risk class, compliance regime), and writes named seats whose non-negotiables come from your domain - a payments QA paranoid about idempotency, a games QA about frame budgets, a security seat that vetoes card data outside the vault. The seat that argued for a requirement is the one who refuses to sign off work that misses it. Edit a card and generation treats it as authored - it is never overwritten.

It does not make the model smarter, and SDLC Studio does not claim it does. It makes the review cover the risks this project actually has, instead of a generic role-prompt walking past them.

When they are consulted

Section titled “When they are consulted”

The Amigos are consulted automatically at the ceremonies where a decision is expensive to get wrong - creating an epic, creating a story, planning the code for a story, and fixing a bug. The decomposition commands bake the consult in: refine is engineering-led, triage is QA-led. You can also call them by hand:

/sdlc-studio consult team <artefact>

Controls: --with-personas / --skip-personas, --persona <name> for one voice, and --quick / --thorough for depth.

How this becomes a hard gate

Section titled “How this becomes a hard gate”

The Amigos’ review feeds the two-role review gate, which separates two jobs that must never be the same actor:

  • The adversarial reviewer - an amigo’s review render - always runs, and its pass is recorded as evidence. It is input to the sign-off, never the sign-off itself: the author’s own automation approving its own work is not a review.
  • The reviewer of record - an independent principal (the operator, or a named delegate in a separate trust boundary) - records the sign-off. A delegate drawn from the author’s own session is refused, loudly.

Past a configured point in a project’s life, a unit needs both records - the adversarial evidence and an independent sign-off - before it can reach Done. Done means signed off, by someone who did not write it.

Where to next

Section titled “Where to next”