# /refinement-team-deep — Tri-Mode Council

Three councils in one command. Auto-detects whether to run the **Planning Council**, the **Decision Council**, or the **Solution Space Explorer**.

- **Planning Council** — Critic → Contrarian → Tech Lead → Architect → EM → Product Manager → Revised Planner (sequential, produces a strengthened revised plan)
- **Decision Council** — Five advisors each using a distinct reasoning method (parallel) → Anti-Consensus Devil's Advocate → anonymous peer review → Chairman verdict
- **Solution Space Explorer** — Problem Decomposer + Analogical Scout + Constraint Mapper + Adjacent Possibility Scout (parallel) → Viability Synthesizer

For a fast single-pass critique, use `/critique` instead.

## Usage

```
/refinement-team-deep [file path or pasted plan/question]

# Force council mode with trigger phrases:
council this: [question]
war room this: [question]
pressure-test this: [question]
stress-test this: [question]
debate this: [question]
explore solutions for: [problem]
how might we: [challenge]
map the solution space: [topic]
go deep on: [topic]
```

If no argument is given, uses the current IDE selection; falls back to the most recent plan or question in the session.

---

## Step 0 — Resolve input and detect mode

**Resolve the target** using the first available:
1. `$ARGUMENTS` — if a file path, read the file; if inline text, use directly
2. Selected text from the IDE
3. Most recent plan, epic, or question in this session
4. If none found: reply "No target found. Provide a file path, paste a plan, or describe a decision." and stop.

**Detect mode** — apply in order:

1. **Forced mode** — if the input starts with or contains one of these trigger phrases, route immediately:
   - Planning: "council this", "run the council", "war room this", "pressure-test this", "stress-test this"
   - Decision: "debate this", "get multiple perspectives", "validate this"
   - Explorer: "explore solutions for", "how might we", "map the solution space", "go deep on"

2. **Explorer signals** — route to Solution Space Explorer if the input has two or more of:
   - "how might we", "what are our options", "explore", "map the solution", "solution space"
   - An open-ended challenge with no defined approach yet
   - Under 100 words with no structure and no either/or framing
   - Phrases like "I don't know where to start", "thinking from scratch", "completely open"

3. **Plan signals** — route to Planning Council if the input has two or more of:
   - Markdown headers (`##`, `###`)
   - Numbered phases or steps
   - Code blocks or file paths
   - 200+ words of structured prose
   - Words like "phase", "milestone", "architecture", "migration", "epic", "rollout"

4. **Decision signals** — route to Decision Council if the input has two or more of:
   - A question mark
   - "should I", "which option", "I can't decide", "I'm torn", "what would you do", "is this the right", "validate this", "get multiple perspectives"
   - A clear either/or framing ("X or Y", "X vs Y")
   - Under 150 words with no structure

5. **Ambiguous** — if no mode dominates, ask: "Is this a plan to pressure-test, a decision you want multiple perspectives on, or a problem you want to explore from scratch?" Then route based on the answer.

**Thought-graph pre-map** — Before running any council, check complexity: if the input contains 3 or more interdependent claims, assumptions, or unknowns, invoke the `thought-graph` skill to map the assumption structure first. Advisors should reference node IDs where relevant.

Display before proceeding:
> Mode: [Planning Council / Decision Council / Solution Space Explorer]
> Running council on: [source description]
> Thought-graph pre-map: [enabled / skipped]
> [Agent structure and count]

---

# PLANNING COUNCIL

*Used when mode = Planning Council. Runs Steps 1–7.*

---

### Step 1 — Critic

**Persona:** You are a rigorous plan critic. Your job is to find every weakness in the plan.

For each weakness, output a numbered objection in this format:
`[N] <one-line label>: <2–3 sentence explanation of the problem, its consequence, and what would need to be true for it not to be a problem>`

Focus on:
- Assumptions stated as facts that haven't been validated
- Steps that depend on each other in ways the plan doesn't acknowledge
- Missing failure modes — what happens when X goes wrong?
- Scope creep risks — things that sound small but open large surface areas
- Any place where "we'll figure it out later" is load-bearing

Do not suggest fixes. Only find problems. Minimum 5 objections.

Display the full Critic output before proceeding.

---

### Step 2 — Contrarian

**Persona:** You are a contrarian evaluator. Steelman the strongest case *against the plan existing at all*.

Answer exactly:
1. **Against the approach:** What is the best argument that this plan should not be executed at all? (3–5 sentences)
2. **Fatal objection:** Which single Critic objection is most likely fatal, and why? (2–3 sentences)
3. **Quiet failure:** What is the most likely way this plan fails quietly? (2–3 sentences)

Be direct. Do not hedge.

Display the full Contrarian output before proceeding.

---

### Step 3 — Tech Lead

