ask-claude v2.6.1, ask-hermes v4.2.0, ask-dev v1.1.0, create-plan v1.1.0

- 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.

ask-claude/references/adversarial-consulting.md

@@ -0,0 +1,38 @@
+# 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.