dev_team_roleplay v1.0.0

name: dev_team_roleplay description: Run a structured multi-role review session where PM, Architect, Developer, and QA personas debate the same proposal in timed rounds, with role cards, conflict rules, and a captured decision log. Use when a plan, design, or architecture choice needs real pushback from multiple angles, when one viewpoint keeps dominating reviews, or when you want a repeatable adversarial review without booking a room.

Dev Team Roleplay

Purpose

One agent asked "is this a good plan?" gives you polite optimism. One prompt wearing four hats gives you polite theater. This skill is a facilitation method: persistent dev-team roles that hold their positions across structured rounds, with written conflict rules and a decision log at the end. The roles are allowed to fight. That is the point. It descends from two established review traditions: Edward de Bono's Six Thinking Hats (1985) for the structured thinking sequence and dedicated process-control role, and Michael Fagan's software inspection (IBM, 1976) for role discipline, the author-may-clarify-but-not-defend rule, and detection-before-resolution.

Use it for: architecture choices, product plans, API designs, launch go/no-go, vendor picks, any decision where you suspect your own enthusiasm is doing the reviewing.

Do not use it for: factual questions, creative drafts that need craft feedback, decisions already made, or topics with no real downside.

Workflow

1. Frame the proposal

Write a one-page brief before any role opens its mouth:

• What is being decided, in one sentence.
• The proposal in under 200 words.
• Constraints (budget, time, team, technical).
• Who actually decides and by when.

No brief, no session. Roles need a target, not a vibe.

2. Cast the roles

Four debaters, one facilitator. The facilitator is the agent running the session and never argues a position. Roles (full cards in references/role-cards.md):

• PM owns user value and business risk. Asks "who is this for and what happens if we are wrong about them?"
• Architect owns the shape of the system five years out. Asks "what does this choice lock in?"
• Developer owns the build. Asks "what breaks at 2am and who gets paged?"
• QA owns the failure modes nobody wants to name. Asks "how does this fail in a way the demo hides?"

Optional fifth seat: a pre-mortem round (Gary Klein, via Harvard Business Review) when the stakes are high: everyone writes the post-mortem of the plan's failure, then works backward to causes.

3. Run the rounds

Four rounds, timed and separate. Never merge rounds.

Round 1: Clarify (questions only, no verdicts). Each role asks up to three questions of the brief. The author of the proposal answers. Nobody is allowed an opinion yet. Missing answers go in the log as open questions.

Round 2: Argue. Each role makes its case in turn, PM first, QA last. Timed: give each role the same budget (say, one full pass over the proposal each). Roles must land at least one genuine objection. "I have no concerns" is not a valid position for a role that holds a mandate.

Round 3: Cross-examine. Roles question each other directly. PM defends user impact against Architect's simplifications. QA probes failure modes Developer waved off. Developer challenges whether Architect's elegant shape ships on time. The facilitator's only job here is time and temperature: keep rounds on budget, keep arguments aimed at the proposal, never the role.

Round 4: Verdict. Each role votes: SHIP, SHIP-WITH-CHANGES, or BLOCK, with a one-sentence reason. A BLOCK must name the specific change that would lift it. The facilitator merges the four votes into the decision log and writes the final recommendation, including dissent that stands.

4. Write the decision log

Every session ends with a written record (template in assets/decision-log-template.md). It holds: the proposal, each role's objections, the open questions, the votes, the recommendation, and the dissent that survived. The decision log is the actual output. The debate is just how you earned it.

Output Contract

A finished session delivers one decision log file, containing:

1. Proposal summary (one paragraph).
2. Role-by-role objections, each attributed to its role.
3. Open questions left unanswered, with owners.
4. Votes: each role's SHIP / SHIP-WITH-CHANGES / BLOCK plus reason.
5. Final recommendation with rationale.
6. Standing dissent, written down even when overruled, so the record shows what was warned about.

Operating Rules

1. Detection before resolution. Rounds 1 to 3 find problems. Fixes and redesigns happen after the session, never inside the debate.
2. Argue the proposal, not the role. The facilitator cuts any line of attack on a persona's competence.
3. The roles cannot agree too fast. If every role votes SHIP in round 4 with no real objection in round 2, the session failed. Rerun round 2 with the facilitator assigning each role its strongest steelman objection.
4. Every role has a blind spot. Role cards name them. The facilitator may invoke a blind spot when a role is overreaching its mandate.
5. Dissent gets written down even when overruled. A decision everyone "agreed" on with no recorded dissent is a session that never happened. This is non-negotiable.
6. Timebox everything. A four-round session should finish in one sitting. If a round overruns, the facilitator calls it and moves on.
7. One proposal per session. New proposal, new session. Do not let round 3 drift into a different decision.
8. The method beats the talent. A well-run session with plain role cards out-performs a clever prompt with no rounds. If the session feels thin, fix the facilitation (timing, round discipline, conflict rules), not the personas.

Worked example (condensed)

Proposal: "Rewrite the billing service in Rust before Q2."

• Round 1: QA asks what the rollback plan is if the rewrite misses the deadline. PM asks which billing bugs customers actually hit last quarter. Architect asks what the rewrite locks in about pricing model flexibility. Developer asks who on the team ships production Rust today.
• Round 2: PM argues the rewrite has no customer-facing trigger. Architect argues the current service's real problem is the data model, not the language. Developer argues the team learns Rust on the critical path to revenue. QA argues billing regressions are the failure mode the demo will hide.
• Round 3: Architect cross-examines PM on whether customer pain is real but invisible. QA cross-examines Developer on test coverage of the existing service.
• Round 4: PM: BLOCK until customer pain is quantified. Architect: SHIP-WITH-CHANGES (fix the data model in the current stack). Developer: BLOCK (team readiness). QA: SHIP-WITH-CHANGES (add billing regression suite first, in either language). Recommendation: do not rewrite; fix the data model; add regression coverage. Standing dissent: PM's warning that the rewrite has no customer trigger.