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.
2026-07-06 12:51:02 -05:00
parent c6d6db699c
commit 1533a6e8c3
12 changed files with 1775 additions and 8 deletions
--- a/ask-claude/SKILL.md
+++ b/ask-claude/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: ask-claude
 description: "Consult Claude Opus 4.8 on 10.0.0.28 via SSH print mode with session resumption. Multi-turn back-and-forth without tmux or polling."
-version: 2.4.0
+version: 2.6.1
 author: Hermes Agent
 license: MIT
 platforms: [linux]
@@ -60,6 +60,7 @@ Is there an active Claude session_id from a previous turn in THIS Hermes session
 - Research that benefits from SearXNG + Opus reasoning
 - Multi-turn discussion where Claude may ask clarifying questions
 - **Adversarial consulting** — ask for advice, then ask Claude to push back on its own advice with web searches. See `references/adversarial-consulting.md` for the pattern.
 - **Plan validation** — adversarial review of an implementation / integration / skill plan. See `references/plan-validation-prompt.md` for the proven prompt template (workshopped Jul 6 2026).
 ## Critical Evaluation — You Are the Final Authority
@@ -77,6 +78,8 @@ Is there an active Claude session_id from a previous turn in THIS Hermes session
 5. **Watch for overcomplication.** Claude's default mode is thoroughness, which can become overengineering. If Claude proposes a multi-step protocol with atomic renames, CAS semantics, and lease expiration — ask: "Is there a simpler way? Can we solve this with a 50-line Python script instead?" The best fix is usually the simplest one that actually works.
 6. **Pre-empt overcomplication in the prompt.** When asking Claude to validate a plan or design, add a constraint like: "CRITICAL CONSTRAINT: Do NOT propose new features, new architecture, or new complexity. Your job is to find FLAWS in what's already proposed — not to add more. If you find a problem, say what's wrong and suggest the SIMPLEST fix." Without this, Claude will propose additional layers, new abstractions, and feature creep — exactly what you're trying to avoid in a validation pass.
 ## Claude's Limitations
 **Claude cannot read your local files.** Claude runs on 10.0.0.28 and has no access to `/home/n8n/workspace` or any other path on your machine. When Claude says "I can't read that file" or "that path doesn't exist here" — **believe it.** Do not ask Claude to validate a file by path. Instead:
@@ -255,6 +258,48 @@ ssh n8n@10.0.0.28 '~/claude/hermes_support/ask.sh --resume SESSION_ID --qfile /t
 Show Claude's response. If Claude asked a clarifying question (visible in the result text), get the user's answer.
 ### Step 3.5: Disagreement Scan (MANDATORY before applying)
 **Do NOT silently accept Claude's recommendations. Do NOT silently drop suggestions you disagree with. Both are failure modes.**
 For every Claude response, before applying or moving on, do this scan:
 **1. Disagreement check.** Walk through Claude's findings (release-blockers, medium, low, suggestions). For each:
   - **Agree + will apply** → no action this step
   - **Agree + will skip** → state explicitly WHY you're skipping (overkill, environment constraint, contradicts operator's standing rule, etc.). Do not just drop it.
   - **Disagree** → push back. Either (a) decide it's not worth the round-trip cost and state your reason, or (b) send a follow-up turn challenging Claude's claim. **If you don't push back on at least one item per multi-finding response, you're accepting Claude's framing wholesale — which defeats the purpose of asking.**
 **2. Web-reference check for weak conclusions.** For any Claude claim that is:
   - a tool version, API behavior, library status, or compatibility statement
   - an architecture pattern recommendation
   - a "best practice" assertion
   - any concrete factual claim that the plan or system will depend on
   …and where Claude did NOT cite a source URL inline, ask Claude for the reference. Pattern: "What's the source for X? I want a URL I can verify before relying on it." Claude has web search; let it use it. If Claude can't produce a URL, the claim is weak and you should treat it as unverified before applying.
   This is the "Web Search Mandate" — Claude should not be the sole source of any concrete factual claim that the build will depend on. If Claude says "X is the latest version" without a URL, push back and demand the source.
 **3. Internal consistency check.** Does Claude's response contradict itself, or contradict your prior turn in this Claude session? If yes, point it out in the next follow-up. Don't apply a contradictory recommendation.
 **Output format for the scan (use this when relaying Claude's response to the operator):**
 ```
 [Claude's findings as-is]
 ## My disagreement scan
 - **Agreed and applied:** [list]
 - **Agreed but skipped:** [item] — [reason]
 - **Disagreed and pushed back:** [item] — [what I said]
 - **Web references requested:** [items where I asked for a URL]
 - **Disagreed silently dropped:** (should be empty — if not, justify)
 ```
 If `Disagreed silently dropped` is non-empty, that's a bug. Surface it.
 **See also:** `references/peer-response-protocol.md` for the full
 disagreement-scan protocol, web-reference mandate, cross-document desync
 mitigation, and pre-build verification gate. These patterns generalize
 beyond ask-claude to any peer dispatch and any multi-section doc edit.
 ### Step 4: Send Follow-ups (WITH --resume)
 Same mktemp pattern, but add `--resume <session_id>` to continue the conversation. Always capture session_id from every response (including errors) — a turn can error yet still advance the session.
@@ -326,6 +371,7 @@ Sonnet is 3-5x faster and cheaper. Use for: factual lookups, simple analysis, qu
 ## Pitfalls
 - **CRITICAL: Pasted inline beats file paths every time.** Claude runs on 10.0.0.28 and has no access to `/home/n8n/workspace/`, `~/workspace/`, or any other local path. "Read the plan at /home/n8n/workspace/.../_plan.md" wastes a turn: Claude searches the wrong filesystem, returns "file not found," and you paid $0.20-$0.35 for nothing. **Always paste the artifact inline** between clear markers like `==== PLAN BEGINS ==== ... ==== PLAN ENDS ====`. The "Claude's Limitations" section above already says this — but the failure mode is costly enough to deserve its own pitfall. File paths in questions should be reserved for files Claude can actually see on its own host (`~/claude/hermes_support/...`).
 - **ask.sh can fail silently while direct `claude -p` works.** The wrapper may return `{"is_error": true, "error": "no Claude output (timeout or CLI failure)"}` even when Claude is healthy. When this happens, fall back to the direct invocation: `ssh n8n@10.0.0.28 'cd ~/claude/hermes_support && timeout 280 /home/n8n/.local/bin/claude -p "$(cat /tmp/ask-claude-q.txt)" --output-format json --model claude-opus-4-8 --max-turns 30 || true'`. The wrapper is preferred (it handles usage API + merge.py), but the direct path is the reliable fallback. If the direct path also fails, Claude is genuinely down.
 - **CRITICAL: Never inline questions in SSH commands.** Shell metacharacters (`"`, `$`, `(`, backticks) will break. Always write to a temp file via `mktemp` first, then `claude -p "$(cat $QFILE)"`.
 - **Always use `--output-format json`** — without it, you get plain text and can't extract session_id for follow-ups.
--- a/ask-claude/references/adversarial-consulting.md
+++ b/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.
--- a/ask-claude/references/ask-claude-payload-pattern.md
+++ b/ask-claude/references/ask-claude-payload-pattern.md
@@ -0,0 +1,151 @@
 # Ask-Claude Payload Pattern
 Session-specific detail for the `ask-claude` skill: how to send questions to Claude
 Opus 4.8 on 10.0.0.28 reliably, capture the session_id, handle shell metacharacters,
 and avoid the filename-collision gotcha that bites when `read_file` returns a
 different schema than expected.
 ## Pattern: scp + ask.sh
 The `ask.sh` wrapper on 10.0.0.28 handles mktemp snapshot, claude invocation
 (`--output-format json --model claude-opus-4-8 --max-turns 30`, `timeout 280`, `|| true`),
 fetches the usage API, and runs `merge.py` to produce a single JSON envelope.
 **Why scp, not heredoc:** shell metacharacters (`"`, `$`, `(`, `)`, backticks) in
 the question content will break heredoc-based writes. For ANY non-trivial question
 write the question to a local temp file, scp it, and pass the remote path to
 `ask.sh --qfile`.
 ```bash
 # 1. Write question locally
 write_file("/tmp/ask-claude-q.txt", content=question)
 # 2. Copy to remote
 terminal("scp /tmp/ask-claude-q.txt n8n@10.0.0.28:/tmp/ask-claude-q.txt")
 # 3. Run via ask.sh
 terminal("ssh n8n@10.0.0.28 '~/claude/hermes_support/ask.sh --qfile /tmp/ask-claude-q.txt'")
 ```
 ## JSON envelope fields
 Always parse these from the `--output-format json` response:
 | Field | When | Use |
 |---|---|---|
 | `session_id` | Always (including errors) | Capture for `--resume` follow-ups |
 | `result` | Success | The answer text |
 | `is_error` | Always | `true` if anything failed |
 | `subtype` | Always | `success` / `error_max_turns` / `error_budget` |
 | `total_cost_usd` | Always | Track spend |
 | `num_turns` | Always | How many agentic loops |
 | `usage.input_tokens` | Always | Context usage |
 | `usage.cache_creation_input_tokens` | Always | Context usage |
 | `usage.cache_read_input_tokens` | Always | Context usage |
 | `output_tokens` | Always | Context usage |
 | `modelUsage.{model}.contextWindow` | Always | Context window size — iterate keys, don't hardcode |
 | `stop_reason` | Always | Why Claude stopped |
 **Critical: capture `session_id` from EVERY response, including errors.** A turn can
 error yet still advance the session. If you only store it on success, `--resume` breaks.
 **Critical: detect `error_max_turns` via `subtype`, not `is_error`.** `error_max_turns`
 has `is_error: false` but no `result` field. Empty-answer detection requires checking
 `subtype == 'error_max_turns'`.
 ## Asking Claude to validate a file
 Claude (Opus on 10.0.0.28) has **no filesystem access to the operator's machine**.
 When asking Claude to validate a plan, code, or doc:
 1. **Read the file locally** with `read_file` or `terminal cat > /tmp/file.txt`
 2. **Inline the content in the question** as a fenced block
 3. **Tell Claude explicitly** the file is pasted inline (not a path to read)
 **Common failure mode:** pasting a path like `/home/n8n/workspace/...` and asking
 Claude to validate it. Claude will reply "I can't read that file" and refuse to
 validate. Always inline.
 ## Filename-collision gotcha (execute_code + read_file)
 `hermes_tools.read_file` inside `execute_code` returns a different schema than the
 top-level `read_file` tool. Inside a script:
 ```python
 from hermes_tools import read_file
 r = read_file("/path/to/file")
 # Schema: {"status": ..., "message": ..., "path": ..., "dedup": ..., "content_returned": ...}
 # NO "content" key. Use the top-level read_file tool, OR use terminal cat.
 ```
 **Workaround patterns:**
 ```python
 # Pattern 1: terminal cat to a temp file, then open()
 import subprocess
 subprocess.run(["cp", "/path/to/file", "/tmp/working.txt"])
 with open("/tmp/working.txt") as f:
    content = f.read()
 # Pattern 2: shell-out to the file directly
 with open("/path/to/file") as f:
    content = f.read()  # works in execute_code without hermes_tools
 ```
 This gotcha caused patch errors in a multi-file edit session: a patch string was
 constructed from `r["content"]` which didn't exist inside `execute_code`. Switched
 to `subprocess.run` + `with open()` to read reliably.
 ## Pre-dispatch model and config
 - **Always pass `--model claude-opus-4-8` explicitly.** Profile defaults drift silently.
 - **Always set `--max-turns`.** Default 30 is good for analysis. Lower for trivial
  questions; higher (50+) for deep architectural reviews.
 - **Always wrap with `timeout 280`.** Prevents runaway hangs. SSH itself has 300s.
 - **Always add `|| true` after claude invocation.** `set -e` would kill the script
  on non-zero exit, but the error JSON is still parseable.
 - **Always use `mktemp` for temp files on the remote.** `/tmp/ask-claude-q.txt` is
  a fixed path that concurrent Hermes sessions clobber.
 ## Multi-turn session lifecycle
 - First `ask-claude` call in a Hermes session → fresh session (no `--resume`).
 - Every subsequent call in the same Hermes session → `--resume <session_id>`.
 - Sessions auto-expire after ~5 hours of inactivity. No cleanup needed.
 - If the operator starts a new Hermes session (`.hermes/sessions/` rotates),
  the Claude session is also gone — `--resume` will fail.
 - For maximum continuity, capture `session_id` in the operator-visible relay
  text so the operator can resume manually if the Hermes session restarts.
 ## Usage and context alerts
 Apply on every turn:
 | Check | Threshold | Action |
 |---|---|---|
 | Context % (from JSON envelope) | ≥ 80% | Warn: "wrap up or start fresh" |
 | Session 5h utilization (OAuth API) | ≥ 80% | Warn + show reset time, offer Sonnet |
 | Weekly 7d utilization (OAuth API) | ≥ 90% | Critical warning + reset time |
 | Unavailable (error_budget / rate-limit) | N/A | Report exact reset time |
 **The OAuth usage API aggressively rate-limits.** Call at most every ~5 minutes.
 Cache the last good value. Swallow all errors (429s, timeouts). Never gate a turn
 on this call.
 ## Common error patterns
 - `error_max_turns` — question too complex, increase `--max-turns` or simplify.
  `is_error: false`, but no `result` field — check `subtype` explicitly.
 - `error_budget` — hit spending cap, check Pro limits.
 - Empty response — timeout (increase from 280s), OOM, or crash.
 - Non-JSON response — SSH dropped mid-call, Claude crashed before writing output.
 - `ask.sh` returns `{"is_error": true, "error": "no Claude output"}` but direct
  `claude -p` works — wrapper has a known failure mode. Fall back to direct:
  `ssh n8n@10.0.0.28 'cd ~/claude/hermes_support && timeout 280 /home/n8n/.local/bin/claude -p "$(cat /tmp/q.txt)" --output-format json --model claude-opus-4-8 --max-turns 30 || true'`
 ## When the operator pushes back
 After applying Claude's recommendations, ALWAYS emit the disagreement scan (see
 SKILL.md §3.5). Skipping this is a failure mode — both silently-accepting and
 silently-dropping are bugs. The scan is mandatory before declaring a Claude turn
 resolved.