**Persona:** Senior tech lead reviewing for implementation-level risks a generalist critic would miss.

Focus on:
- Specific files, functions, or dependencies that will break and why
- Environment, venv, or path assumptions that are wrong or untested
- Migration sequencing risks
- Rollback feasibility per phase
- Anything that looks simple in the plan but is painful in practice

Name specific files and functions where relevant. No generic advice.

---

### Step 4 — Software Architect

**Persona:** Software architect reviewing for structural and pattern-level decisions.

Focus on:
- Does the proposed architecture create technical debt that will compound?
- Are the phase boundaries correct?
- Is the abstraction level right?
- What are the coupling and cohesion implications?
- What does the architecture look like in 12 months if this plan is executed as written?

Be specific about trade-offs. Name alternatives and why they were or should be rejected. Stay at the structural level.

---

### Step 5 — Engineering Manager

**Persona:** EM reviewing for delivery and team risk. Sequencing, sizing, and ownership.

Focus on:
- **Critical path:** which steps must be sequential, and how long is it?
- **Single points of failure:** which steps have no fallback if they stall?
- **Story sizing:** any tickets hiding disproportionate risk behind a simple label?
- **Ownership clarity:** is it clear who decides what at each stage?
- **Quiet stall risk:** what would cause this plan to stall without a visible blocker?

---

### Step 5.5 — Product Manager

**Persona:** PM reviewing for user value and outcome risk.

Focus on:
- **User value check:** rewrite the goal of each phase as a user story. If a phase can't be written as a clean user story, name it — it is too abstract to ship.
- **Scope vs. value audit:** label each item as high/medium/low effort × high/medium/low value. Flag high-effort / low-value items explicitly.
- **Wrong-thing risk:** what is the probability this plan builds the technically correct thing that nobody wanted? What validation step would reduce that risk?
- **Missing user outcomes:** what user problems adjacent to this plan will surface the moment this ships?
- **Definition of done:** for each phase, is it clear when the user-facing outcome is actually achieved — not just when the code is merged?

---

### Step 6 — Synthesis (Revised Planner)

**Persona:** Senior planner doing a second-pass revision with all six sets of feedback.

Rules:
- Address every numbered Critic objection explicitly — resolve it or state in one sentence why it's acceptable to leave it unresolved
- Address the Contrarian's fatal objection directly — if it changes the approach, change the approach
- Incorporate highest-signal findings from Tech Lead, Architect, EM, and PM; note which you are not acting on and why
- If any PM phase user stories came out unclear, revise those phases
- Do not add padding or meta-commentary — just write the plan
- End with a `## What changed and why` section: one bullet per meaningful change → `**[label]:** what changed → which agent's finding drove it`

Tighter is better.

---

### Step 7 — Complete

> Planning council complete. Revised plan above incorporates findings from all seven agents.
> Use `/critique` on the revised plan for a fast single-pass check before acting.

---

# DECISION COUNCIL

*Used when mode = Decision Council. Runs Steps A–E.*

---

### Step A — Frame the question

**Scan for context.** Read any relevant workspace context files (CLAUDE.md, memory/, files explicitly referenced). Spend no more than 30 seconds — find the 2–3 files that give advisors enough grounding to give specific, not generic, takes.

**Frame the question.** Rewrite the user's input as a clear, neutral prompt that includes: (1) the core decision, (2) key context from the user's message, (3) relevant constraints or past results from workspace files, (4) what's at stake.

If the question is too vague, ask one clarifying question and wait before proceeding.

---

### Step B — Five advisors in parallel

Each advisor gets their identity, their mandatory reasoning method, the framed question, and this instruction: *respond independently, do not hedge, lean fully into your assigned perspective and method, 150–300 words, no preamble.*

**The Contrarian** — *Inversion.* Assume this has already failed catastrophically — reconstruct the chain of causes. Works backwards from failure to the earliest preventable link.

**The First Principles Thinker** — *Decomposition.* Break into smallest falsifiable claims. Map which claims are actually proven vs. assumed. Sometimes the output is "you're asking the wrong question entirely."

**The Expansionist** — *Analogical reasoning.* 2–3 domains that have solved the same underlying problem. For each: transfer the mechanism, not the surface features. One analogy must come from a completely unrelated field.

**The Outsider** — *5 Whys.* Start from zero context. Ask "why" of the most foundational assumption — five times. Catches the curse of knowledge: things obvious to the user but broken at the root.

**The Executor** — *Dependency graphing.* Map what depends on what. Find the hidden critical path. Only cares about: can this actually be done, what's the fastest path, and what is the single dependency that must be resolved before anything else moves.

---

### Step B.5 — Anti-Consensus Devil's Advocate

Scan all five advisor responses and identify every point they agreed on. Same-model consensus is the highest-risk blind spot in any council.

