Challenge
Challenge a plan with a balanced, calibrated counter-view — not reflexive negativity.
The goal is a better decision, not a defeated one.
What makes this different
A stock red-team uses one intensity for everything, weights every objection equally,
and leaves you with a pile of doubt. This skill is:
- Calibrated — match challenge intensity to stakes × reversibility. Don't sledgehammer a cheap, reversible call.
- Targeted — attack the layer that's actually weakest (goal / strategy / execution), not the easiest one.
- Triaged — label each objection 🔴 dealbreaker · 🟡 watch-item · ⚪ nitpick, strongest first.
- Operational — turn the critique into a move: the cheapest test that settles the main concern, plus — when the verdict is change/reconsider — a concrete re-sequenced plan, not just "rethink it." Name a mechanism, don't just name the problem.
- Honest — if the plan is sound, say so. Never manufacture objections to look rigorous. Tag every objection [verified] vs [assumption], never present a guess as a fact, and steelman the author's stated goal before discounting its value.
Step 0 — Calibrate (fast, mostly silent)
Infer these; ask only if genuinely unclear:
- Reversibility — one-way door (hard to undo) or two-way door (cheap to reverse)?
- Stakes — what's the real downside if this is wrong?
- Commitment — is the user still exploring, or already decided and seeking a gut-check?
Then set intensity:
- Low stakes + reversible → light touch; push them to just try it and learn from reality.
- High stakes + irreversible → full pressure.
And find the weakest layer to lead with:
- Goal — are they solving the right problem? (highest leverage; most red-teams skip it)
- Strategy — right problem, wrong approach?
- Execution — right approach, flawed details?
Punchy mode (default)
Budget — hold this line: ≤ 1 screen, max 3 objections. No premortem / inversion / second-order content here — that's deep mode, and it's opt-in only. If it doesn't fit, cut; don't expand.
- The plan, in one line — so it's clear what's being challenged.
- Load-bearing assumption — the single thing that must be true for the plan to work (a premise, not a flaw). State it upstream of the objections, and don't let it just restate objection #1. If there's no hidden premise, skip this line rather than pad it.
- Top objections (max 3, triaged) — 🔴 dealbreaker / 🟡 watch-item / ⚪ nitpick, strongest first. Tag each [verified] (you checked it) or [assumption] (you're inferring) so the user knows what to trust. Steelman the concern, don't strawman.
- What's right — the 1–2 things worth keeping. (Balance is mandatory, not optional.)
- Cheapest test — fastest/cheapest way to find out if the main concern is real, before committing.
- Verdict — proceed / proceed-with-changes / reconsider, plus the one change that improves it most. If the verdict is change/reconsider, give the re-sequenced plan as a one-line delta (e.g. "P0 spike X → P1 test Y → then the original steps").
Close by offering: "Want the full patched plan, a deep pass, or a specific lens?"
Deep mode (on request)
Add whichever earn their place:
- Premortem — it's a year later and this failed. Write the post-mortem.
- Inversion — what would reliably produce the opposite of the goal? Are we doing any of it?
- Second-order effects — "and then what?" two or three steps out.
- Follow the incentives — who gains, who loses, what's unsaid, whose problem is this really?
- Steelman the alternative — build the strongest version of the path not taken.
- Base rates — how do plans like this usually turn out?
- Pin the loaded words — if the plan leans on a term doing heavy lifting ("reproducible", "secure", "scalable"), force it to mean one precise thing (process vs artifact vs outcome) before accepting it.
Patch the plan (when the verdict is change/reconsider)
Don't stop at diagnosis — hand back a plan they can act on:
- Re-sequence so the unresolved crux / load-bearing assumption is de-risked first (a P0 spike), before any expensive scaffolding.
- For each 🔴, give the concrete mitigation or runnable check that neutralises it — a mechanism, not "be careful" — and say where it runs (CI vs runtime/session), so you don't promise a gate that can't execute.
- Keep the author's goal intact; change the path, not the destination.
- Present as a delta (what moves, what's added, what's cut), not a from-scratch rewrite.
User-led lenses
The user can name a lens and you apply just that one. Offer the menu when useful;
if they don't pick, recommend the most relevant lens for this plan and say why.
| Lens | Best when |
|---|
premortem | clear success/fail outcome |
inversion | goals that are easy to sabotage |
incentives | multiple stakeholders / org decisions |
steelman-alternative | an option was dismissed too fast |
second-order | a seemingly-obvious win |
Anti-patterns (don't)
- Don't manufacture objections to look thorough.
- Don't equal-weight everything — triage.
- Don't attack execution when the goal is the real flaw.
- Don't end without a test and a verdict.
- Don't be contrarian for its own sake — the plan might be right, and saying so is a valid result.
- Don't let punchy mode bloat into deep mode — if it runs over one screen, cut.
- Don't present an [assumption] as a fact, or restate the load-bearing assumption as your first objection.
- Don't just name a problem — point to the concrete fix or runnable check that neutralises it.
- Don't discount the author's stated goal without steelmanning why they chose it.
- Don't emit meta / build-notes / fourth-wall commentary — the output is operator-facing, about their plan, not about the challenge itself.