Skip to content
SDLC Studiov6

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.

They are not role prompts. Each is a card with goals, a proficiency, a working method, the things they will not trade away - and an honest account of how they fail.

Meet the team

Section titled “Meet the team”
Amigo Viewpoint Brings
Lena Marsh - Product What & why user value, scope discipline, “is this what was actually asked for?”
Dani Okafor - Engineering How feasibility, TRD alignment, blast radius
Sam Eriksson - QA What if testability, TSD alignment, “what breaks?”

The Shadow

Section titled “The Shadow”

Every card carries a mandatory Shadow: how this amigo fails when it is trying hardest to be good. Dani gold-plates. Sam can block on a risk nobody will ever hit. Lena trades depth for reach.

This is not decoration. Off-script, a charter reverts to the base model’s agreeableness, and a reviewer with no named failure mode drifts back into agreeing with you. Writing the failure down is what keeps the pressure-test honest - and it lets you read a review with its bias visible.

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:

  • The work render - craft goals, how they work, non-negotiables - frames the seat when it builds, authors or tests.
  • The review render - lens, pushes back when, Shadow - frames it when it critiques.

The two are always separate instances on one unit. A seat never reviews its own output. Each is consulted as an independent subagent and the views are synthesised, so a blind spot in one is caught by another.

The critic is a seat, not an anonymous instance

Section titled “The critic is a seat, not an anonymous instance”

Each unit’s reviewer is briefed as a seat’s review render: critic.py brief --unit <id> --seat qa hands it the card’s lens and its “pushes back when” list as its attack angles, and the verdict is recorded under the seat’s name - so the verdict ledger reads as Sam’s verdict, not an unattributed thumbs-down. Record a verdict under a reviewer that matches no declared seat and the tool says so.

Accountability: who answers for a document

Section titled “Accountability: who answers for a document”

Two further seats exist, and they are review-only - they do not build:

Seat Accountable for Applies
Product Owner the PRD: that its requirements are complete, current and satisfied by the work. Signs the PRD review leg. every project
Product Manager the PVD: that its product requirements are satisfied and each maps to a child PRD. Signs the PVD review leg. only when a PVD exists

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 rejects 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.

Zero setup still works. With no seats defined the skill falls back to the three shipped amigos, so the independence rules apply from the first commit. Seats are matched on a machine-readable role marker inside the card, never the filename - so a card named after a person still resolves deterministically.

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 lead in: refine is engineering-led (a request is largely a build breakdown), triage is QA-led (is it reproducible, and what is the real defect?).

You can also call them by hand, or talk to them:

/sdlc-studio consult team <artefact>     # the panel, on one artefact
/sdlc-studio consult stakeholders <id>   # the wider cast, with their veto lines
/sdlc-studio chat                        # talk to a seat directly

Controls: --with-personas / --skip-personas, --persona <name> for one voice, and --quick / --thorough for depth. A consult leaves an audit trail on the artefact - a Consulted: line and the panel’s output - so a decision can be read back months later.

How this becomes a hard gate

Section titled “How this becomes a hard gate”

The Amigos’ review is the one independent review every unit gets. Two jobs stay separate, and are never the same actor:

  • The reviewer - an amigo’s review render, in a fresh context that did not write the code - records one verdict per unit with critic.py record, in at most two rounds. A verdict whose reviewer is its author clears nothing: the author’s own automation approving its own work is not a review.
  • The operator reads the one-page sprint report and signs the run once with sprint.py sign. The signature refuses a principal who authored or reviewed a unit in the run.

A unit reaches Done when its criteria pass and its reviewer approves. Done means reviewed by someone who did not write it, in a run signed by someone who did neither.

Independence has a floor and a ceiling. A separate instance of the same model catches self-favouritism, and that is the floor. It still shares that model’s blind spots, so for high-stakes work a cross-model review is the stronger form.

Where to next

Section titled “Where to next”