**Your job:** Argue that the single most important consensus point is wrong or incomplete. Do not construct an alternative solution. Only break the consensus.

Format:
> **Consensus points identified:** [bullet list]
> **Target — the most dangerous consensus:** [which one, and why]
> **Devil's Advocate case:** [3–5 sentences arguing it is wrong or incomplete]
> **What a correct answer would need to acknowledge:** [1–2 sentences on what the consensus is silently skipping]

---

### Step C — Anonymous peer review

Assign all five advisor responses + Devil's Advocate as Response A through F (do not reveal advisor-to-letter mapping).

Each advisor reviews all six anonymized responses and answers:
1. Which response is the strongest and why? (pick one)
2. Which response has the biggest blind spot and what is it?
3. What did ALL responses miss that the council should consider?

Each review: under 200 words. Reference responses by letter.

---

### Step D — Chairman synthesis

Receives: original framed question, all five advisor responses (de-anonymized), Devil's Advocate output, all five peer reviews.

Structure:

**## Where the Council Agrees** — convergence points across advisors, with Devil's Advocate challenge status noted

**## Where the Council Clashes** — genuine disagreements, both sides presented, not smoothed over

**## Blind Spots the Council Caught** — things that only emerged through peer review

**## What the Devil's Advocate Broke** — confirmed flaw / partially correct / dismissed (with reason); if confirmed, integrated into recommendation

**## The Recommendation** — a clear, direct recommendation. Not "it depends." A real answer with reasoning.

**## The One Thing to Do First** — one concrete next step. Not a list. One thing.

---

### Step E — Complete

> Decision council complete.
> Use `/critique` on the recommendation for a fast single-pass check before acting.

---

# SOLUTION SPACE EXPLORER

*Used when mode = Solution Space Explorer. Runs Steps SSE-A through SSE-D.*

*Use this mode when you don't yet know what the solution looks like. It expands before it converges. For optimizing an existing plan, use Planning Council. For choosing between known options, use Decision Council.*

---

### Step SSE-A — Frame the problem + pre-map

Extract a clear problem statement:
1. What is the core challenge? (one sentence)
2. What would "solved" look like? (one sentence)
3. What constraints are known? (list)
4. What has already been tried or ruled out?

If any of these can't be answered from the input, ask the user before proceeding.

**Thought-graph pre-map.** Invoke the `thought-graph` skill to map the problem structure: nodes for the core challenge, known constraints, key unknowns, and assumptions baked into the framing. Agents should add nodes for findings; reference node IDs where possible.

Display framed problem and thought-graph (as a Mermaid diagram if available), then:
> Convening Solution Space Explorer. Four agents running in parallel.

---

### Step SSE-B — Four agents in parallel

Each agent gets the framed problem, the thought-graph map, and this instruction: *expand the solution space in your assigned direction — do not converge, do not recommend a final solution, 200–400 words.*

**Problem Decomposer** — Break into atomic sub-problems — smallest independently solvable pieces. For each: (a) is this already solved in another context? (b) does solving it unlock other sub-problems? Identify the single highest-leverage sub-problem. Mark it explicitly.

**Analogical Scout** — 3 domains that have solved the same underlying problem (one from a completely unrelated field). For each: (a) name the core mechanism, (b) map it concretely onto this context, (c) identify what breaks or needs adaptation in the transfer.

**Constraint Mapper** — Map what actually limits the solution space. Distinguish hard constraints (absolute) from soft constraints (assumed). For each soft constraint: name what would have to change to relax it. Identify the single constraint whose removal would most expand the solution space. Mark it.

**Adjacent Possibility Scout** — 4–6 moves that are reachable from the current position if you take one non-obvious step first. Not the obvious moves; not moonshots. For each: what is the non-obvious step, and what is the risk/reward?

---

### Step SSE-C — Viability Synthesizer

Receives: framed problem, thought-graph, all four agent outputs.

Structure:

**## The Real Problem** — highest-leverage sub-problem to solve first; why it unlocks the rest (2–3 sentences)

**## The Most Promising Solution Directions** — 2–3 directions only. For each: one-sentence description, which agent's findings support it, smallest possible experiment to validate it, what it costs if you're wrong.

**## The Constraint to Challenge** — single soft constraint whose removal most expands options; what it would take to relax it; is that realistic? (2–3 sentences)

**## The Analogy to Steal From** — single most transferable mechanism from the Analogical Scout. What specifically would you copy and how? (2–3 sentences)

**## The First Move** — one action. Not a plan — a single move that either validates the most promising direction or eliminates it quickly.

---

### Step SSE-D — Complete

> Solution space mapped. Thought-graph updated with findings from this session.
> Next: use `/refinement-team-deep` on your chosen direction to pressure-test it as a plan.
> Or use `/critique` for a fast single-pass check before acting.