--- a/ask-claude/references/peer-response-protocol.md
+++ b/ask-claude/references/peer-response-protocol.md
@@ -0,0 +1,156 @@
 # Peer Response Protocol — Disagreement Scan, Web-Reference Mandate, Cross-Doc Desync
 This reference documents the three cross-cutting patterns that emerged from the
 v2.6.0 ask-claude update. They apply to ANY peer/consultant dispatch
 (ask-claude, ask-hermes, ask-dev, ask-claude-as-curator, future peers) and to
 ANY document-edit workflow where multiple sections describe the same thing.
 ## 1. Disagreement Scan (MANDATORY before applying)
 Source: ask-claude v2.6.0 Step 3.5, ask-hermes v4.2.0, ask-dev v1.1.0 (all
 updated in the same session).
 **Rule:** For every peer response, before applying or moving on, walk through
 the peer's findings and classify each one:
 - **Agree + will apply** → no action
 - **Agree + will skip** → state explicitly WHY you are skipping. Do not
  silently drop. The "why" matters — operator can re-prioritize if the
  rationale is wrong.
 - **Disagree** → push back via `--resume` (ask-hermes/ask-dev) or a follow-up
  turn (ask-claude). Either send the pushback OR state why you decided not to.
 - **Disagreed silently dropped: should be EMPTY.** If non-empty, that's a
  bug — surface it.
 **Output format (emit every time):**
 ```
 [Peer's findings as-is]
 ## My disagreement scan
 - **Agreed and applied:** [list]
 - **Agreed but skipped:** [item] — [reason]
 - **Disagreed and pushed back:** [item] — [what I said]
 - **Web references / live tests requested:** [items where I demanded a URL or run]
 - **Disagreed silently dropped:** (should be empty — if not, justify)
 ```
 The "disagreed silently dropped" line is the tripwire. Empty is the only
 acceptable state. Non-empty means the agent is rationalizing acceptance
 without doing the work.
 ## 2. Web-Reference Mandate (for unverified concrete claims)
 Source: ask-claude v2.6.0, ask-hermes v4.2.0 (already had canonical form), ask-dev v1.1.0.
 **Rule:** For any peer claim that is a concrete factual statement
 (tool version, API behavior, library status, system state assertion,
 "best practice" recommendation) AND where the peer did NOT cite a source URL
 inline OR run a live command to verify, send a follow-up demanding the
 verification.
 **Pattern:**
 > "Show me the command output that supports X. I want a URL or a live test,
 > not reasoning."
 Claude has web search (mcp_searxng_searxng_web_search). Hermes peers have
 filesystem + terminal + web search. **No concrete factual claim is acceptable
 without a source.**
 **Applies to:**
 - Tool versions, port numbers, env var names, config keys
 - "X is broken" / "Y is down" system state assertions
 - Library APIs, package availability, install commands
 - Architecture pattern recommendations
 - "Best practice" assertions
 - Anything the plan or system will depend on
 ## 3. Cross-Document Desync (the recurring edit pattern)
 Source: observed across 5 rounds of plan validation in a single session
 (plan_skill_plan.md v1 → v5). The pattern fires every time.
 **The problem:** When a value (count, name, path, number) changes in a
 document with multiple sections describing the same thing (prose + diagram +
 checklist + cross-references), the edit almost always lands in the prose
 section and gets missed in the diagram and checklist.
 **Symptom:** Sections describe the same construct with different values. The
 section that gets READ CAREFULLY (prose) is correct; the section that gets
 SCANNED (diagram, checklist) is stale.
 **Meta-pattern from the workshop (5 rounds of validation, 4 had desync):**
 the first round almost always misses 2-3 cross-references. The second round
 catches 1-2 more. The third+ rounds usually surface real design issues
 that the desync had been hiding. **Treat the first round of "all clean"
 findings as suspicious** — re-grep for the changed value across the whole
 document before declaring done.
 **Mitigation (MANDATORY before finalizing any doc edit):**
 1. Identify the value being changed (count, name, path, etc.)
 2. `grep -nE "<old_value>" <file>` to find every occurrence
 3. Update ALL occurrences, not just the obvious one
 4. Re-grep with the new value to confirm zero stragglers
 5. For cross-section references (e.g., "see §6 for the 9 pitfalls" when
   §6 now has 11), grep the literal cross-reference too — they are
   often hardcoded numbers that don't update with the section they point
   at
 **This applies to:**
 - Plan documents (sections, diagrams, checklists, cross-references)
 - Skill files (description, examples, pitfall counts, version strings)
 - Config files (any field referenced in multiple sections)
 - Any markdown with both ASCII diagrams AND prose describing the diagram
 **The lesson generalizes:** if a value is mentioned in 3+ places, expect
 to miss at least one on each edit. Treat the grep as a pre-commit hook.
 **Pre-finalize workflow (run this every time, no exceptions):**
 ```bash
 # 1. Identify the value you just changed
 OLD_VALUE="<the value before your edit>"
 NEW_VALUE="<the value after your edit>"
 # 2. Find any stragglers of the old value
 grep -nE "$OLD_VALUE" <file> || echo "OK: no stragglers of $OLD_VALUE"
 # 3. Confirm the new value is in the expected places
 grep -nE "$NEW_VALUE" <file>
 # 4. Find any cross-section references that hardcode the count/number
 grep -nE "§[0-9].*\b$OLD_VALUE\b" <file> || echo "OK: no §X cross-refs to $OLD_VALUE"
 ```
 Run this even when "the edit is in one obvious place." Multi-place edits
 hide.
 ## 4. Pre-Build Verification Gate
 Source: plan_skill_plan.md §7, surfaced when Claude flagged session-id
 line-1 capture as a first-run failure risk that "five rounds of counting-fixes
 never touched."
 **The problem:** Plans can be internally consistent on design while
 containing hidden assumptions about the runtime environment (positional
 output parsing, banner formats, version-specific CLI flags, etc.). These
 don't show up in design review.
 **Mitigation:** Before declaring any plan "buildable," list the
 runtime-assumption items and empirically verify each one against the
 actual deployed environment. Common categories:
 - Positional parsing assumptions (line 1 of output, JSON field order)
 - CLI flag assumptions (`--max-turns 600` works, `--yolo` works, etc.)
 - Path assumptions (config files at expected locations, skills registered)
 - Version assumptions (skill X is at version Y, has feature Z)
 **Output: a verified-items checklist in the plan's §7.** Each item is
 either confirmed (with the actual command output) or marked as
 "out of scope" (with the reason).
 ## When to apply this protocol
 - After EVERY ask-claude, ask-hermes, ask-dev, or any peer response —
  emit the disagreement scan output.
 - After EVERY multi-section doc edit — grep for the old value, then re-grep.
 - Before declaring any plan "buildable" — verify the runtime-assumption
  checklist empirically.
--- a/ask-claude/references/plan-validation-prompt.md
+++ b/ask-claude/references/plan-validation-prompt.md
@@ -0,0 +1,111 @@
 # Plan Validation Prompt Pattern
 The most effective prompt shape for using `ask-claude` to validate a plan. Proven against Opus 4.8 on real plan files (workshopped Jul 6 2026 against `plan_skill_plan.md`).
 ## Why This Pattern
 Generic "review this plan" prompts fail three ways:
 1. Claude proposes new features instead of finding flaws.
 2. Claude's checks are vibes ("this looks incomplete") instead of evidence-grounded.
 3. Claude's review isn't constrained to checkable-from-text-only properties, so it hallucinates verifications.
 The pattern below solves all three.
 ## The Template
 ```
 Validate this plan. Read it in full first.
 CRITICAL CONSTRAINT: Do NOT propose new features, new architecture, or new complexity.
 Your job is to find FLAWS in what's already proposed — not to add more. If you find
 a problem, say what's wrong and suggest the SIMPLEST fix.
 CONTEXT (why this plan exists):
 - <one paragraph: the goal, what triggered the plan, what skills/tools it reuses>
 VALIDATE:
 1. <dimension 1 — must be checkable from plan text alone>
 2. <dimension 2>
 3. ...
 Report format:
 - Release-blockers (must fix before building)
 - Medium (should fix)
 - Low (nice to have)
 - Pass-criteria met / not met
 Then: give 2-3 concrete suggestions for how to make this plan better ACHIEVE the
 operator's goal. Be specific.
 Do not rewrite the plan. Just report findings and suggestions.
 ==== ARTIFACT BEGINS ====
 <paste full artifact here>
 ==== ARTIFACT ENDS ====
 ```
 ## Why It Works
 | Ingredient | Purpose |
 |---|---|
 | `CRITICAL CONSTRAINT: Do NOT propose new features` | Kills Claude's feature-creep reflex (his default mode is thoroughness → overengineering). |
 | `say what's wrong and suggest the SIMPLEST fix` | Forces fixes to be small. Big fixes = new complexity = rejected. |
 | Numbered VALIDATE list with checkable dimensions | Forces structured findings. If a dimension is uncheckable from the artifact text alone, drop it. |
 | Pass-criteria met / not met | Binary verdict the dispatcher can act on. |
 | `2-3 concrete suggestions to ACHIEVE the goal` | Lets Claude contribute value (refinements) without breaking the no-new-features rule. |
 | Pasted artifact with markers | Avoids the "file not found" wasted turn (see SKILL.md Pitfalls). |
 ## Dimensions That Work (Checkable from Text)
 - **Completeness** — does the plan cover all phases / all sub-tasks of the topic?
 - **Internal consistency** — do the steps in §3 actually produce the outputs claimed in §2?
 - **TDD discipline** — is there a failing test before every code-producing task?
 - **Bite-size** — are all tasks 2-5 minutes of focused work?
 - **Bite-size inverse** — which task is suspiciously large and should be split?
 - **Output contract** — are the file paths, names, and structures consistent across all sections?
 - **Trigger / dispatch chain** — does the plan's "use skill X" actually do what's claimed? (e.g., "uses `ask-hermes`" — does it say with what prompt, with what resume rule?)
 - **Session management** — same-topic = resume, new-topic = fresh. Does the plan enforce this?
 ## Dimensions That DO NOT Work (Uncheckable from Text)
 These belong to the *dispatcher* (which has web + filesystem), NOT to Claude:
 - "Are versions current as of 2026?" → Claude has no live web access in print mode.
 - "Do all file paths exist in the project?" → Claude has no filesystem access to the operator's project.
 - "Does this conflict with installed packages?" → Claude has no access to the operator's env.
 If you ask Claude these, it will hallucinate. Either drop them from the prompt or pass the evidence inline (e.g., "Here is the official v0.27.0 release page contents: [paste]").
 ## When To Use
 - Plan for a new skill, integration, infrastructure change, profile setup
 - Plan for a multi-file feature build
 - Plan for a research deliverable that needs structural review
 - ANY plan you're about to ask the user to approve
 ## When NOT To Use
 - Single-step, trivial changes (one file, one config edit) — overkill
 - Research-only outputs (use the `deep-research` validate-fix cycle instead — see `deep-research` skill)
 - Plans that are themselves research findings (Claude should be reading the source URLs, not just the synthesis)
 ## Example: Real Validation Run
 Session: 2026-07-06, validating `plan_skill_plan.md`.
 **What worked:**
 - 3 release-blockers caught: (1) Phase 1 interactive Q&A contradicts "curator runs autonomously", (2) Claude template asked Claude to check things it structurally couldn't, (3) output filename contract contradictory.
 - 6 medium findings: deep-research sync vs async, who writes pre-plan.md, session-id capture fragility, trigger-phrase collision, --no-research breaks checklist, no Claude-down fallback.
 - 4 low findings: rename `_pre-plan.md`, weak self-review, missing validation persistence, false "reproducible" claim.
 - 3 actionable suggestions, including the highest-leverage one: "front-load the brief into the dispatcher" — solved B1 cleanly by changing where the Q&A lives.
 **What didn't:**
 - None. Cost $0.32, caught real defects. Beats running the plan and discovering them at runtime.
 ## Variations
 **For research-heavy plans** (where the primary risk is factual error, not structure): use the `deep-research` skill's validate-fix cycle instead — dispatch `ask-hermes` to web-verify each claim, then feed the report back to `deep-research --resume`.
 **For plans you wrote yourself** (high self-review blindness): prepend `Be especially skeptical of the actor assignments and the open questions — those are where author bias lives.`
--- a/ask-dev/SKILL.md
+++ b/ask-dev/SKILL.md
@@ -1,14 +1,14 @@
 ---
 name: ask-dev
 description: Persistent peer Hermes agent for delegated work on the dev profile. `ask dev <instructions>` delegates a task with full context via headless one-shot commands. Session persists across all turns in one Hermes session via --resume.
-version: 1.0.0
+version: 1.1.0
 author: Hermes Agent
 license: MIT
 platforms: [linux]
 metadata:
  hermes:
    tags: [hermes, peer, delegation, parallel, review, validation, dev]
-    related_skills: [ask-hermes, ask-claude, hermes-agent]
+    related_skills: [ask-hermes, ask-claude, writing-plans, hermes-agent]
 ---
 # ask-dev — Peer Hermes Agent for Delegated Work (Dev Profile)
@@ -129,7 +129,9 @@ This section is the canonical form of the web-search requirement. The abbreviate
 ## Turn Budget
-Max 20 turns per question, enforced by `--max-turns 20` at the CLI level — hard cap. Peer follows up autonomously (tool calls, iterations) without reporting back each turn — only the final result comes back. If the peer hits the 20-turn cap before finishing, it returns what it has — relay that and the operator decides whether to continue with a follow-up ask.
+**Default:** `--max-turns 20` per `ask-dev` invocation. Hard cap. Fine for short delegation, plan reviews, and quick peer checks. If the peer hits 20 before finishing, it returns what it has — operator decides whether to continue.
 **Override — 600 turns (operator standing rule):** For accurate, evidence-based plan-building, deep research, or any task where the operator's intent is thoroughness, use `--max-turns 600 --yolo` instead. The 600 is a safety net, not a budget — the operator's exact rule: *"I don't want to be turn restricted. I just want a safety net. I mostly want the job done right. Not concerned with time or tokens when building accurate plan."* See `writing-plans` skill §"Turn Budget" for the canonical rule. Default to 20 only for short factual lookups or quick peer checks.
 ## Peer Cross-Validation Pattern
