1533a6e8c3
- ask-claude v2.4.0 -> v2.6.1: Added mandatory disagreement scan (Step 3.5) with web-reference demand + internal consistency check. Updated callouts for the paste-vs-path rule (now HARD RULE, not just example). - ask-hermes v4.1.1 -> v4.2.0: Added mandatory disagreement scan mirroring ask-claude. - ask-dev v1.0.0 -> v1.1.0: Added mandatory disagreement scan mirroring ask-claude. - create-plan v1.1.0 (new): Multi-agent plan-build dispatcher. Trigger phrases, 10-Q brief script (min as needed, max 10), curator dispatch, capture/handoff format, all 6 failure modes. Companion references: curator-framing-prompt.md, deep-research-dispatch-template.md, ask-claude-validation-template.md, structured-brief-10q.md. 5 rounds of Claude validation on the design plan; final SHIP from ask-hermes peer review.
39 lines
1.9 KiB
Markdown
39 lines
1.9 KiB
Markdown
# Adversarial Consulting Pattern
|
|
|
|
Two-turn technique for higher-quality analysis from Claude Opus. Proven effective for architecture decisions, prompt engineering, and design trade-offs.
|
|
|
|
## Pattern
|
|
|
|
**Turn 1:** Ask for advice on the problem. Frame it neutrally — "I need your advice on X."
|
|
|
|
**Turn 2:** Ask Claude to play devil's advocate against its own Turn 1 advice. Require web searches to ground the pushback. Frame: "Push back on your own advice. Do web searches first. Be genuinely adversarial — if your previous answer was wrong, say so."
|
|
|
|
## Why It Works
|
|
|
|
- Claude's first answer is often confident but incomplete — it picks a position and argues for it
|
|
- The adversarial prompt forces it to find counter-evidence via web search, surfacing trade-offs it glossed over
|
|
- The second turn often partially reverses or qualifies the first, producing a more nuanced final position
|
|
- Web search requirement prevents it from just inventing counter-arguments — they must be grounded
|
|
|
|
## When To Use
|
|
|
|
- Architecture decisions with real trade-offs
|
|
- Prompt engineering (where to place rules, how to structure instructions)
|
|
- Security/design reviews
|
|
- Any decision where the first answer felt too clean
|
|
|
|
## When NOT To Use
|
|
|
|
- Simple factual questions (one turn is enough)
|
|
- Time-sensitive queries where the extra turn isn't worth it
|
|
- When Claude's first answer already acknowledged uncertainty and trade-offs
|
|
|
|
## Example Session
|
|
|
|
Session from 2026-07-02: "Where to add global conciseness instructions to reduce token use?"
|
|
|
|
Turn 1: Claude recommended SOUL.md edit, argued token math favored it.
|
|
Turn 2 (adversarial): Claude partially reversed on token math (user has local Ollama, no per-token pricing), conceded the 14-profile symlink risk, acknowledged compression threshold concern, and revised to: SOUL.md edit + SOUL_OVERRIDE.md mechanism + measurement.
|
|
|
|
The adversarial turn produced a materially better recommendation than the first pass.
|