update: session persistence rule — same topic resume, new topic new session

ask-hermes/SKILL.md

@@ -80,7 +80,10 @@ hermes -p general chat --resume <session_id> -q "<composed prompt>" -Q --max-tur
 
 ## Session Persistence
 
-**HARD RULE: Always --resume the prior session for follow-up asks.** The session_id is captured from output line 1 of the first ask. Every subsequent ask in the same line of work MUST use `--resume <session_id>`, not start a fresh session. Starting fresh discards the peer's context, wastes tokens re-establishing state, and breaks multi-turn workflows. If you don't have the session_id, you failed to capture it — that's a separate failure. The session_id lives in conversation context; hold it there.
+**HARD RULE: Same topic = resume. New topic = new session.**
+
+- **Same topic / same line of work:** Always `--resume <session_id>`. The session_id is captured from output line 1 of the first ask. Every subsequent ask in the same line of work MUST use `--resume <session_id>`, not start a fresh session. Starting fresh discards the peer's context, wastes tokens re-establishing state, and breaks multi-turn workflows. If you don't have the session_id, you failed to capture it — that's a separate failure.
+- **New topic / new line of work:** Start a fresh session. Do NOT resume an unrelated session — the peer's context is polluted with the old topic and will confuse it.
 
 The session_id lives in conversation context. No state file. If the LXC crashes, we both crash — next session starts fresh.
 
@@ -176,6 +179,28 @@ When the user says "ask hermes to fix X, then YOU validate," follow this exact s
 8. **Don't silently paraphrase.** Relay the peer's actual response. If long, chunk it. Call out unverified claims.
 10. **Peers can overstate findings.** A peer may correctly identify real gaps AND incorrectly flag things that aren't actually broken. In this session, the peer correctly identified the tool_executor.py ThreadPoolExecutor as the root cause of the Ctrl+C hang, but also flagged cli.py:9452 (account-usage fetch) as a second culprit — that one uses a `with` context manager that properly joins, so it's not a leak. Always verify each claim independently; don't assume all of a peer's findings are correct just because some are.
 
+## Pre-Dispatch Reasoning Check (MANDATORY)
+
+Before EVERY `ask hermes` dispatch, verify the general profile's `reasoning_effort` is set to the maximum the model supports. This is a hard gate — do not dispatch without checking.
+
+```
+# 1. Read the general profile's current model and 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:
+#    - deepseek-v4-pro:cloud → set to 'max' (xhigh rejected)
+#    - glm-5.2:cloud → set to 'max' (xhigh rejected)
+#    - minimax-m3:cloud → set to 'xhigh' (supports it)
+#    - If unsure what the model supports → set to 'max' (safe default)
+
+# 3. Apply the fix if needed:
+hermes -p general config set agent.reasoning_effort xhigh
+# OR for models that reject xhigh:
+hermes -p general config set agent.reasoning_effort max
+```
+
+**Rule:** Always dispatch with the highest reasoning effort the model actually supports. Never silently downgrade. If the model changed and you don't know what it supports, test with `max` first (universally safer than `xhigh`).
+
 ## Verification Checklist
 
 - [x] First `ask hermes <task>` returns peer's response showing real tool use