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

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

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

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.

Tip

This is the whole idea in one line: specify together, build apart, review independently. The people who agreed what to build are not the single point of failure who also decides it is done.

The critic is a seat, not an anonymous instance

When a batch is reviewed, the adversarial full-diff pass runs as the QA seat’s review render. The card’s lens and its “pushes back when” list are the critic’s attack angles, and the verdict is recorded under the seat’s name - so the verdict log 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

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

Caution

A seat is never accountable for reviewing a document it wrote. The Product amigo decomposes a ratified PRD into stories and reviews requirements against it - she does not author the PRD she is accountable for. A single-repo project runs with the Product Owner alone; the Product Manager seat appears only once several repos form one product.

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.

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

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.

Note

A panel where every seat ratifies the original proposal is suspicious. If you keep getting unanimous agreement, the panel is rubber-stamping; widen it.

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 before it can reach Done. Done means signed off, by someone who did not write it.

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

• Two-role review & sign-off - the independence gate the Amigos run under.
• Personas - the other cast: who the product is for.
• The specification layer - the documents the team writes and answers for.
• Review and close - where the adversarial pass actually runs.