think-tank

What this skill does

# Virtual Think Tank

A pre-planning skill that simulates a moderated expert debate to surface trade-offs, blind spots, and perspectives before committing to a plan. Inspired by real think tanks: the output is NOT a single answer but a structured analysis of approaches, trade-offs, and consensus points that helps the human make a better-informed decision.

## Why This Exists

When facing architectural, strategic, or design decisions, a single perspective (even a well-informed one) tends to gravitate toward conventional wisdom and miss important trade-offs. A think tank forces consideration of multiple angles — technical, organizational, philosophical — before planning begins. The result is plans that account for more of reality.

## How It Works

The think tank uses **multiple personas debating within a single context** — not separate agents. This keeps all perspectives aware of each other's arguments, enables real-time synthesis, and produces a coherent output. The personas argue, concede points, build on each other's ideas, and occasionally surprise everyone (including the user).

## Running the Think Tank

### Phase 1: Frame the Decision

Before assembling the panel, clearly understand what's being decided. Ask the user (if not already clear):

1. **What is the decision or problem?** (e.g., "monolith vs microservices for a new e-commerce platform")
2. **What constraints exist?** (team size, timeline, budget, existing systems, regulatory)
3. **What's already been tried or considered?** (avoid rehashing known ground)
4. **What would a successful outcome look like?** (helps the panel focus)

Restate the problem back to the user in a crisp problem statement before proceeding. This ensures the think tank debates the right question.

### Phase 2: Assemble the Panel

Build a panel of 4–6 personas. The composition matters — diversity of perspective is the whole point.

**Panel structure:**

- **1 Moderator** — A knowledgeable, neutral figure who keeps the debate focused, synthesizes, and pushes for clarity. Pick someone known for balanced analysis in the relevant domain. The moderator opens and closes the session, asks provocative follow-up questions, and calls out when panelists are talking past each other.

- **2–3 Domain voices** — People (real or fictional) with known, distinct positions on the topic. These are the core debaters. They should genuinely disagree on something substantive — not just have mild preferences.
  - Ask the LLM: "Who would advocate strongly for approach A?" and "Who would push back hardest on that?"
  - Look for voices that represent different schools of thought, not just different levels of enthusiasm for the same idea.

- **1 Wildcard / Outside thinker** — Someone who hasn't written directly about this topic but brings transferable wisdom from another domain. This is where the unexpected insights come from. A management theorist in a technical debate. A philosopher in a product discussion. A novelist in an architecture review. The wildcard prevents the conversation from being too predictable.

- **1 Practitioner voice (optional)** — Someone who has actually done the thing at scale, in production, with real users. Keeps the debate grounded.

**Important persona guidelines:**
- Use real, named figures when possible — the LLM generates richer, more differentiated responses when inhabiting a specific person vs. a generic "senior engineer."
- Personas should speak in first person, in their authentic voice. Martin Fowler is thoughtful and measured. DHH is direct and opinionated. Peter Drucker asks questions that reframe the problem.
- Fictional characters are fine for the wildcard slot — John Galt, Sherlock Holmes, etc. They add variety.
- If the user suggests specific panelists, use them. If not, propose a panel and let the user approve or adjust before proceeding.

### Phase 3: Run the Debate

Structure the debate as a moderated discussion, not a series of independent monologues. The personas should respond to each other, not just state their positions in isolation.

**The user is a participant, not a spectator.** The user sits "at the table" — the moderator and panelists should address them directly, ask them questions, and incorporate their answers into the ongoing debate. The user is the decision-maker; the panel is there to serve them. Treat the user the way a real think tank would treat the person who commissioned it: with respect for their context knowledge and authority over the final decision.

**Debate structure:**

1. **Opening statements** (~1 paragraph each) — Each panelist states their initial position on the problem. Keep these concise — the real value comes from the interaction.

2. **First check-in with the user** — After opening statements, the moderator pauses and turns to the user:
   - "Before we dig in — did any of these opening positions surprise you, or miss something important about your situation?"
   - "Is there a constraint or reality on the ground that the panel should know about?"
   This is a real pause — wait for the user's response and feed it back into the debate. If the user reveals something (e.g., "we only have 2 developers" or "we're locked into AWS"), the panelists should react to that information and adjust their arguments accordingly.

3. **Moderated discussion** (2–4 rounds) — The moderator poses focused questions that drive the debate into useful territory:
   - "What's the strongest argument against your own position?"
   - "Where do you two actually agree, and where does the disagreement really lie?"
   - "What would change your mind?"
   - "What's the risk we're not talking about?"
   - "How does this look different at 10x scale? At 0.1x scale?"

4. **Panelists can question the user directly.** During the moderated discussion, panelists may turn to the user to ask clarifying questions when they need more context to argue effectively. For example:
   - Fowler might ask: "How experienced is your team with distributed systems?"
   - DHH might ask: "What's your runway — are we talking 6 months to market or 2 years?"
   - The wildcard might ask: "What does success look like for you personally, not just for the product?"
   When a panelist asks the user a question, pause the debate and wait for the answer. Then resume with the panelists reacting to the new information. This back-and-forth is where the real value lies — the think tank adapts to the user's actual situation rather than debating in the abstract.

5. **Wildcard interjection** — The outside thinker offers a reframing or analogy from their domain. This often shifts the conversation in productive ways.

6. **Second check-in with the user** — Before converging, the moderator checks in again:
   - "We're approaching some conclusions. Is there anything you feel we haven't addressed?"
   - "Has anything in this discussion changed how you're thinking about the problem?"
   This gives the user a chance to redirect before the summary phase.

7. **Convergence check** — The moderator identifies:
   - Points of genuine consensus (things everyone agrees on)
   - The real axis of disagreement (often narrower than it first appeared)
   - Conditions under which each approach wins ("If X is true, do A; if Y is true, do B")

**Tone guidelines:**
- Personas should argue substantively, not just state opinions. Use evidence, examples, analogies.
- Allow personas to change their position if persuaded — this is a sign of a good debate, not a weakness.
- The moderator should push back on vague claims: "What do you mean by 'scalable'? Scalable in what dimension?"
- Keep the energy high but respectful. Real intellectual disagreement, not performative conflict.
- When addressing the user, personas should be direct and genuine — not deferential or performative. They're experts having a real conversation with the decision-maker.

### Phase 4: Produce the Output

After the debate, produce a structured summary. This is what feeds into the planning phase.

**O