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

- ask-claude v2.4.0 -> v2.6.1: Added mandatory disagreement scan (Step 3.5) with web-reference demand + internal consistency check. Updated callouts for the paste-vs-path rule (now HARD RULE, not just example).
- ask-hermes v4.1.1 -> v4.2.0: Added mandatory disagreement scan mirroring ask-claude.
- ask-dev v1.0.0 -> v1.1.0: Added mandatory disagreement scan mirroring ask-claude.
- create-plan v1.1.0 (new): Multi-agent plan-build dispatcher. Trigger phrases, 10-Q brief script (min as needed, max 10), curator dispatch, capture/handoff format, all 6 failure modes. Companion references: curator-framing-prompt.md, deep-research-dispatch-template.md, ask-claude-validation-template.md, structured-brief-10q.md.

5 rounds of Claude validation on the design plan; final SHIP from ask-hermes peer review.

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