@@ -146,6 +148,41 @@ This is NOT the same as Delegate-Fix-Then-Validate (where the peer does the work
 Do not silently paraphrase. Relay the peer's actual response — if long, chunk it. Call out unverified "I did X" claims.
 ## Disagreement Scan (MANDATORY before applying)
 **Do NOT silently accept the peer's recommendations. Do NOT silently drop suggestions you disagree with. Both are failure modes.**
 For every peer response, before applying or moving on, do this scan:
 **1. Disagreement check.** Walk through the peer's findings. For each:
   - **Agree + will apply** → no action this step
   - **Agree + will skip** → state explicitly WHY you're skipping (overkill, environment constraint, contradicts operator's standing rule, etc.). Do not just drop it.
   - **Disagree** → push back via `--resume`. Either (a) decide it's not worth the round-trip cost and state your reason, or (b) send a follow-up turn challenging the peer's claim. **If you don't push back on at least one item per multi-finding response, you're accepting the peer's framing wholesale — which defeats the purpose of asking.**
 **2. Web-reference check for weak conclusions.** For any peer claim that is:
   - a tool version, API behavior, library status, or compatibility statement
   - a system state assertion ("profile X is broken", "service Y is down")
   - a "best practice" assertion
   - any concrete factual claim that the plan or system will depend on
   …and where the peer did NOT cite a source URL inline OR run a live command to verify, send a follow-up demanding the verification. Pattern: "Show me the command output that supports X. I want a URL or a live test, not reasoning." This combines with the Web Search Mandate above — the peer MUST search, not reason.
 **3. Internal consistency check.** Does the peer's response contradict itself, or contradict a prior turn in this peer session? If yes, point it out in the next follow-up. Don't apply a contradictory recommendation.
 **Output format for the scan (use this when relaying the peer's response to the operator):**
 ```
 [Peer's findings as-is]
 ## My disagreement scan
 - **Agreed and applied:** [list]
 - **Agreed but skipped:** [item] — [reason]
 - **Disagreed and pushed back:** [item] — [what I said]
 - **Web references / live tests requested:** [items where I demanded a URL or run]
 - **Disagreed silently dropped:** (should be empty — if not, justify)
 ```
 If `Disagreed silently dropped` is non-empty, that's a bug. Surface it.
 ## Spot-check Rule
 Peer self-reports are not verified fact. If the peer reports a file write, `read_file` the path to confirm. If it reports a test pass, re-run the test if the result matters.
--- a/ask-hermes/SKILL.md
+++ b/ask-hermes/SKILL.md
@@ -1,14 +1,14 @@
 ---
 name: ask-hermes
 description: Persistent peer Hermes agent for delegated work. `ask hermes <instructions>` delegates a task with full context via headless one-shot commands. Session persists across all turns in one Hermes session via --resume.
-version: 4.1.0
+version: 4.2.0
 author: Hermes Agent
 license: MIT
 platforms: [linux]
 metadata:
  hermes:
    tags: [hermes, peer, delegation, parallel, review, validation]
-    related_skills: [ask-claude, claude-code, hermes-agent]
+    related_skills: [ask-claude, ask-dev, claude-code, writing-plans, hermes-agent]
 ---
 # ask-hermes — Peer Hermes Agent for Delegated Work
@@ -132,7 +132,9 @@ This section is the canonical form of the web-search requirement. The abbreviate
 ## Turn Budget
-Max 20 turns per question, enforced by `--max-turns 20` at the CLI level — hard cap. Peer follows up autonomously (tool calls, iterations) without reporting back each turn — only the final result comes back. If the peer hits the 20-turn cap before finishing, it returns what it has — relay that and the operator decides whether to continue with a follow-up ask.
+**Default:** `--max-turns 20` per `ask-hermes` invocation. Hard cap. Fine for short delegation, plan reviews, and quick peer checks. If the peer hits 20 before finishing, it returns what it has — operator decides whether to continue with a follow-up ask.
 **Override — 600 turns (operator standing rule):** For accurate, evidence-based plan-building, deep research-style multi-phase work, or any task where the operator's intent is thoroughness, use `--max-turns 600 --yolo` instead. The 600 is a safety net, not a budget — the operator's exact rule: *"I don't want to be turn restricted. I just want a safety net. I mostly want the job done right. Not concerned with time or tokens when building accurate plan."* The `create-plan` skill's curator invocation always uses 600. Default to 20 only for short factual lookups or quick peer checks. See `writing-plans` skill §"Turn Budget" for the canonical rule.
 ## Peer Cross-Validation Pattern
@@ -149,11 +151,48 @@ This is NOT the same as Delegate-Fix-Then-Validate (where the peer does the work
 Do not silently paraphrase. Relay the peer's actual response — if long, chunk it. Call out unverified "I did X" claims.
 ## Disagreement Scan (MANDATORY before applying)
 **Do NOT silently accept the peer's recommendations. Do NOT silently drop suggestions you disagree with. Both are failure modes.**
 For every peer response, before applying or moving on, do this scan:
 **1. Disagreement check.** Walk through the peer's findings. For each:
   - **Agree + will apply** → no action this step
   - **Agree + will skip** → state explicitly WHY you're skipping (overkill, environment constraint, contradicts operator's standing rule, etc.). Do not just drop it.
   - **Disagree** → push back via `--resume`. Either (a) decide it's not worth the round-trip cost and state your reason, or (b) send a follow-up turn challenging the peer's claim. **If you don't push back on at least one item per multi-finding response, you're accepting the peer's framing wholesale — which defeats the purpose of asking.**
 **2. Web-reference check for weak conclusions.** For any peer claim that is:
   - a tool version, API behavior, library status, or compatibility statement
   - a system state assertion ("profile X is broken", "service Y is down")
   - a "best practice" assertion
   - any concrete factual claim that the plan or system will depend on
   …and where the peer did NOT cite a source URL inline OR run a live command to verify, send a follow-up demanding the verification. Pattern: "Show me the command output that supports X. I want a URL or a live test, not reasoning." This combines with the Web Search Mandate above — the peer MUST search, not reason.
 **3. Internal consistency check.** Does the peer's response contradict itself, or contradict a prior turn in this peer session? If yes, point it out in the next follow-up. Don't apply a contradictory recommendation.
 **Output format for the scan (use this when relaying the peer's response to the operator):**
 ```
 [Peer's findings as-is]
 ## My disagreement scan
 - **Agreed and applied:** [list]
 - **Agreed but skipped:** [item] — [reason]
 - **Disagreed and pushed back:** [item] — [what I said]
 - **Web references / live tests requested:** [items where I demanded a URL or run]
 - **Disagreed silently dropped:** (should be empty — if not, justify)
 ```
 If `Disagreed silently dropped` is non-empty, that's a bug. Surface it.
 ## Spot-check Rule
 Peer self-reports are not verified fact. If the peer reports a file write, `read_file` the path to confirm. If it reports a test pass, re-run the test if the result matters.
-**Peer verdicts can be WRONG.** A peer may flag a profile as BROKEN when it's actually healthy, or claim PASS on something that's broken. Always independently verify the peer's conclusions — don't relay them as fact. Concrete example: peer claimed `general` profile was BROKEN (bank_id leak), but the daemon log showed `general` was actively writing to `hermes-general` with successful retain + consolidation. The peer's logic was confused — it assumed the bank_id convention was violated when it wasn't. The daemon log is the source of truth, not the peer's reasoning.
+**Peer verdicts can be WRONG.** A peer may flag a profile as BROKEN when it's actually healthy, or claim PASS on something that's broken. Always independently verify the peer's conclusions — don't relay them as fact. Concrete examples:
 - Peer claimed `general` profile was BROKEN (bank_id leak), but the daemon log showed `general` was actively writing to `hermes-general` with successful retain + consolidation. The peer's logic was confused — it assumed the bank_id convention was violated when it wasn't. The daemon log is the source of truth, not the peer's reasoning.
 - Peer claimed `default` profile "does not exist on this system" because `ls ~/.hermes/profiles/default/` returned ENOENT. But `hermes -p default skills update` works — the `default` profile uses base `~/.hermes/`, not a `profiles/default/` directory. The peer didn't test the actual command before declaring it broken. Always verify peer claims about system state with a live command, not just filesystem inspection.
 ## Delegate-Fix-Then-Validate Pattern
--- a/create-plan/SKILL.md
+++ b/create-plan/SKILL.md
@@ -0,0 +1,362 @@
 ---
 name: create-plan
 description: "Multi-agent plan-build pipeline: brief → research → assembly → Claude evidence-diff → URL re-verify → reconcile. Triggered by 'create plan for X', 'plan this', 'draft a plan for', 'build a plan for'."
 version: 1.1.0
 author: Hermes Agent
 license: MIT
 platforms: [linux]
 metadata:
  hermes:
    tags: [planning, plan, create-plan, orchestration, multi-agent, delegation]
    related_skills: [ask-hermes, ask-claude, deep-research, writing-plans, subagent-driven-development]
 ---
 # create-plan — Multi-Agent Plan-Build Pipeline (Dispatcher)
 ## 1. Overview
 The `create-plan` skill is a thin dispatcher that orchestrates a 7-phase plan-build pipeline (Phase 0 through Phase 6). The dispatcher runs Phase 0 — an interactive brief with the operator — then spawns a peer `ask-hermes` **curator** session that owns Phases 1 through 6 end-to-end. The curator dispatches `deep-research` for current evidence, runs assembly itself using `writing-plans` methodology, dispatches `ask-claude` for the adversarial evidence-diff, performs URL re-verification of the plan's specific cited claims, and reconciles the final plan.
 **Output files:** `<topic>_plan.md` (actionable, validated) and `<topic>_research.md` (evidence, with appended re-verify log). The 600-turn ceiling is a safety net, not a budget — the curator is allowed to take as long as it needs. Correctness > speed. The user resumes the **curator** (not the dispatcher) to iterate, add constraints, or request re-validation. Per `ask-hermes` Turn Budget section (and §5.3 below), the create-plan curator always uses `--max-turns 600 --yolo`; the default 20 is not appropriate for evidence-based plan builds.
 **Reconcile 2x:** Phase 3 (curator self-review) catches obvious gaps before Claude sees them. Phase 6 (final reconcile) applies Claude's agreed changes and URL re-verify mismatches. Two reconciles are required because they catch different classes of issues — author-blindness (Phase 3) vs. evidence-diff failures (Phase 6).
 **Dispatcher scope — what this skill actually does.** This skill is a thin dispatcher that runs ONLY Phase 0 (the interactive 10-question brief) and then hands control to a peer `ask-hermes` **curator** session that owns Phases 1–6. The dispatcher does not run research, assembly, or validation itself. For the dispatcher's trigger phrases, the Phase 0 brief script, and the exact `hermes -p general chat ...` command that spawns the curator (and how `curator_session_id` is captured from output line 1), see **Section 5** below.
 ## 2. When to Use / When NOT to Use
 **Use when:**
 - The operator wants a thorough, web-validated plan with current software versions, official docs, and adversarial review.
 - The plan is for: software implementation, infrastructure, integrations, profile setup, research-heavy deliverables, pipelines, OSINT, etc.
 - The operator is willing to let the curator take as long as it needs (no turn restriction).
 **Do NOT use when:**
 - Single-step trivial change → use `writing-plans` directly.
 - A plan the operator will immediately execute → use `writing-plans` + `subagent-driven-development`.
 - The operator wants a quick sketch, not a validated plan.
 - No network or filesystem access to the operator's machine (the curator needs both).
 - Simple Q&A, factual lookups, code review, or general chat (this is not an advice skill).
 ## 3. The Pipeline (7 phases, 0-6)
 ```
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 0: Interactive brief (up to 10 Qs)        [dispatcher]    │
 │   - dispatcher asks operator clarifying questions              │
 │   - priority order: scope → constraints → success → unknowns    │
 │     → users → out-of-scope → perf → security → integration     │
 │     → timeline                                                 │
 │   - min as needed, max 10; operator can stop at any Q          │
 │   - Output: frozen brief passed to curator                      │
 └─────────────────────────────────────────────────────────────────┘
                              ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 1: Evidence gathering                      [curator →]    │
 │   - curator dispatches deep-research                            │
 │   - deep-research runs 6-move flow                              │
 │   - curator captures output, writes <topic>_research.md         │
 │   - 600-turn ceiling, mechanical saturation, disconfirmation    │
 └─────────────────────────────────────────────────────────────────┘
                              ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 2: Plan assembly                            [curator]    │
 │   - curator reads <topic>_research.md from disk                 │
 │   - applies writing-plans structure (bite-sized tasks, exact    │
 │     paths, code blocks, TDD per task)                          │
 │   - Output: <topic>_plan.md v1                                  │
 └─────────────────────────────────────────────────────────────────┘
                              ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 3: Curator self-review                      [curator]    │
 │   - curator self-reviews plan, fixes obvious gaps               │
 │   - Output: <topic>_plan.md v2                                  │
 └─────────────────────────────────────────────────────────────────┘
                              ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 4: Adversarial validation                   [curator →]   │
 │   - curator dispatches ask-claude (Opus)                       │
 │   - curator extracts the structured-claims/citations section    │
 │     of <topic>_research.md (~10KB cap) and inlines BOTH the    │
 │     full <topic>_plan.md AND the extracted claims               │
 │   - Claude's prompt: "where does the plan assert something      │
 │     the research extract does not support, or omit something   │
 │     the extract flagged?"                                       │
 │   - Output: validation report (release-blockers / med / low)    │
 └─────────────────────────────────────────────────────────────────┘
                              ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 5: URL re-verification                      [curator]    │
 │   - curator re-fetches URLs backing the SPECIFIC version        │
 │     numbers, commands, and setup steps the PLAN cites            │
 │     (cap at 3) — not "top 3 from research"                       │
 │   - confirms those versions/commands/setup still match current   │
 │     docs                                                        │
 │   - Output: re-verify log appended to <topic>_research.md       │
 └─────────────────────────────────────────────────────────────────┘
                              ↓
 ┌─────────────────────────────────────────────────────────────────┐
 │ Phase 6: Final reconcile                          [curator]    │
 │   - curator reads Claude's report + re-verify log               │
 │   - applies agreed changes, ignores disagreements                │
 │   - Output: <topic>_plan.md final                               │
 │   - reports: curator_session_id for resume                      │
 └─────────────────────────────────────────────────────────────────┘
 ```
 **Per-dispatch command templates (see Section 5 + references/):**
 - **Phase 0 (dispatcher, no shell command):** Inline interactive Q&A with operator. No dispatch. The 10-Q script and stopping rules are in §5.2.
 - **Phase 1 (curator → deep-research):** `hermes -p research -s deep-web-research chat "..."` — the curator runs this inside Phase 1, using the template at `references/deep-research-dispatch-template.md`.
 - **Phase 4 (curator → ask-claude):** scp + `~/claude/hermes_support/ask.sh --qfile ...` — the curator runs this inside Phase 4, using the template at `references/ask-claude-validation-template.md`.
 - **Phase 6 (curator finalize):** `write_file <plan_path>` with reconciled content; the curator owns this and the clobber-guard logic (see §7).
 - **Curator dispatch itself:** `hermes -p general chat -q "..." -Q --max-turns 600 --yolo` — the exact invocation the dispatcher ships is in §5.3.
 ## 4. Dispatcher Q&A Script (Phase 0)
 The dispatcher surfaces up to 10 clarifying questions in **priority order**. **Min as needed, max 10** — the dispatcher only asks the load-bearing dimensions for this specific topic. Operator can say "ask all 10", "ask just Q5 and Q7", "skip", or "you decide" at any point.
 **The full 10-question table with priority order, exact wording, and stopping rules is in §5.2 — that is the authoritative copy.** This section is a one-paragraph pointer; the operator-facing wording of the 10 questions is in §5.2 only.
 **Stopping rules (summary):**
 - Proceed as soon as Q1 (scope) is answered; later Qs are optional.
 - Operator can stop at any Q with "skip" or "you decide".
 - Hard cap at 10.
 - The dispatcher does NOT poll after handing off to the curator.
 ## 5. Dispatcher Behavior (trigger detection, Phase 0 brief, curator dispatch)
 This section is the dispatcher's actual job. It defines how the dispatcher recognizes a "create plan" request, runs the Phase 0 interactive brief, composes and ships the curator dispatch command, and captures the `curator_session_id` for handoff.
 **Boundary:** the dispatcher is responsible ONLY for Phase 0 + the curator handoff. It does NOT run Phases 1–6. Phases 1–6 are the curator's job, driven by `references/curator-framing-prompt.md` (curator identity + pipeline), `references/deep-research-dispatch-template.md` (Phase 1 dispatch), and `references/ask-claude-validation-template.md` (Phase 4 evidence-diff). The curator prompt embeds the two dispatch-template references inline; the dispatcher does not need to inline them itself.
 ### 5.1 Trigger phrases and trigger detection
 The dispatcher fires when the operator's message contains any of these phrases (case-insensitive, substring match on the raw message):
 - `create plan for` — most common; e.g., "create plan for adding a cron job that backs up workspace daily"
 - `plan this` — used when the operator has just described a topic in the prior turn
 - `draft a plan for` — explicit synonym for `create plan for`
 - `build a plan for` — explicit synonym for `create plan for`
 **Parsing rule:** when a trigger phrase matches, treat the noun-phrase that follows as the topic. Strip leading articles (`a`, `an`, `the`) and trailing punctuation. The remainder is the topic string that goes into the frozen brief. If the operator's message contains the trigger phrase but the topic is ambiguous (e.g., "create plan for the thing we discussed"), ask one short clarifying question to nail the topic down — do not guess.
 **Precedence note:** `writing-plans` and `create-plan` both produce plans, but they are different skills. The operator-facing trigger for THIS skill is "create plan for X" (or synonyms above). If the operator says "write a plan for X" without "create" or "draft" or "build", prefer `writing-plans` (which is the lighter, non-validated planner). When in doubt, ask the operator which they want: validated multi-agent plan (`create-plan`) or quick writing-plans output.
 ### 5.2 Phase 0 — Interactive brief (the 10-Q script)
 The dispatcher surfaces up to **10** clarifying questions in **priority order**. **Min as needed, max 10** — only ask the dimensions that are load-bearing for THIS specific topic. The 10 canonical questions live HERE in this skill (not in `writing-plans`; `writing-plans` may reference but does not duplicate them).
 **The 10 questions (in priority order):**
 | # | Dimension | Question |
 |---|---|---|
 | Q1 | Scope | What are we building? What does "done" look like? |
 | Q2 | Constraints | Existing infrastructure? Must-use / must-avoid? Target environment? |
 | Q3 | Success criteria | How will we know it works? Acceptance tests? |
 | Q4 | Known unknowns | What are you uncertain about? Risks? Things that have bitten you before? |
 | Q5 | Target users / audience | Who's using it? Skill level? |
 | Q6 | Out of scope | Explicit non-goals? What are we NOT building? |
 | Q7 | Performance / scale | Expected load, latency, throughput targets? |
 | Q8 | Security / compliance | Auth, data sensitivity, regulatory constraints? |
 | Q9 | Integration points | External systems, APIs, or services this must work with? |
 | Q10 | Timeline / cost ceiling | Time constraint? Budget ceiling? Priority vs. other work? |
 **Stopping rules (binding):**
 - **Proceed as soon as Q1 (Scope) is answered.** Q1 is the only question that is always asked. Every question after Q1 is optional.
 - The operator can stop at any Q with `skip` or `you decide` — treat that dimension as "you decide" in the frozen brief.
 - The operator can also steer: `ask all 10`, `ask just Q5 and Q7`, or `skip the rest`. Honor exactly.
 - The operator can say `proceed` at any point to freeze the brief immediately with whatever has been collected.
 - **Hard cap at 10.** Do not ask an 11th question.
 - The dispatcher does NOT poll after handing off. Once the brief is frozen, dispatch and exit (see §5.3, §5.4).
 **Load-bearing test (the only rule that matters):** before asking Q_n, ask yourself "is this dimension load-bearing for THIS topic?" If Q4 is asking about known unknowns and the operator's topic is a trivial 3-line config change, skip Q4. If Q8 is asking about security and the operator's topic is a local-only single-user shell alias, skip Q8. The operator is paying for every question; only ask the ones whose answer changes the plan.
 **Mode flags (collected during the brief):**
 - `--no-research` — skip Phase 1 and Phase 5. The curator goes straight from brief → assembly. Reflect this in the brief's `Mode flags:` line.
 **Frozen brief format (the exact text the curator receives — the curator prompt's `=== FROZEN BRIEF ===` block):**
 ```
 === FROZEN BRIEF BEGIN ===
 Topic: <topic from operator>
 Target save dir: ~/workspace/<current-workspace>/plans/
 Q1 (Scope):         <operator's answer or "you decide">
 Q2 (Constraints):   <operator's answer or "you decide">
 Q3 (Success):       <operator's answer or "you decide">
 Q4 (Unknowns):      <operator's answer or "you decide">
 Q5 (Users):         <operator's answer or "you decide">
 Q6 (Out-of-scope):  <operator's answer or "you decide">
 Q7 (Performance):   <operator's answer or "you decide">
 Q8 (Security):      <operator's answer or "you decide">
 Q9 (Integration):   <operator's answer or "you decide">
 Q10 (Timeline):     <operator's answer or "you decide">
 Mode flags:         <none, or e.g. --no-research>
 === FROZEN BRIEF END ===
 ```
 ### 5.3 Curator dispatch (the actual `hermes` command)
 After the brief is frozen, the dispatcher composes the full prompt by concatenating, in this order:
 1. **The curator framing prompt** — the verbatim contents of `references/curator-framing-prompt.md`. Read it from disk with `read_file`; do not paraphrase, do not summarize.
 2. **The frozen brief block** — the `=== FROZEN BRIEF BEGIN ... END ===` block from §5.2 above, with the operator's actual answers substituted in.
 The composed prompt is one string. It is passed to the curator via the standard `ask hermes` one-shot invocation:
 ```bash
 hermes -p general chat -q "<COMPOSED_PROMPT>" -Q --max-turns 600 --yolo
 ```
 **Flag rationale (matches `ask-hermes` skill v4.2 conventions):**
 - `-p general` — required profile flag; the curator runs on the general profile, not dev/research.
 - `chat -q "..."` — headless one-shot, no interactive REPL. The REPL mode produces unreadable ANSI redraw noise.
 - `-Q` — one-shot mode, no REPL.
 - `--max-turns 600` — the operator's "no turn restriction, correctness over speed" rule. 600 is a safety net, not a budget. The `create-plan` curator always uses 600 (per `ask-hermes` Turn Budget section, override for plan-building).
 - `--yolo` — required for headless execution; approval prompts fail closed (60s timeout → deny) without it. The hardline blocklist still applies.
 - **NO `--model` override.** The general profile's default model is the source of truth. Do not pass `--model`. The curator must NOT receive a model override.
 **Pre-dispatch reasoning check (MANDATORY — run before dispatching):**
 Before invoking the command above, verify the **general profile's** `agent.reasoning_effort` is at the maximum the deployed model supports. (The `references/curator-framing-prompt.md` does an analogous check for the research profile inside Phase 1; the dispatcher does the general-profile check here before spawning the curator.)
 ```bash
 # 1. Read general profile's current model + reasoning_effort
 grep -E "default:|reasoning_effort:" ~/.hermes/profiles/general/config.yaml | head -5
 # 2. If reasoning_effort is NOT at max for the model:
 #    - minimax-m3:cloud → 'xhigh' (supports it)
 #    - deepseek-v4-pro:cloud / glm-5.2:cloud → 'max' (xhigh rejected)
 #    - if unsure → 'max' (safe universal default)
 hermes -p general config set agent.reasoning_effort xhigh
 # OR for models that reject xhigh:
 hermes -p general config set agent.reasoning_effort max
 ```
 **Hard gate:** do not dispatch the curator without this check. The `ask-hermes` skill v4.2 documents this exact check (Pre-Dispatch Reasoning Check section); the dispatcher runs it once at the top of the curator dispatch.
 **Prompt composition rule (binding):** the composed prompt is the curator framing prompt + the frozen brief, concatenated. Do NOT inline `references/deep-research-dispatch-template.md` or `references/ask-claude-validation-template.md` in the dispatcher's prompt — the curator framing prompt already references them inline. The dispatcher does not pre-dispatch the research or claude calls; the curator does that itself in Phases 1 and 4. One curator session per plan. (See §6 Session Management.)
 ### 5.4 Capture and handoff (curator_session_id is the resume handle)
 When the `hermes -p general chat -q "..." -Q --max-turns 600 --yolo` command runs, the output has this shape:
 ```
 session_id: <id>
 <the curator's response — usually a one-line "acknowledged, starting Phase 1" or a focused question back to the operator>
 ```
 **Capture rule (binding):** **Output line 1 is `session_id: <id>` — capture that exact value.** This is the `curator_session_id`. The operator resumes the curator with this id; the dispatcher does not poll, does not process the curator's response further, does not run any follow-up turns.
 **Empirical verification requirement (per `plan_skill_plan.md` §6 pitfall #10 and §7 verification checklist):** before declaring this skill buildable, the dispatcher (or its first-run tester) must empirically confirm that line 1 of `ask-hermes` output IS the session id. This is a first-run failure risk: if the `ask-hermes` banner format changes (warning line, blank line, config notice, or a different hermes version precedes the session id with extra output), the dispatcher captures garbage, prints a broken resume command, and the operator cannot resume the plan. If capture is unreliable, fall back to a JSON-output flag or whatever documented mechanism `hermes` exposes to return the session id (out of scope for this skill to fix the underlying Hermes behavior).
 **Handoff output (the dispatcher's final response to the operator):**
 ```
 === CREATE-PLAN DISPATCH COMPLETE ===
 curator_session_id: <id from line 1>
 frozen_brief_topic: <the topic string>
 target_save_dir: ~/workspace/<current-workspace>/plans/
 mode_flags: <none | --no-research | etc.>
 The curator now owns Phases 1–6 (research → assemble → self-review → Claude evidence-diff → URL re-verify → reconcile).
 The dispatcher will not poll. To check progress, add constraints, or request re-validation:
  ask hermes --resume <curator_session_id> '...'
 Resume the curator (NOT this dispatcher) for any follow-up. Expected deliverables:
 - <topic>_plan.md (actionable, validated)
 - <topic>_research.md (evidence + Phase 5 re-verify log)
 === CREATE-PLAN DISPATCH COMPLETE ===
 ```
 **What the dispatcher does NOT do after this:**
 - Does NOT poll the curator.
 - Does NOT process the curator's response further (it may be a one-line "Phase 1 starting" or a focused clarifying question — relay verbatim or, if a question, surface it to the operator; either way, do not run a `--resume` turn on the operator's behalf).
 - Does NOT itself run deep-research, ask-claude, or any other dispatch.
 - Does NOT write `<topic>_plan.md` or `<topic>_research.md` — the curator is the sole writer of those files.
 - Does NOT execute the plan (out of scope for this skill).
 ### 5.5 Cross-references (the three references/ files)
 The curator prompt embeds the two dispatch-template references inline; the dispatcher itself does not inline them. The full set of `references/` files the curator prompt pulls from:
 - `references/curator-framing-prompt.md` — the curator identity + pipeline + frozen-brief block + Phase 1–6 instructions. The dispatcher reads this file and concatenates it with the frozen brief to compose the dispatch prompt (§5.3).
 - `references/deep-research-dispatch-template.md` — referenced from the curator prompt; used inside Phase 1 to dispatch deep-research. The dispatcher does NOT touch this file.
 - `references/ask-claude-validation-template.md` — referenced from the curator prompt; used inside Phase 4 to dispatch the ask-claude evidence-diff. The dispatcher does NOT touch this file.
 `references/structured-brief-10q.md` is the reusable 10-question brief template (see See Also).
 ## 6. Session Management
 - **One curator session per plan.** Capture `curator_session_id` from output line 1 of the ask-hermes dispatch.
 - **Resume the curator for:** continuing the brief, adding sections, requesting re-validation, asking the curator to expand a phase.
 - **Never resume across topics.** Same plan = resume, different plan = fresh curator session.
 - **deep-research sessions are NOT resumed by the curator.** Curator captures the `<topic>_research.md` output and moves on; the research session expires naturally.
 - **ask-claude sessions are NOT resumed.** Claude is one-shot for the validation pass. Re-validation = fresh Claude session.
 - **Dispatcher is one-shot.** The dispatcher does NOT poll. Operator resumes the curator for follow-up.
 **Pre-build check — verify line-1 capture (per `~/workspace/general/plan_skill_plan.md` §7, pitfall #10):**
 Before declaring the skill buildable, the dispatcher must empirically confirm that line 1 of `ask-hermes` output is the session id. This is a **first-run failure risk**: if the `ask-hermes` banner format changes (warning line, blank line, config notice) or if a different hermes version precedes the session id with extra output, the dispatcher captures garbage, prints a broken resume command, and the operator cannot resume the plan. If capture is unreliable, fall back to a JSON-output flag or whatever documented mechanism `hermes` exposes to return the session id (out of scope for this skill to fix the underlying Hermes behavior).
 ## 7. Output Files
 - **`<topic>_plan.md`** — the actionable plan. Pinned filename. Date in frontmatter, not filename. Single writer: the curator.
 - **`<topic>_research.md`** — the research evidence. Pinned filename. Curator is the **sole writer**. Phase 5 re-verify log is appended in-place.
 - **Default save location:** `~/workspace/<current-workspace>/plans/`. Override with explicit path in the brief.
 - **Phase 5 validation log:** appended to `<topic>_research.md` (not a separate file). Contains: re-fetched URL, what was confirmed, any version/command drift found.
 **Same-topic clobber guard (per `~/workspace/general/plan_skill_plan.md` §7.5):** The curator checks for an existing `<topic>_plan.md` in the target dir. If found, the curator renames the existing file to `<topic>_plan.<timestamp>.bak.md` and saves the new plan to the canonical `<topic>_plan.md`. The operator can recover the prior version from the .bak.md file. Prevents silent clobber under `--yolo`.
 ## 8. Common Pitfalls (from plan §6, verbatim)
 1. **Don't dispatch deep-research without a focused question.** Phase 0's brief (especially Q1 scope) must produce a focused research question. Vague → deep-research burns turns on landscape.
 2. **Don't paraphrase the research in assembly.** Phase 2 copies structured data verbatim. Versions, code blocks, official URLs — copy as-is. Summarizing these is how plans get stale.
 3. **Don't skip Phase 3 (curator self-review).** The first assembly is rough. The curator's self-review catches obvious gaps before Claude sees them.
 4. **Don't ask Claude to fix the plan — only to find flaws.** The curator applies changes. Claude's role is adversary, not editor.
 5. **Don't resume across topics.** Same plan = resume. Different plan = fresh curator session.
 6. **Don't try to use the dispatcher session for follow-up.** The dispatcher is a one-shot. Resume the curator.
 7. **The research.md is evidence, not a deliverable.** Users see the plan, not the research. research.md is for the curator's reference and future audits. Curator is the SOLE writer of this file.
 8. **Don't skip Phase 5 (URL re-verify) — that's the only step that catches stale versions.** Claude can't verify currency; the curator must re-fetch official URLs and confirm.
 9. **The 10-Q brief widens the plan's claim surface.** A fuller brief (security, integration, perf answers) means the plan may cite more tools → Phase 5's 3-URL re-verify cap is a real under-coverage risk. If the plan cites many tools, the operator should resume the curator to request additional URL re-verification.
 10. **The session-id capture ("from output line 1") is positional parsing.** If the `ask-hermes` banner format changes (warning line, blank line, config notice) or if a different hermes version precedes the session id with extra output, the dispatcher captures garbage, prints a broken resume command, and the operator cannot resume the plan. **This is a first-run failure risk.** The skill SHOULD empirically verify line-1 capture against the deployed hermes version before declaring the skill buildable. If capture is unreliable, use a JSON-output flag or whatever documented mechanism `hermes` exposes to return the session id (out of scope for this skill to fix the underlying Hermes behavior).
 11. **Phase 4 (Claude evidence-diff) only sees the structured-claims extract, not the full research.md.** The curator's self-review (Phase 3) is the safety net for findings that fall outside the extract.
 ## 9. Verification Checklist (from plan §7, verbatim)
 - [ ] Phase 0 brief captured (1-10 operator answers, or operator said "you decide")
 - [ ] **`curator_session_id` capture verified** — empirically confirmed that line 1 of `ask-hermes` output is the session id (per pitfall #10; do this BEFORE declaring build complete)
 - [ ] **Dispatcher Section 5 has trigger phrases (5.1), 10-Q script (5.2), curator dispatch command (5.3), and capture/handoff format (5.4)** — the dispatcher can fire on the four trigger phrases, ask up to 10 questions with the documented stopping rules, dispatch `hermes -p general chat -q "..." -Q --max-turns 600 --yolo` after the brief is frozen, capture the `curator_session_id` from output line 1, and print the resume instruction to the operator.
 - [ ] `<topic>_research.md` exists with research evidence
 - [ ] `<topic>_plan.md` exists. Every task is 2-5 min of focused work, has exact file paths, complete code blocks, and a TDD cycle (failing test → run-fail → implement → run-pass → commit).
 - [ ] ask-claude validation report received (release-blockers / med / low)
 - [ ] Phase 5 URL re-verify log appended to `<topic>_research.md`
 - [ ] All release-blockers and agreed changes applied
 - [ ] `curator_session_id` returned to user
 - [ ] No execution of the plan attempted (out of scope for this skill)
 **Conditional on `--no-research`:** If operator passed `--no-research`, the `<topic>_research.md` requirement and Phase 5 URL re-verify are SKIPPED. The Claude template's "URL currency" checks are also void in this mode. Final plan reflects this explicitly in its header.
 ## 10. Failure Modes (from plan §7.5, verbatim)
 - **ask-claude unreachable (10.0.0.28 down / network error / session budget):** Curator finalizes the plan WITHOUT the adversarial pass. Appends a header note: "Adversarial validation skipped — ask-claude unreachable. Recommend manual review before building." Continues to Phase 6.
 - **deep-research errors out:** Curator retries ONCE with the same prompt. If still failing, finalizes plan with header note: "Research phase failed. Plan based on operator-provided brief only. Currency cannot be guaranteed."
 - **curator's own session expires (~5h idle):** On the operator's next resume, the ask-hermes session returns an expired-session error. The operator starts a fresh plan build. The expired session is not auto-resumed.
 - **same-topic plan already exists:** The curator checks for an existing `<topic>_plan.md` in the target dir. If found, the curator renames the existing file to `<topic>_plan.<timestamp>.bak.md` and saves the new plan to the canonical `<topic>_plan.md`. The operator can recover the prior version from the .bak.md file. Prevents silent clobber under `--yolo`.
 - **operator adds new constraints mid-pipeline:** Operator resumes the curator. Curator classifies the constraint: if it affects the plan's architecture (security model, data flow, integration points), re-run Phases 2-4. If it's tactical (a flag value, a path, a UI affordance), apply forward and note the change in the plan header.
 ## See Also
 - `references/structured-brief-10q.md` — the 10-question brief template (reusable for any non-trivial delegated work, not just plans)
 - `references/curator-framing-prompt.md` — the actual prompt the dispatcher sends to the curator (Phases 1-6)
 - `references/deep-research-dispatch-template.md` — the Phase 1 research dispatch template
 - `references/ask-claude-validation-template.md` — the Phase 4 evidence-diff prompt template
 - `writing-plans` skill — Phase 2 methodology
 - `subagent-driven-development` skill — for executing the plan after delivery
 - `ask-hermes` / `ask-claude` / `deep-research` skills — peer dispatch patterns
 - `references/multi-round-validation-pattern.md` (in subagent-driven-development) — for the multi-round validation protocol used in plan-build
--- a/create-plan/references/ask-claude-validation-template.md
+++ b/create-plan/references/ask-claude-validation-template.md
@@ -0,0 +1,234 @@
 # Ask-Claude Validation Template — `create-plan` Phase 4
 > **This is the exact prompt + dispatch script the curator uses in Phase 4 to run the adversarial evidence-diff against `<topic>_plan.md` v2.** The curator fills in `<PLAN_BODY>` (full plan) and `<RESEARCH_CLAIMS_EXTRACT>` (~10KB cap) and dispatches to Claude Opus on 10.0.0.28. Output: a release-blockers / medium / low validation report. The curator applies agreed findings in Phase 6 — Claude does NOT rewrite the plan.
 ---
 ## 1. The Prompt (the exact text shipped to Claude)
 The curator assembles this string, then writes it to a temp file (scp pattern — never inline in the SSH command; shell metacharacters in the plan body will break):
 ```
 ==== PLAN BEGINS ====
 <PLAN_BODY>
 ==== PLAN ENDS ====
 ==== RESEARCH CLAIMS/CITATIONS EXTRACT BEGINS ====
 <RESEARCH_CLAIMS_EXTRACT>
 ==== RESEARCH CLAIMS EXTRACT ENDS ====
 You are reviewing an evidence-diff for a software plan. Below is:
 1. The plan in full.
 2. An extract of the structured claims, version numbers, official-URL
   citations, and key code/config snippets from the research evidence.
 CRITICAL CONSTRAINT: Do NOT propose new features, new architecture, or new complexity.
 Your job is to find FLAWS in what's already proposed — not to add more. If you find
 a problem, say what's wrong and suggest the SIMPLEST fix.
 YOUR JOB IS AN EVIDENCE-DIFF, NOT A VIBE CHECK.
 For each claim the plan makes, check whether the provided research extract supports it.
 For each claim in the provided research extract, check whether the plan addresses it.
 Specifically report:
 - Plan assertions that the research extract does NOT support (hallucinated claims)
 - Major research extract findings the plan OMITS (silent gaps)
 - Internal contradictions in the plan
 - Missing TDD discipline (failing test before code-producing task?)
 - Tasks larger than 2-5 minutes of focused work
 - Missing official doc citations for tools the plan uses
 Report format:
 - Release-blockers (must fix)
 - Medium (should fix)
 - Low (nice to have)
 - Pass-criteria met / not met
 Do not rewrite the plan. Just report findings.
 ```
 ### 1.1 Note on Claude's capabilities / scope
 Claude (Opus on 10.0.0.28) has **no web access** and cannot read the curator's local filesystem. Do NOT ask Claude to verify URL currency or file existence — those are the curator's job in Phase 5. Claude's job here is purely a structured text-vs-text diff against the inlined payloads.
 ### 1.2 Why "2-3 concrete suggestions" from the upstream pattern is dropped
 The upstream `ask-claude` plan-validation prompt ends with "give 2-3 concrete suggestions for how to make this plan better." That suggestion-generating mode is **incompatible** with our CRITICAL CONSTRAINT (no new features, no new architecture, no new complexity). Suggestions would either be empty (waste of Claude's pass) or contradict the constraint. The template is deliberately narrower than the upstream pattern: pure flaw-finding, no improvement generation. If the operator wants improvement suggestions, that's a separate dispatch, not this validation pass.
 ### 1.3 Payload delimiters (must be present, exactly)
 | Delimiter | Purpose |
 |---|---|
 | `==== PLAN BEGINS ====` ... `==== PLAN ENDS ====` | Wraps the full `<topic>_plan.md` v2. |
 | `==== RESEARCH CLAIMS/CITATIONS EXTRACT BEGINS ====` ... `==== RESEARCH CLAIMS EXTRACT ENDS ====` | Wraps the extracted claims/citations section. |
 The framing text and validation instructions follow BOTH delimiters (not inside the plan or research payload). Claude reads the instructions last and knows the markers are structural, not part of the text being reviewed.
 ---
 ## 2. The Research Payload — Size Discipline (MANDATORY)
 The curator reads `<topic>_research.md` from disk and extracts **only the structured-claims/citations section**, not the full document. Inline that extract, not the full research.md.
 **Extract these sections from `<topic>_research.md`:**
 - Key Findings (claim + source URL pairs)
 - Version Numbers & Currency Notes
 - Official Documentation Citations
 - Key Code / Config Snippets (verbatim — do not paraphrase)
 - Conflicts / Open Questions
 **Skip these sections:**
 - The narrative Summary (Claude cannot verify prose; the curator's self-review, Phase 3, already covered it)
 - Any other long-form discussion paragraphs
 **Cap the inlined research payload at ~10KB.** Claude's context is not free, and a 50KB research.md will burn tokens on prose Claude cannot meaningfully diff against the plan anyway. The full research.md remains on disk for the curator's reference.
 **Accepted trade-off:** Claude cannot detect findings in the research that live outside the extracted claims/citations (long prose paragraphs, narrative context, exploratory tangents). This is a known limitation, not a bug. The structured-claims extract is the load-bearing evidence; the curator's self-review (Phase 3) is the safety net for the rest. Document this trade-off in the final plan header so future readers know what Claude actually saw.
 ---
 ## 3. The Dispatch Script (parameterized, ready to run)
 ```bash
 # 1. Build the prompt (see §1 for the full template)
 PROMPT="==== PLAN BEGINS ====
 $(cat <topic>_plan.md)
 ==== PLAN ENDS ====
 ==== RESEARCH CLAIMS/CITATIONS EXTRACT BEGINS ====
 $(cat <research_claims_extract.md>)
 ==== RESEARCH CLAIMS EXTRACT ENDS ====
 You are reviewing an evidence-diff for a software plan. Below is:
 1. The plan in full.
 2. An extract of the structured claims, version numbers, official-URL
   citations, and key code/config snippets from the research evidence.
 CRITICAL CONSTRAINT: Do NOT propose new features, new architecture, or new complexity.
 Your job is to find FLAWS in what's already proposed — not to add more. If you find
 a problem, say what's wrong and suggest the SIMPLEST fix.
 YOUR JOB IS AN EVIDENCE-DIFF, NOT A VIBE CHECK.
 For each claim the plan makes, check whether the provided research extract supports it.
 For each claim in the provided research extract, check whether the plan addresses it.
 Specifically report:
 - Plan assertions that the research extract does NOT support (hallucinated claims)
 - Major research extract findings the plan OMITS (silent gaps)
 - Internal contradictions in the plan
 - Missing TDD discipline (failing test before code-producing task?)
 - Tasks larger than 2-5 minutes of focused work
 - Missing official doc citations for tools the plan uses
 Report format:
 - Release-blockers (must fix)
 - Medium (should fix)
 - Low (nice to have)
 - Pass-criteria met / not met
 Do not rewrite the plan. Just report findings."
 # 2. Write locally → scp to remote → run via ask.sh (file-based, no shell escaping)
 echo "$PROMPT" > /tmp/curator-claude-prompt.txt
 scp -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new -o ServerAliveInterval=30 /tmp/curator-claude-prompt.txt n8n@10.0.0.28:/tmp/curator-claude-prompt.txt
 RESP=$(ssh -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new -o ServerAliveInterval=30 n8n@10.0.0.28 '~/claude/hermes_support/ask.sh --qfile /tmp/curator-claude-prompt.txt')
 echo "$RESP"
 rm -f /tmp/curator-claude-prompt.txt
 ```
 **Flag rationale (per `ask-claude` v2.6.1):**
 - `-i ~/.ssh/id_ed25519` — required key
 - `-o StrictHostKeyChecking=accept-new` — first-time host key trust without prompting
 - `-o ServerAliveInterval=30` — Opus turns can run 45-90s; prevents silent SSH drop
 - `ask.sh --qfile <path>` — file-based, no shell metacharacter issues; the wrapper handles mktemp snapshot + claude invocation + merge.py internally
 - **Never use `--resume`** for this validation role — Claude is one-shot for the evidence-diff. Re-validation is a fresh dispatch.
 ---
 ## 4. Parse the Response (one-shot, not a resumed session)
 `ask.sh` returns JSON. Extract the two fields that matter:
 ```bash
 # Claude's findings text
 RESULT=$(echo "$RESP" | python3 -c "
 import sys, json
 try:
    d = json.load(sys.stdin)
 except:
    print('ERROR: non-JSON response'); sys.exit(0)
 subtype = d.get('subtype','')
 if subtype == 'error_max_turns':
    print('ERROR: max turns reached')
 elif d.get('is_error'):
    print(f'ERROR: {subtype} - {d.get(\"result\",\"\")}')
 else:
    print(d.get('result','(empty)'))
 ")
 # session_id — CAPTURED but NOT USED to resume
 # Per the rules: re-validation = fresh dispatch. The session_id is recorded for the
 # audit log only. Do not pass --resume on any follow-up.
 SID=$(echo "$RESP" | python3 -c "
 import sys, json
 try: print(json.load(sys.stdin).get('session_id',''))
 except: print('')
 ")
 ```
 **Mandatory spot-checks (run before applying anything):**
 | Check | Field | If true, do what |
 |---|---|---|
 | JSON parsed cleanly | n/a | If non-JSON, treat as failure → §5 |
 | `is_error: true` | top-level | Treat as failure → §5 |
 | `subtype: error_max_turns` | top-level | Treat as failure → §5 (note: `is_error` is `false` on this one — must check `subtype` explicitly) |
 | `subtype: error_budget` | top-level | Treat as failure → §5 |
 | `result` field is empty string | top-level | Treat as failure → §5 |
 | `result` field has Claude's findings | top-level | Run the disagreement scan (ask-claude §3.5) before applying |
 **Do not resume the Claude session under any circumstance.** A fresh `ask-claude` dispatch is a one-shot for the evidence-diff role. If a re-validation is needed (e.g., the curator applied Phase 6 fixes and wants Claude to take another pass), that is a **fresh dispatch** with a fresh prompt, not `--resume <old_sid>`.
 ---
 ## 5. Failure Handling (one-liner behavior)
 **If ask-claude is unreachable (10.0.0.28 down / network error / `error_budget` / `error_max_turns` / non-JSON / empty response):**
 > Finalize the plan WITHOUT the adversarial pass. Append a header note to `<topic>_plan.md`:
 > `"Adversarial validation skipped — ask-claude unreachable. Recommend manual review before building."`
 > Continue to Phase 5 (if not `--no-research`) and Phase 6. Surface the skip in the final curator handoff so the operator knows the plan was not adversarially reviewed.
 **Do not retry.** Ask-claude unreachability is a transport/infrastructure failure, not a prompt-quality problem. Retrying just burns curator turns. One skip, one header note, move on. The operator can manually re-run Phase 4 by resuming the curator.
 ---
 ## 6. Disagreement Scan (after Claude responds — MANDATORY before applying)
 Per `ask-claude` v2.6.1 §3.5, run the disagreement scan on Claude's response **before** applying any of its findings. The curator classifies each item (release-blocker / medium / low) as:
 - **Agree + will apply** → note for Phase 6 reconcile
 - **Agree + will skip** → state explicitly WHY (overkill, environment constraint, contradicts brief, contradicts operator's standing rule, etc.). Never silently drop.
 - **Disagree** → decide it's not worth a round-trip and state your reason. **Do not resume Claude to push back** — re-validation is a fresh dispatch. If the disagreement is load-bearing, the operator can resume the curator to escalate.
 - **Web references requested** → for any Claude claim that is a tool version, API behavior, library status, compatibility statement, or "best practice" assertion AND Claude did not cite a source URL inline — treat the claim as unverified. The curator's Phase 5 URL re-verify covers currency; for factual claims that should have come from the inlined research extract but don't, that's a finding to record.
 - **Internal consistency check** → does Claude's response contradict itself, or contradict a prior finding in this same Phase 4? If yes, note it but do not chase it down — flag in the plan header.
 - **Silently dropped** → should be empty. If non-empty, that's a bug. Surface it in the Phase 6 handoff.
 Include a brief disagreement-scan recap in the plan header (see `curator-framing-prompt.md` Step 6.2) so future readers see what was considered and rejected.
 ---
 ## 7. What the Curator Hands Off to Phase 6
 After Phase 4 completes, the curator has:
 1. Claude's raw response (the `result` field) — kept in the curator session for reference
 2. The session_id — recorded for the audit log, **not** used to resume
 3. The classified list of findings (release-blockers / medium / low) with per-item disposition from §6
 4. The disagreement-scan output (for the plan header)
 Phase 6 applies the agreed findings + any URL re-verify mismatches from Phase 5. Claude's role ends here.
 ---
 **Pipeline position:** Phase 0 (dispatcher, brief) → Phase 1 (curator → deep-research) → Phase 2 (curator, assemble) → Phase 3 (curator, self-review) → **Phase 4 (curator → ask-claude, this template)** → Phase 5 (curator, URL re-verify) → Phase 6 (curator, reconcile).
--- a/create-plan/references/curator-framing-prompt.md
+++ b/create-plan/references/curator-framing-prompt.md
@@ -0,0 +1,430 @@
 # Curator Framing Prompt — `create-plan` Pipeline (Phases 1–6)
 > **This file is the exact prompt the dispatcher sends to a fresh `ask-hermes` session to start a plan build.** A fresh peer Hermes agent receiving only this prompt + the operator's frozen brief should be able to execute the full 7-phase pipeline (Phases 1–6; Phase 0 is the dispatcher's job) and produce `<topic>_plan.md` + `<topic>_research.md`.
 ---
 ## 0. Identity & Mission
 You are the **curator**. A dispatcher (the `create-plan` skill) has already completed **Phase 0** — the interactive brief with the operator. The dispatcher's output is the **frozen brief** below. The dispatcher expects you to own **Phases 1–6** end-to-end and report back when the plan is finalized.
 **Your mission:** Run the 6-phase plan-build pipeline (Phases 1–6; the dispatcher runs Phase 0). Produce two files:
 1. `<topic>_plan.md` — the actionable, validated, bite-sized implementation plan (the user-facing deliverable)
 2. `<topic>_research.md` — the research evidence + the Phase 5 re-verify log (curator is the sole writer)
 The 600-turn ceiling is a safety net, not a budget. Correctness > speed. Take as long as you need. The operator has explicitly said no turn restriction for evidence-based plan builds.
 **You are a peer agent, not a chatbot.** Be direct, imperative, and specific. Cite commands, paths, and behaviors. Do not narrate your reasoning at length — execute.
 **Begin with the pre-dispatch reasoning check (§2), then Phase 1.**
 ---
 ## 1. The Frozen Brief (Phase 0 output)
 The dispatcher has already asked the operator up to 10 clarifying questions in priority order (Q1 scope → Q2 constraints → Q3 success → Q4 unknowns → Q5 users → Q6 out-of-scope → Q7 perf → Q8 security → Q9 integration → Q10 timeline) and frozen the answers below. **Do not re-ask these questions.** The operator has signed off on this brief; treat it as the starting point.
 ```
 === FROZEN BRIEF BEGIN ===
 Topic: <topic from operator>
 Target save dir: ~/workspace/<current-workspace>/plans/
 Q1 (Scope):         <operator's answer or "you decide">
 Q2 (Constraints):   <operator's answer or "you decide">
 Q3 (Success):       <operator's answer or "you decide">
 Q4 (Unknowns):      <operator's answer or "you decide">
 Q5 (Users):         <operator's answer or "you decide">
 Q6 (Out-of-scope):  <operator's answer or "you decide">
 Q7 (Performance):   <operator's answer or "you decide">
 Q8 (Security):      <operator's answer or "you decide">
 Q9 (Integration):   <operator's answer or "you decide">
 Q10 (Timeline):     <operator's answer or "you decide">
 Mode flags:         <none, or e.g. --no-research>
 === FROZEN BRIEF END ===
 ```
 If the operator passed `--no-research`, **skip Phase 1 and Phase 5** and reflect that explicitly in the plan header. The rest of the pipeline (2–4, 6) still runs. The Claude template's URL-currency checks are void in this mode.
 ---
 ## 2. Pre-Dispatch Reasoning Check (MANDATORY — before Phase 1)
 Before dispatching Phase 1's deep-research, verify the **research profile's** `agent.reasoning_effort` is at the maximum the deployed model supports. This is a hard gate — do not dispatch without it.
 ```bash
 # 1. Read research profile's current model + reasoning_effort
 grep -E "default:|reasoning_effort:" ~/.hermes/profiles/research/config.yaml | head -5
 # 2. If reasoning_effort is NOT at max:
 hermes -p research config set agent.reasoning_effort max
 # (Use 'xhigh' for models that support it; 'max' is the safe universal default.)
 ```
 The research profile's reasoning effort is the one that matters for the dispatch — your own (general) profile is already configured. Do not modify it.
 `max` is the highest effort setting universally supported by all models. If you don't know the model's max, default to `max`. Do not dispatch until this is confirmed.
 ---
 ## 3. The Pipeline (Phases 1–6)
 ### Phase 1 — Evidence gathering `[curator → deep-research]`
 **Goal:** Produce exhaustive, current, evidence-backed research that the plan will cite.
 **Step 1.1:** Derive a **focused research question** from the frozen brief. The Q1 (Scope) answer is your anchor. The question must be narrow enough to drive 3+ search angles, but broad enough to cover all phases of the plan. Example transformation: scope "cron job that backs up workspace daily" → research question "Current best-practice for daily backup cron job in 2026: scheduling tool, deduplication, retention, encryption at rest, restore verification, integration with rsync/restic/borg, alerting on failure."
 **Step 1.2:** Dispatch `deep-research` to the research profile:
 ```bash
 hermes -p research -s deep-web-research chat -q "<focused research question derived from frozen brief>" -Q --max-turns 600 --yolo
 ```
 **Step 1.3:** Capture the output. The research agent writes its full findings to `/tmp/research-<sid>.md` (external ledger) and emits a condensed answer. **Read both** — the ledger has the evidence, the condensed answer has the synthesis.
 **Step 1.4:** Write `<topic>_research.md` to the target save dir. You are the **sole writer** of this file. Structure:
 ```markdown
 # <Topic> — Research Evidence
 > **Curator file.** Generated during Phase 1 of the create-plan pipeline. This file is evidence, not a deliverable. Users see the plan, not this research.
 **Date:** <YYYY-MM-DD>
 **Research session:** <deep-research session_id>
 **Research question:** <the focused question you dispatched>
 ## Summary
 <3-5 sentence TL;DR of the research>
 ## Key Findings
 - <finding 1 — claim + source URL>
 - <finding 2 — claim + source URL>
 - ...
 ## Version Numbers & Currency Notes
 - <tool/library> — <version> — <source URL> — <verified date>
 - ...
 ## Official Documentation Citations
 - <URL 1> — <what it documents>
 - <URL 2> — <what it documents>
 - ...
 ## Key Code / Config Snippets
 ```<lang>
 <verbatim snippet from research — do NOT paraphrase>
 ```
 ## Conflicts / Open Questions
 - <any contradictions or gaps the research surfaced>
 ## Phase 5 Re-Verify Log
 _(appended below in Phase 5)_
 ```
 **Step 1.5:** **Failure handling** — If `deep-research` errors out, retry ONCE with the same prompt. If it fails again, write the plan with a header note: `"Research phase failed. Plan based on operator-provided brief only. Currency cannot be guaranteed."` Continue to Phase 2 with whatever evidence you have (or skip research-derived steps in the plan).
 **Step 1.6:** Report: `Phase 1 complete — <research.md path>`
 ---
 ### Phase 2 — Plan assembly `[curator]`
 **Goal:** Produce `<topic>_plan.md` v1 by reading research.md and applying `writing-plans` structure.
 **Step 2.1:** Read `<topic>_research.md` from disk (do NOT use cached context — the file is the source of truth).
 **Step 2.2:** Apply `writing-plans` methodology (the `software-development/writing-plans` skill, v1.4.0, defines this). Key rules:
 - **Bite-sized tasks** — 2–5 minutes of focused work each. One action per step. "Write failing test" / "Run to verify fail" / "Implement minimal code" / "Run to verify pass" / "Commit" is the canonical 5-step task shape.
 - **Exact file paths** — every task lists `Create: <path>` and `Modify: <path:line>` explicitly. No "the config file."
 - **Complete code blocks** — copy-pasteable, not "add validation."
 - **Exact commands** with expected output — `pytest tests/... -v` → `3 passed`. No "run the tests."
 - **TDD per task** — failing test before any code-producing step. No TDD = plan gap. (Infra/setup tasks without a test to write are exempt — e.g., "create the directory structure.")
 - **DRY, YAGNI, frequent commits** — one commit per task minimum.
 - **Plan header** — `# [Feature] Implementation Plan` + For-Hermes note + Goal (1 sentence) + Architecture (2–3 sentences) + Tech Stack.
 **Step 2.3:** **Copy structured data verbatim from research.md.** Do NOT paraphrase. The following must be copied as-is:
 - Version numbers (e.g., "Python 3.13" stays "Python 3.13", not "recent Python")
 - Code/config snippets (full blocks, not summaries)
 - Official URLs (exact, not truncated)
 - Command names and flags (exact, not paraphrased)
 - Tool/library names (exact casing)
 Paraphrasing these is how plans get stale. The whole point of Phase 1's research is to capture exact data — Phase 2 is transcription, not summarization.
 **Step 2.4:** Write `<topic>_plan.md` to the target save dir. (Clobber guard happens in Step 6.2, not here — during the pipeline, you write to the canonical name. The check + suffix happens at the end of Phase 6.)
 **Step 2.5:** Report: `Phase 2 complete — <plan.md v1 path>`
 ---
 ### Phase 3 — Curator self-review `[curator]`
 **Goal:** Catch obvious gaps before Claude sees the plan. Two reconciles are required (this + Phase 6) because they catch different classes of issues — author-blindness here, evidence-diff failures there.
 **Step 3.1:** Re-read your own `<topic>_plan.md` from disk with fresh eyes. Check the verification list:
 - [ ] **All phases of the brief covered.** Walk through Q1–Q10. Each answered dimension should have at least one corresponding task or section in the plan. Unanswered dimensions ("you decide") can have any reasonable interpretation — note the interpretation in the plan header.
 - [ ] **File paths exact.** Every `Create:` and `Modify:` resolves to a real path. No relative paths without anchors. No "the config file."
 - [ ] **TDD present per task.** Every code-producing task has: (1) write failing test, (2) run-fail, (3) implement, (4) run-pass, (5) commit. No skipping the test-first step.
 - [ ] **Tasks are 2–5 minutes each.** If a task spans more than ~15 lines of new code, it's probably 2–3 tasks. Split.
 - [ ] **Official docs cited.** Every external tool, library, API, or service the plan uses has at least one official documentation URL in either the task's "Docs to check" line or in the plan's references section.
 - [ ] **Versions explicit.** Every version-dependent dependency has an exact version number, not "latest" or "recent."
 - [ ] **Verification steps concrete.** Every task ends with a runnable verification (command + expected output), not "make sure it works."
 - [ ] **Commit per task.** Every task ends with a `git commit` step.
 **Step 3.2:** Fix gaps inline. Save as `<topic>_plan.md` v2 (overwrite v1 — v1 is a draft, v2 is the self-reviewed version).
 **Step 3.3:** Report: `Phase 3 complete — <plan.md v2 path>, <N gaps fixed>`
 ---
 ### Phase 4 — Adversarial validation `[curator → ask-claude]`
 **Goal:** Run an evidence-diff against the plan. Claude finds flaws — Claude does NOT fix. The curator applies changes in Phase 6.
 **Step 4.1:** Read `<topic>_plan.md` v2 from disk and `<topic>_research.md` from disk.
 **Step 4.2:** **Extract the structured-claims/citations section of research.md.** This is the load-bearing evidence Claude needs. Inline only this section (~10KB cap) plus the full plan. Do NOT inline the full research.md (it can be 50KB+; Claude's context is not free).
 The extracted section should include:
 - Key Findings (claim + source URL pairs)
 - Version Numbers & Currency Notes
 - Official Documentation Citations
 - Key Code / Config Snippets (verbatim)
 - Conflicts / Open Questions
 Skip the narrative Summary section (Claude can't verify prose; you already did in Phase 3).
 **Step 4.3:** Write the validation prompt to a temp file (scp pattern — do NOT inline in SSH command; shell metacharacters will break):
 ```bash
 # Build the prompt
 PROMPT="==== PLAN BEGINS ====
 <full contents of <topic>_plan.md v2>
 ==== PLAN ENDS ====
 ==== RESEARCH CLAIMS/CITATIONS EXTRACT BEGINS ====
 <extracted structured-claims/citations section of <topic>_research.md, ~10KB cap>
 ==== RESEARCH CLAIMS EXTRACT ENDS ====
 You are reviewing an evidence-diff for a software plan. Below is:
 1. The plan in full.
 2. An extract of the structured claims, version numbers, official-URL citations, and key code/config snippets from the research evidence.
 CRITICAL CONSTRAINT: Do NOT propose new features, new architecture, or new complexity. Your job is to find FLAWS in what's already proposed — not to add more. If you find a problem, say what's wrong and suggest the SIMPLEST fix.
 YOUR JOB IS AN EVIDENCE-DIFF, NOT A VIBE CHECK.
 For each claim the plan makes, check whether the provided research extract supports it.
 For each claim in the provided research extract, check whether the plan addresses it.
 Specifically report:
 - Plan assertions that the research extract does NOT support (hallucinated claims)
 - Major research extract findings the plan OMITS (silent gaps)
 - Internal contradictions in the plan
 - Missing TDD discipline (failing test before code-producing task?)
 - Tasks larger than 2-5 minutes of focused work
 - Missing official doc citations for tools the plan uses
 Report format:
 - Release-blockers (must fix)
 - Medium (should fix)
 - Low (nice to have)
 - Pass-criteria met / not met
 Do not rewrite the plan. Just report findings."
 # Write locally, scp to remote, run via ask.sh
 echo "$PROMPT" > /tmp/curator-claude-prompt.txt
 scp -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new -o ServerAliveInterval=30 /tmp/curator-claude-prompt.txt n8n@10.0.0.28:/tmp/curator-claude-prompt.txt
 RESP=$(ssh -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new -o ServerAliveInterval=30 n8n@10.0.0.28 '~/claude/hermes_support/ask.sh --qfile /tmp/curator-claude-prompt.txt')
 echo "$RESP"
 rm -f /tmp/curator-claude-prompt.txt
 ```
 **Step 4.4:** Parse the JSON response. Capture the `result` field (Claude's findings) and `session_id` (for potential follow-up — but per the rules below, do NOT resume Claude for this validator role). Spot-check the response: if `is_error: true` or `subtype: error_max_turns`, treat as failure and skip to the failure-handling step.
 **Step 4.5:** **Failure handling** — If ask-claude is unreachable (10.0.0.28 down / network error / `error_budget` / `error_max_turns`), **finalize the plan WITHOUT the adversarial pass.** Add a header note: `"Adversarial validation skipped — ask-claude unreachable. Recommend manual review before building."` Continue to Phase 5 (if not `--no-research`) and Phase 6.
 **Step 4.6:** Disagreement scan (MANDATORY before applying, per `ask-claude` v2.6.1 §3.5). Walk through Claude's findings (release-blockers, medium, low) and classify each:
 - **Agree + will apply** → note for Phase 6
 - **Agree + will skip** → state explicitly WHY (overkill, environment constraint, contradicts brief, etc.). Never silently drop.
 - **Disagree** → decide it's not worth a round-trip and state your reason. (Curators do not resume ask-claude sessions — re-validation, if needed, is a fresh `ask-claude` dispatch by the operator.)
 - **Web references / live tests requested** → for any Claude claim that is a tool version, API behavior, library status, compatibility statement, or "best practice" assertion AND Claude did not cite a source URL inline, push back: ask for the source URL. (You are the curator, not Claude — web searches are Claude's job in the evidence-diff role. If Claude can't produce a URL, treat the claim as unverified.)
 - **Internal consistency check** → does Claude's response contradict itself, or contradict a prior finding in this same Phase 4? If yes, point it out in the plan header.
 - **Silently dropped** → should be empty. If non-empty, justify.
 Claude is input, not a decision. You own the final call. Do not apply findings wholesale.
 **Step 4.7:** Report: `Phase 4 complete — Claude findings: <N release-blockers, N medium, N low>, applying <list>`
 ---
 ### Phase 5 — URL re-verification `[curator]`
 **Goal:** Re-fetch the URLs backing the SPECIFIC version numbers, commands, and setup steps the **plan** cites (cap at 3). Not "top 3 from research" — the 3 most load-bearing URLs in the plan itself. This is the only step that catches stale versions. Claude can't verify currency (no web access on 10.0.0.28); this is the curator's responsibility.
 **Skip this phase entirely if `--no-research` was passed.**
 **Step 5.1:** From the v2 plan, identify the **3 most load-bearing URLs**. Criteria for "load-bearing":
 - A URL backing a specific version number cited in the plan (e.g., a release page or PyPI page)
 - A URL backing a specific install command or setup step (e.g., an install guide)
 - A URL backing a specific configuration or API behavior the plan depends on (e.g., official API docs)
 If the plan cites fewer than 3 URLs, re-verify all of them. If the plan cites more than 3, prioritize the 3 with the highest "if this is wrong, the whole plan breaks" weight.
 **Step 5.2:** For each of the ≤3 URLs, fetch the current content and check it against the plan's assertion:
 ```bash
 # For each URL:
 mcp_searxng_web_url_read --url "<URL>" --maxLength 5000
 # OR for docs that need a browser:
 mcp_playwright_browser_navigate --url "<URL>"
 ```
 For each, verify:
 - Is the version number cited in the plan still the current/latest? If not, what's the new version?
 - Is the install command / setup step still valid? Any deprecation, renaming, or breaking change?
 - Is the API/config behavior still as documented? Any breaking change?
 **Step 5.3:** Append a re-verify log to `<topic>_research.md` (do NOT create a separate file — keep all evidence in one place for the curator's reference and future audits). Format:
 ```markdown
 ## Phase 5 Re-Verify Log (<YYYY-MM-DD>)
 ### URL 1: <URL>
 - **Plan claim:** <what the plan asserts this URL backs up>
 - **Verified state:** <what the current page says>
 - **Status:** ✅ confirmed / ⚠️ drift detected / ❌ broken
 - **Action needed:** <if any — e.g., "update version from 1.2.3 to 1.4.0", "no change">
 ### URL 2: <URL>
 - **Plan claim:** ...
 - **Verified state:** ...
 - **Status:** ...
 - **Action needed:** ...
 ### URL 3: <URL>
 - ...
 ```
 **Step 5.4:** Report: `Phase 5 complete — re-verified <N> URLs, <N drift(s) found>`
 ---
 ### Phase 6 — Final reconcile `[curator]`
 **Goal:** Apply Claude's agreed findings + URL re-verify mismatches. Produce the final plan. Report the resume handle.
 **Step 6.1:** Open `<topic>_plan.md` v2. Apply the agreed findings from Phase 4 (curator self-review + Claude's agreed-and-applied items) AND any drift fixes from Phase 5.
 Apply rules:
 - **Agreed release-blockers from Claude** → apply.
 - **Agreed medium from Claude** → apply unless the brief explicitly constrains the change away.
 - **Agreed low from Claude** → apply at your discretion; low-priority polish.
 - **Disagreed-from-Claude items** → do not apply. Do not silently drop — the disagreement scan from Phase 4 already justified the rejection.
 - **Drift from Phase 5** → apply the version/command/setup update. If a major API change, flag it in the plan header as "Phase 5 re-verify found drift — review before building."
 - **Disagreement scan output** → include a brief recap in the plan header so future readers see what was considered and rejected.
 **Step 6.2:** **Clobber guard.** Before saving the final plan, check for an existing file at `<topic>_plan.md`:
 ```bash
 ls -la <target_dir>/<topic>_plan.md 2>/dev/null
 ```
 If a file already exists, rename it to `<topic>_plan.<timestamp>.bak.md` (e.g., `<topic>_plan.20260706-114523.bak.md`) so the operator can recover the prior version. Then save your final plan to the canonical `<topic>_plan.md`. Note the backup in the plan header. Prevents silent clobber under `--yolo`.
 Update the plan header to reflect:
 ```markdown
 # [Feature] Implementation Plan
 > **For Hermes:** Use subagent-driven-development skill to implement this plan task-by-task.
 **Goal:** <one sentence>
 **Architecture:** <2-3 sentences>
 **Tech Stack:** <key technologies/libraries>
 **Plan version:** v<N> (final)
 **Curator session:** <curator_session_id> — resume with `ask hermes --resume <curator_session_id>` for iteration, expansion, or re-validation.
 **Validation:** Claude evidence-diff applied (<N> release-blockers, <N> medium, <N> low). <N> URL re-verifications, <N> drift(s) fixed.
 **Disagreement scan:** <N> items agreed+applied, <N> agreed+skipped [reasons], <N> disagreed+rejected [reasons].
 **Failure notes:** <e.g., "Adversarial validation skipped — ask-claude unreachable" or "Research phase failed">
 ```
 **Step 6.3:** Verify all files exist and are non-empty:
 ```bash
 ls -la <target_dir>/<topic>_plan.md <target_dir>/<topic>_research.md
 wc -c <target_dir>/<topic>_plan.md <target_dir>/<topic>_research.md
 ```
 **Step 6.4:** Report the final handoff to the dispatcher. Output format:
 ```
 === CURATOR HANDOFF BEGIN ===
 plan_path: <absolute path to final <topic>_plan.md>
 research_path: <absolute path to <topic>_research.md>
 curator_session_id: <this session's id>
 phases:
  1. research — <one-line summary> (research.md: <path>)
  2. assembly — <one-line summary> (plan.md v1: <path>)
  3. self-review — <one-line summary> (<N> gaps fixed, plan.md v2: <path>)
  4. validate — <one-line summary> (Claude: <N> blockers / <N> med / <N> low; agreed+applied: <N>)
  5. url-reverify — <one-line summary> (<N> URLs re-verified, <N> drift(s) fixed)
  6. reconcile — <one-line summary> (final plan: <path>)
 release_blockers_unresolved: <list, or "none">
 failure_notes: <list, or "none">
 === CURATOR HANDOFF END ===
 ```
 The dispatcher will relay this to the operator along with the resume command: `ask hermes --resume <curator_session_id> '...'`.
 ---
 ## 4. Operational Rules (binding)
 ### 4.1 Session management (binding)
 | Session | Owner | Resumable? |
 |---|---|---|
 | **Curator (this session)** | you | Yes — by the operator only, for iteration on this same plan |
 | **deep-research** | research profile | The curator dispatches exactly one deep-research session per plan; the curator does NOT resume it. (The deep-research skill's own `--resume` rule applies only within that research session's own line of work.) |
 | **ask-claude** | Claude on 10.0.0.28 | No — one-shot for the evidence-diff role. Re-validation is a fresh `ask-claude` dispatch. |
 - **One curator session per plan.** This is your session. You are the resume handle. The dispatcher is one-shot — the operator resumes YOU (not the dispatcher) for follow-up.
 - **Never resume across topics.** Different plan = fresh curator session.
 ### 4.2 Command patterns (binding)
 - **Curator invocation** (already done by dispatcher): `hermes -p general chat -q "..." -Q --max-turns 600 --yolo`
 - **Default model, no override.** Do NOT pass `--model`. The general profile's config is the source of truth for model choice.
 - **deep-research invocation:** `hermes -p research -s deep-web-research chat -q "..." -Q --max-turns 600 --yolo`
 - **ask-claude invocation:** scp + `~/claude/hermes_support/ask.sh --qfile ...` (see Phase 4.3). Always use the scp pattern — never inline prompts in SSH commands.
 - **Sole writer of `<topic>_research.md`:** you. No one else writes to this file.
 - **Clobber guard:** the single source of truth is §6.2 Step 6.2 below (timestamped `.bak.md` rename). Do not run a separate clobber check at write time.
 ### 4.4 Failure modes (binding)
 - **ask-claude unreachable:** Finalize the plan WITHOUT the adversarial pass. Header note: `"Adversarial validation skipped — ask-claude unreachable. Recommend manual review before building."` Continue to Phase 5 (if applicable) and Phase 6.
 - **deep-research fails:** Retry ONCE with the same prompt. If still failing, finalize with header note: `"Research phase failed. Plan based on operator-provided brief only. Currency cannot be guaranteed."` Continue to Phase 2 with whatever evidence you have.
 - **Ceiling hit (600 turns):** Stop and write the current plan with header note `"turn ceiling hit — plan may be incomplete."` Do NOT truncate silently. Better to ship an honest incomplete plan than a confident broken one. **Recovery:** the operator can resume the curator to continue from where it left off, OR start a new curator session that reads the existing `<topic>_research.md` and `<topic>_plan.md` (current state) and picks up from Phase 6 reconcile.
 - **Your session expires (~5h idle):** The operator's next resume returns an expired-session error. **Recovery:** the existing `<topic>_research.md` and `<topic>_plan.md` (if Phase 6 reached) survive on disk. The operator starts a fresh plan build, which reads those files and picks up from wherever the prior session left off. The expired session is not auto-resumed.
 - **Operator adds new constraints mid-pipeline:** They resume you. Classify: architectural (security model, data flow, integration) → re-run Phases 2–4. Tactical (flag value, path, UI affordance) → apply forward and note in the plan header.
 ### 4.5 Tone & output
 See §0 ("You are a peer agent, not a chatbot"). Print a one-line `Phase N complete — <summary>` after each phase.
 ---
 **Pipeline at a glance:** Phase 0 (dispatcher, brief) → Phase 1 (curator → deep-research) → Phase 2 (curator, assemble) → Phase 3 (curator, self-review) → Phase 4 (curator → ask-claude, evidence-diff) → Phase 5 (curator, URL re-verify) → Phase 6 (curator, reconcile). You own Phases 1–6. Begin with §2, then Phase 1.
--- a/create-plan/references/deep-research-dispatch-template.md
+++ b/create-plan/references/deep-research-dispatch-template.md
@@ -0,0 +1,92 @@
 # Deep-Research Dispatch Template — `create-plan` Phase 1
 > **This is the exact prompt template the curator uses in Phase 1 to convert the frozen brief into a focused `deep-research` dispatch.** The curator fills in `<FOCUSED_QUESTION>` from the brief (rules below), runs the pre-dispatch check, and dispatches. Output is captured into `<topic>_research.md`.
 ---
 ## 1. Pre-Dispatch Reasoning Check (MANDATORY)
 Run these commands before dispatching. Hard gate — do not dispatch without it.
 ```bash
 # 1. Read research profile's current model + reasoning_effort
 grep -E "default:|reasoning_effort:" ~/.hermes/profiles/research/config.yaml | head -5
 # 2. If reasoning_effort is NOT at max:
 hermes -p research config set agent.reasoning_effort max
 # (Use 'xhigh' for models that support it; 'max' is the safe universal default.)
 ```
 `max` is the highest effort setting universally supported by all models. The research profile's reasoning effort is the one that matters — your own (general/curator) profile is already configured. Do not modify your own profile.
 ---
 ## 2. The Dispatch Command (parameterized)
 ```bash
 hermes -p research -s deep-web-research chat -q "<FOCUSED_QUESTION>" -Q --max-turns 600 --yolo
 ```
 Flag rationale (matches `deep-research` v2.1.0; `-s deep-web-research` loads the deep-web-research sub-skill of the deep-research dispatcher):
 - `-p research` — required profile flag (sticky default may be general)
 - `-s deep-web-research` — required skill flag; loads the six-move research methodology
 - `-Q` — one-shot mode, no REPL
 - `--max-turns 600` — ceiling, not budget; matches operator's "no turn restriction, correctness over speed" rule
 - `--yolo` — required for headless execution; approval prompts fail closed without it
 - **NO `--model` override** — the research profile's default model is the source of truth
 **Output capture:**
 - Output line 1: `session_id: <id>` — capture this
 - Output line 2+: the research agent's condensed answer (relay verbatim — do not re-condense)
 - The research agent also writes its full findings to `/tmp/research-<sid>.md` (external ledger) — read both
 ---
 ## 3. Focused-Question Derivation (the value-add)
 **Precedence (read first):** Q1 sets the topic, Q2 sets the hard limits, Q3 sets the definition of done, Q4 becomes `CRITICAL:` sub-directions. Q5–Q10 contribute dimensions if relevant.
 The focused question is what makes Phase 1 produce evidence the plan can cite verbatim. Derivation rules:
 1. **Anchor on Q1 (Scope)** from the frozen brief. The scope answer is the topic.
 2. **Add Q2 (Constraints)** as hard limits — must-use / must-avoid / target environment narrow the search space.
 3. **Add Q3 (Success criteria)** as the definition of "done" for the research — what would the research need to find for the plan to be buildable?
 4. **The question must drive 3+ search angles** — multiple source types (official docs, GitHub, PyPI, release notes, tutorials, known-issue trackers).
 5. **The question must justify 600 turns of investigation** — vague questions get shallow landscape passes and burn turns without producing load-bearing evidence.
 6. **Do NOT include the curator's own assumptions** — only constraints derived from the operator's brief answers.
 7. **Q4 (Known unknowns) is always processed.** Concerns the operator named become `CRITICAL:` sub-directions. If Q4 was skipped or answered "none", the question still includes a "common unknowns to disconfirm" clause to ensure disconfirmation discipline (e.g., "CRITICAL: verify no recent CVEs, no deprecation notices, no license changes in the last 12 months").
 **Format (use this skeleton, fill in from the brief):**
 ```
 Exhaustive deep research: [topic from Q1]. [1-2 sentence scope framing from Q1]. Cover: [list of dimensions derived from brief Q2-Q10 if relevant — e.g., scheduling tool, deduplication, retention, encryption, restore verification, alerting]. For each dimension: [what to find — name, current version, official setup steps, hardware/dependency requirements, license, key commands]. CRITICAL: [any specific concerns the operator raised in Q4 — e.g., "must work on NixOS", "avoid Docker", "license must be MIT", "compatibility with Python 3.13"]. Format as comprehensive markdown with full details, options, trade-offs, and source URLs.
 ```
 **Worked example** (Q1 = "cron job that backs up workspace daily"):
 ```
 Exhaustive deep research: daily workspace backup cron job in 2026. A reliable, low-maintenance scheduled backup of a Linux user workspace, run unattended, with restore verification. Cover: scheduling tool (cron vs systemd-timer), backup engine (rsync vs restic vs borg vs btrfs-snap), deduplication strategy, retention policy, encryption at rest, restore verification, alerting on failure, integration with existing cron/systemd on a standard Proxmox host. For each option: current stable version, official setup steps, hardware/disk requirements, license, key commands for backup and restore. CRITICAL: must work on a single-user homelab with no managed monitoring stack; operator wants minimal ongoing maintenance; restore must be testable without overwriting live data. Format as comprehensive markdown with full details, options, trade-offs, and source URLs.
 ```
 ---
 ## 4. Output Handling (read both channels)
 - **Stdout (condensed):** the research agent's terminal output. Synthesis — the answer the research agent already condensed. Relay verbatim, do not re-condense.
 - **External ledger (full):** `/tmp/research-<sid>.md` — every finding, every source URL, every credibility tier. The evidence.
 **Spot-check rule:** the research agent's self-reports are not verified fact. If it claims a specific finding, spot-check the source URL. If it claims a file write, `read_file` the path to confirm.
 The curator captures both and writes `<topic>_research.md` to the target save dir (`~/workspace/<current-workspace>/plans/`). The structure of `<topic>_research.md` is defined in `curator-framing-prompt.md` Step 1.4 — this template is only the dispatch step.
 ---
 ## 5. Failure Handling
 If deep-research errors out, retry ONCE with the same prompt. If still failing, finalize the plan with header note `"Research phase failed. Plan based on operator-provided brief only. Currency cannot be guaranteed."` Continue to Phase 2 with whatever evidence you have (or skip research-derived steps in the plan).
 **Do not retry more than once.** Two failed dispatches means the research profile itself is broken — escalate to operator, do not loop.
 ---
 **Pipeline position:** Phase 0 (dispatcher, brief) → **Phase 1 (this template, deep-research)** → Phase 2 (curator, assemble) → Phase 3 (curator, self-review) → Phase 4 (curator → ask-claude, evidence-diff) → Phase 5 (curator, URL re-verify) → Phase 6 (curator, reconcile).
--- a/create-plan/references/structured-brief-10q.md
+++ b/create-plan/references/structured-brief-10q.md
@@ -0,0 +1,71 @@
 # Structured 10-Question Brief Template
 > **Reusable planning-interview pattern.** Used by `create-plan` Phase 0 (the dispatcher) and any other agent that needs a frozen brief before delegating work. The curator / peer agent receives this brief as inline text and treats it as the starting point — does NOT re-ask these questions.
 ## When to use
 - You (or a dispatcher) are about to dispatch a peer agent for a non-trivial task (plan-build, deep research, design, multi-step implementation).
 - The peer needs a complete, frozen starting point — not a back-and-forth.
 - Operator is willing to spend ~3-5 minutes answering priority-ordered questions before dispatch.
 ## The 10 questions (priority order)
 | # | Dimension | Question | Default if operator says "skip" |
 |---|---|---|---|
 | Q1 | **Scope** | What are we building? What does "done" look like? | Curate from the dispatcher's initial message; if unclear, ask once before proceeding. |
 | Q2 | **Constraints** | Existing infrastructure? Must-use / must-avoid? Target environment? | None — proceed with sensible defaults; flag in the deliverable. |
 | Q3 | **Success criteria** | How will we know it works? Acceptance tests? | Define "done" as "all phases complete and reconciled." |
 | Q4 | **Known unknowns** | What are you uncertain about? Risks? Things that have bitten you before? | Disconfirmation clause in the research question (e.g., "verify no recent CVEs, no deprecation notices, no license changes"). |
 | Q5 | **Target users / audience** | Who's using it? Skill level? | Operator is the default audience unless Q1 names otherwise. |
 | Q6 | **Out of scope** | Explicit non-goals? What are we NOT building? | Nothing — agent produces a comprehensive deliverable; operator trims after. |
 | Q7 | **Performance / scale** | Expected load, latency, throughput targets? | "No explicit targets" — agent picks reasonable defaults and notes the choice. |
 | Q8 | **Security / compliance** | Auth, data sensitivity, regulatory constraints? | Public / local-only by default; flag if scope implies otherwise. |
 | Q9 | **Integration points** | External systems, APIs, or services this must work with? | Agent identifies during research; operator corrects. |
 | Q10 | **Timeline / cost ceiling** | Time constraint? Budget ceiling? Priority vs. other work? | "No ceiling" — agent optimizes for correctness. |
 ## Operational rules
 - **Min as needed, max 10.** Surface only the load-bearing dimensions for THIS topic. If Q1 already names the scope and there are no obvious constraints, ask just Q1 and proceed.
 - **Operator can stop at any Q** with "skip," "you decide," or "ask all 10" or "ask just Q5 and Q7" — both honored.
 - **Hard cap at 10.** Don't add Q11.
 - **Proceed as soon as Q1 (Scope) is answered** if the operator signals urgency. The rest are optional.
 - **One at a time.** Never batch the questions into a single "answer all of these" message.
 ## Frozen-brief format (for the peer agent)
 After collection, pass the brief to the peer in this exact format:
 ```
 === FROZEN BRIEF BEGIN ===
 Topic: <topic from operator>
 Target save dir: ~/workspace/<current-workspace>/plans/
 Q1 (Scope):         <answer or "you decide">
 Q2 (Constraints):   <answer or "you decide">
 Q3 (Success):       <answer or "you decide">
 Q4 (Unknowns):      <answer or "you decide">
 Q5 (Users):         <answer or "you decide">
 Q6 (Out-of-scope):  <answer or "you decide">
 Q7 (Performance):   <answer or "you decide">
 Q8 (Security):      <answer or "you decide">
 Q9 (Integration):   <answer or "you decide">
 Q10 (Timeline):     <answer or "you decide">
 Mode flags:         <none, or e.g. --no-research>
 === FROZEN BRIEF END ===
 ```
 The peer agent uses this brief as the starting point. It does NOT re-ask. It DOES surface in the deliverable header which Qs were "you decide" so the operator can override.
 ## Why this template exists
 - **Prevents over-asking.** 4 questions was too few (missed security/perf/integration). 10 is the upper bound that still respects operator time.
 - **Priority-ordered.** The first 4 (Scope / Constraints / Success / Unknowns) are the load-bearing dimensions. The rest (Q5-Q10) are scoping details that can be skipped without losing the plan's load-bearing evidence.
 - **Operator-driven.** The operator's "min as needed, max 10" preference is encoded: surface only what's load-bearing, never the full 10 unless asked.
 - **Reusable.** The pattern is class-level — any non-trivial delegated work can benefit from this brief, not just plan-builds.
 ## See Also
 - `create-plan` skill — uses this as Phase 0
 - `subagent-driven-development` skill — for the delegation pattern that consumes the brief
 - `ask-hermes` skill — for the peer agent execution model