Outside Voice

Outside Voice creates deliberate distance from your current momentum. Instead of continuing to push the same plan, it asks a second opinion to challenge the framing, pressure-test the approach, or review the result in a blunt, useful voice:

Direct, concrete, builder-to-builder. No filler.

When to Use

• A plan feels plausible, but you want a strong preflight challenge before implementation
• You are in the middle of debugging or design work and need an outside perspective on the blocker
• A change is "done" but you want an independent review before calling it complete
• The conversation has become anchored on one approach and you want a fresh take

When NOT to Use

Instead of outside-voice	Use
Broad multi-path decision-making with multiple roles	council
Formal code/security review against a concrete diff	code-review or pr-security-review
Choosing the cheapest or strongest model for a task	multi-model-strategy

Modes

Mode	Trigger	Output
challenge	Before implementation starts	A critique of the plan, missing constraints, safer alternatives
consult	During active work	A narrow outside view on the blocker, assumption, or stuck point
review	After implementation	A verdict on correctness, risk, and what still needs work

Workflow

1. Pick the mode explicitly

State the exact role up front:

Use outside-voice in challenge mode.
We have not started implementation yet.
Critique the approach before we commit to it.

2. Pass only the artifact that needs judgment

Do not dump the whole session. Give the outside voice a compact target:

• challenge -> proposed plan, acceptance criteria, constraints
• consult -> blocker, current hypothesis, relevant files or logs
• review -> diff summary, test status, known risks

The smaller the artifact, the easier it is to stay independent from your original framing.

3. Keep the opinion independent

If possible, use a different model or agent than the builder so the second opinion is not merely an echo of the same reasoning lane. See multi-model-strategy for concrete pairing patterns.

4. Ask for a sharp answer, not a polite summary

Use prompts that force a useful verdict:

Mode: challenge
Voice: direct, concrete, builder-to-builder. No filler.

Question:
Will this plan fail? If yes, where?

Return:
1. Verdict
2. Top 3 objections
3. What to change before implementation
4. What would convince you the plan is now sound

5. Apply the output mode-by-mode

Challenge mode

Use this before starting work:

## Outside Voice — Challenge

**Verdict:** [sound / risky / wrong framing]

### Top Objections
1. ...
2. ...
3. ...

### Required Changes Before Build
- ...

### Confidence Gate
- What evidence or prototype would de-risk this?

Consult mode

Use this when progress stalls:

## Outside Voice — Consult

**Likely Mistake:** ...
**What You're Assuming:** ...
**What To Check Next:** ...
**If That Fails:** ...

Review mode

Use this after implementation:

## Outside Voice — Review

**Verdict:** pass / concerns / block

### Findings
- ...

### Highest-Risk Gap
- ...

### Next Required Action
- ...

Common Rationalizations

Rationalization	Reality
"I already thought this through."	That is exactly when anchoring risk is highest.
"A second opinion will slow me down."	It is cheaper than building on a bad premise or shipping a hidden flaw.
"I only need encouragement."	Outside Voice is for challenge, not reassurance.

Red Flags

• The brief contains the answer you want instead of the question you need checked
• The outside opinion agrees instantly without naming concrete risks
• You keep asking until one reviewer blesses the original plan
• Review mode is used without showing the actual changed surface

Tips

• Ask one narrow question per pass
• Prefer a different model family for the second opinion when practical
• Treat a strong dissent as input to resolve, not tone to ignore
• If the problem is really "which path should we choose?", move to council

See Also

• council — multi-voice deliberation for ambiguous decisions
• implementation-review — compare delivered work against the original spec
• multi-model-strategy — diversify builder and reviewer lanes