tools-update-cron: sync 2026-08-09 — 37 skill(s) updated

deep-research/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: deep-research
 description: Dispatch exhaustive deep web research to the research profile. Triggered by "deep research", "ask web", or "research this". The research profile runs with the deep-web-research skill loaded — six-move flow, external ledger, mechanical saturation, disconfirmation, condensation from disk.
-version: 2.4.0
+version: 2.5.0
 author: Hermes Agent
 license: MIT
 platforms: [linux]
@@ -42,51 +42,56 @@ Beyond the question's subject, confirm any dimension that changes the *output sh
 - **Build-on-existing vs. fresh** — when the target environment already has partial tooling installed, confirm whether to reuse it or design from scratch.
 These are NOT generic clarifying questions — they are scope axes specific to plan-building research. Ask at most one `clarify` round covering whichever of these are genuinely unresolved before dispatching.
 
-**Multi-turn narrowing:** If after 1–2 rounds of clarifying questions the scope is still unclear, abandon the dispatch and ask the operator to rewrite the question with the scope made explicit. Do not loop.
+**Multi-turn narrowing:** If after that one round the scope is still unclear, abandon the dispatch and ask the operator to rewrite the question with the scope made explicit. Do not loop.
 
 ## Command
 
-```
-hermes -p research -s deep-web-research chat -q "<question>" -Q --max-turns 600 --yolo
+**Dispatch as a background terminal process with `notify_on_complete=true`.** Do NOT pipe through `head` or any other truncating filter — that kills the hermes process via SIGPIPE before the session_id is emitted.
+
+```bash
+terminal(background=true, notify_on_complete=true, timeout=14400,
+  command="hermes -p research -s deep-web-research chat -q \"<question>\" -Q --max-turns 4000 --yolo",
+  workdir="/home/n8n/workspace/research")
 ```
 
-- Output line 1: `session_id: <id>` — capture this
-- The research agent writes the condensed answer to `~/workspace/research/results/<YYYY-MM-DD>-<slug>.md`
+- The session_id appears near the END of stdout. Extract it from the process log with `process(action='log', session_id=...)` after completion — read the last ~20 lines for `session_id: <id>`.
+- The research agent writes the condensed answer to `/home/n8n/workspace/research/results/<YYYY-MM-DD>-<slug>.md` (absolute path)
 - Hold the session_id for follow-up questions
-- **Session_id capture pitfall (background dispatch):** When run as a background process, the output begins with a TUI banner (OS/hostname/IP block) + an initial reasoning block BEFORE the session_id line appears. Piping through `| head -20` can truncate the output before the session_id is reached. Use a larger head (`| head -50`) or, better, `grep -oE 'session_id: [a-f0-9-]+'` on the full log to extract it reliably. If the session_id is lost, `session_search` on the research profile may NOT find `-Q` quiet-mode sessions — in that case, do NOT re-dispatch Stage 3 of the validate-fix pipeline; apply validated corrections directly to the plan file yourself (you have the full plan text + validation report). This is equally correct and avoids a redundant 600-turn run.
+- **Session_id capture:** After the background process completes, read the last ~20 lines of the process log to find `session_id: <id>`. If the session_id is lost, `session_search` on the research profile may NOT find `-Q` quiet-mode sessions — in that case, do NOT re-dispatch Stage 3 of the validate-fix pipeline; apply validated corrections directly to the plan file yourself (you have the full plan text + validation report). This is equally correct and avoids a redundant 600-turn run.
 
 **Subsequent asks (resume the session):**
-```
-hermes -p research -s deep-web-research chat --resume <session_id> -q "<follow-up>" -Q --max-turns 600 --yolo
+```bash
+terminal(background=true, notify_on_complete=true, timeout=14400,
+  command="hermes -p research -s deep-web-research chat --resume <session_id> -q \"<follow-up>\" -Q --max-turns 4000 --yolo",
+  workdir="/home/n8n/workspace/research")
 ```
 
 ## Delivery Method (MANDATORY)
 
 **File-only delivery.** The research agent writes the full condensed answer to a markdown file and reports the path. Nothing is relayed inline.
 
-- **Path:** `~/workspace/research/results/<YYYY-MM-DD>-<slug>.md`
+- **Path:** `/home/n8n/workspace/research/results/<YYYY-MM-DD>-<slug>.md` (absolute path)
 - **Slug:** derived from the question (e.g., `minimax-m3-temperature-support`)
 - **Format:** YAML frontmatter (question, date, sources, confidence) + markdown body with structured findings
-- **After dispatch:** report the session_id and the expected output path to the user
-- **When user asks for results:** use `session_search` on the research profile with the captured session_id, then relay the path — the user reads the file directly
+- **After dispatch:** report the expected output path to the user. The session_id is not available yet — capture and report it from the process log when the `notify_on_complete` notification arrives (see the Exception at the end of Post-Dispatch Behavior).
+- **When user asks for results:** check for the result file at the path above. If the slug is unknown, use `ls -t /home/n8n/workspace/research/results/ | head` to find the most recent result. If the file ends in `-ABORTED.md`, the question was under-specified — report that to the operator and re-dispatch with narrowed scope rather than treating it as a result. Do NOT inline the answer — the file is the source of truth.
 
 The file is the single source of truth. Do not inline the research answer — it's always lossy for 100+ turn sessions.
 
 ## Post-Dispatch Behavior (MANDATORY — non-negotiable)
 
-**After dispatching, return control to the operator IMMEDIATELY. Do NOT poll, do NOT check, do NOT background, do NOT auto-deliver.**
+**After dispatching, return control to the operator IMMEDIATELY. Do NOT poll, do NOT check, do NOT auto-deliver.**
 
-- The research runs as a background process. It will complete on its own.
+- The research runs as a background process (`notify_on_complete=true`). It will complete on its own and you'll be notified.
 - **Do NOT poll.** Do NOT call `session_search` on the research session to check progress.
 - **Do NOT check.** Do NOT call `process wait` or `process poll` on the background process.
-- **Do NOT background the wait.** The dispatch should return in seconds, not minutes — if you find yourself waiting, you did it wrong.
 - **Do NOT auto-deliver.** Do NOT inline the answer. Do NOT push to a chat platform (Telegram/etc). Do NOT proactively surface results when the background process completes.
 - **Only check for results when the user explicitly asks** (e.g., "what did the research find?", "is it done?", "show me the results").
-- When the user asks, use `session_search` on the research profile with the captured session_id to confirm completion, then report the file path: `~/workspace/research/results/<date>-<slug>.md`. Do NOT inline the answer — the file is the source of truth.
+- When the user asks, check for the result file at `/home/n8n/workspace/research/results/<date>-<slug>.md` first. If the slug is unknown, use `ls -t /home/n8n/workspace/research/results/ | head` to find the most recent result. If not found, check for a ledger at `/tmp/research-*.md` with `ls -t /tmp/research-*.md | grep -v gate | head`. Do NOT inline the answer — the file is the source of truth.
 
 **This rule is operator-standing and applies to all research delegation skills** (`deep-research`, `better-search`, and any future research-delegation skill). Even "checking once after a delay" violates the rule. The operator reads the result file when they want to.
 
-The session_id is captured from output line 1 and held in conversation context for follow-up questions and result retrieval. No state file needed.
+**Exception:** On the `notify_on_complete` notification, reading the process log to capture the session_id is allowed — it is not delivery, it's bookkeeping. Do NOT use this as a pretext to check results.
 
 ## What the Research Agent Does
 
@@ -99,7 +104,7 @@ The `deep-web-research` skill on the research profile enforces:
 4. **Disconfirmation** — actively hunt for contradiction and outdated claims
 5. **Condensation** — read the external findings ledger from disk, synthesize into a concrete answer
 
-The research agent writes all findings to `/tmp/research-<sid>.md` (external ledger) and uses a phase gate file to enforce completion before condensing. Mechanical saturation checks (`grep -c`) prevent endless searching. Re-strategize checkpoints after Move 2 and every ~10 findings during Move 3 enable mid-research pivots.
+The research agent writes all findings to `/tmp/research-<YYYY-MM-DD>-<slug>.md` (external ledger, stem picked in Move 0) and uses a phase gate file to enforce completion before condensing. Mechanical saturation checks (`grep -c`) prevent endless searching. Re-strategize checkpoints after Move 2 and every ~10 findings during Move 3 enable mid-research pivots.
 
 ## Tool Selection Strategy
 
@@ -151,7 +156,7 @@ The research ladder has three tiers. Pick the cheapest one that fits the questio
 
 ## Relay Rule
 
-Do NOT relay the research agent's response inline. The file at `~/workspace/research/results/<date>-<slug>.md` is the single source of truth. When the user asks for results, report the file path and let them read it directly. If the user asks for a specific finding, you may extract that one section from the file — but never inline the full answer.
+Do NOT relay the research agent's response inline. The file at `/home/n8n/workspace/research/results/<date>-<slug>.md` is the single source of truth. When the user asks for results, report the file path and let them read it directly. If the user asks for a specific finding, you may extract that one section from the file — but never inline the full answer.
 
 ## Spot-check Rule
 
@@ -161,7 +166,7 @@ The research agent self-reports are not verified fact. If it claims a file write
 
 **HARD RULE: Same topic = resume. New topic = new session.**
 
-- **Same topic / same line of research:** Always `--resume <session_id>`. Capture session_id from output line 1. Every follow-up in the same line of research MUST use `--resume <session_id>`. Starting fresh discards the research context and wastes turns.
+- **Same topic / same line of research:** Always `--resume <session_id>`. Capture session_id from the process log after completion. Every follow-up in the same line of research MUST use `--resume <session_id>`. Starting fresh discards the research context and wastes turns.
 - **New topic / new line of research:** Start a fresh session. Do NOT resume an unrelated session — the research context is polluted with the old topic and will produce confused results.
 
 ## Common Pitfalls
@@ -169,27 +174,31 @@ The research agent self-reports are not verified fact. If it claims a file write
 1. **Profile flag required.** Always use `-p research`. The sticky default may be general.
 2. **Skill flag required.** Always use `-s deep-web-research`. Without it, the research agent runs in normal mode without the methodology.
 3. **--yolo is required.** The research agent runs headless. Without it, approval prompts fail closed.
-4. **600 turns is the ceiling, not the target.** The research agent should condense well before 600. Hitting the ceiling means it failed to condense. The operator's standing rule: 600 is a safety net, not a budget — "I just want a safety net. I would even be okay with 600 as a catch. I mostly want the job done right. Not concerned with time or tokens." Apply 600 for any plan-building, research, or evidence-based work; default to lower only for short factual lookups.
-5. **Don't re-condense.** The research agent already produced a condensed answer. Relay it, don't summarize it further.
+4. **2000 turns is the ceiling, not the target.** The research agent should condense well before 2000. Hitting the ceiling means it failed to condense. The operator's standing rule: 2000 is a safety net, not a budget — "I just want a safety net. I would even be okay with 2000 as a catch. I mostly want the job done right. Not concerned with time or tokens."
+5. **Don't re-condense.** The research agent already produced a condensed answer. Report the file path — the answer is already condensed. Do not re-summarize or inline it.
 6. **Don't do the research yourself.** If the user triggers deep research, dispatch it. Don't run a few searches and call it done. This is the #1 failure mode: the agent runs 2-3 `mcp_searxng_searxng_web_search` calls, gets empty results, and gives up. That's not deep research — that's a casual lookup. If you catch yourself typing `mcp_searxng_searxng_web_search` for a deep research request, STOP. You're doing it wrong. Dispatch to the research profile.
 7. **The methodology skill lives on the research profile.** `deep-web-research` is at `~/.hermes/profiles/research/skills/research/deep-web-research/SKILL.md`. It does NOT exist on the general profile. Don't search for it here — it won't be found. The general profile only has this delegation skill.
 8. **Dispatcher/methodology coordination is a two-skill contract.** This skill (the dispatcher) caps clarifying questions at 5 default / 10 max and aborts the dispatch if the question is under-specified. The `deep-web-research` methodology skill (on the research profile) handles the same problem differently because it's headless — it can't ask the operator, so it aborts with a structured under-specification report naming the plausible interpretations. When updating one, update the other to match. Drift between the two causes the dispatcher to think the question is dispatchable while the methodology aborts it, or vice versa — both waste turns.
 9. **Confirm hardware/environment scope before dispatching a hardware-mapped plan.** If the deliverable maps tools to specific hardware, confirm *which hardware* before dispatch — do not assume the full fleet from memory. The operator may be scoping to a single box (e.g., "I'll provide one LXC"). A 600-turn research artifact built against the wrong hardware scope has its architecture, parallelization, and GPU-scheduling sections wrong and must be killed and re-dispatched. Cheaper to ask one `clarify` round than to re-run 600 turns. (Learned 2026-07-07: dispatched a microdrama-pipeline plan against the full fleet; operator corrected to a single LXC; had to kill and re-dispatch.)
 10. **Inventory the target box before dispatching environment-specific research.** When the plan must build on an existing install, SSH in and inventory the real state (GPU, RAM, disk, running services, installed models/nodes/packages) *before* dispatching, and pass the exact inventory into the research prompt. This lets the research agent research only the genuinely missing pieces instead of guessing or re-researching what's already installed. See `references/inventory-before-dispatch.md` for the probe script.
 
+## Tool Inventory
+
+The research profile has a comprehensive tool inventory at `~/.hermes/profiles/research/memories/MEMORY_TOOLS.md` — 15 sections organized by use case (Web Search, Scraping, Browser, PDF, OSINT, Social Media, Vector Search, AI/ML, Code, Memory, Tasks, Vision, Skills, Data Formats, Infrastructure). The `deep-web-research` methodology skill references it for tool selection. Before dispatching, confirm the inventory is current by checking the file exists. If the research agent reports missing tools, update the inventory first, then re-dispatch.
+
 ## Pre-Dispatch Reasoning Check (do NOT mutate the research profile's config)
 
-**Do NOT call `hermes -p research config set agent.reasoning_effort max` before dispatching.** That is a persistent side-effect — it writes to the research profile's `config.yaml` and the change survives the dispatch, affecting every subsequent research-profile session (interactive use, cron jobs, other research delegations).
+**Do NOT call `hermes -p research config set reasoning_effort high` before dispatching.** That is a persistent side-effect — it writes to the research profile's `config.yaml` and the change survives the dispatch, affecting every subsequent research-profile session (interactive use, cron jobs, other research delegations).
 
-**Correct approach:** The research profile's `agent.reasoning_effort` is already set to a thorough value by the operator (operator's standing rule: thoroughness > speed; thoroughness > tokens). Read it before dispatching to confirm it's at a high value, but do NOT write to it:
+**Correct approach:** The research profile's `reasoning_effort` is already set to `high` by the operator (operator's standing rule: thoroughness > speed; thoroughness > tokens). Read it before dispatching to confirm it's at a high value, but do NOT write to it:
 
 ```bash
 # Read-only check — confirm reasoning_effort is set
-grep -E "default:|reasoning_effort:" ~/.hermes/profiles/research/config.yaml | head -5
-# If it's NOT at max for the model, warn the operator — don't silently fix it
+grep "reasoning_effort:" ~/.hermes/profiles/research/config.yaml
+# If it's NOT at high, warn the operator — don't silently fix it
 ```
 
-If the operator wants a different reasoning effort for this specific dispatch, they set it themselves; the dispatcher does not mutate other profiles' configs on every invocation. The "max" value the operator wants is achieved by the operator setting it once in `config.yaml`; the dispatcher reads and confirms, never writes.
+If the operator wants a different reasoning effort for this specific dispatch, they set it themselves; the dispatcher does not mutate other profiles' configs on every invocation. The `high` value the operator wants is achieved by the operator setting it once in `config.yaml`; the dispatcher reads and confirms, never writes.
 
 This rule also applies to all research-dispatching skills (`better-search`, future research delegation skills). The dispatcher is not authorized to mutate the target profile's config.
 
@@ -216,7 +225,7 @@ Save to <path>_validation.md.
 
 **Stage 3 prompt template** (resume the research session):
 ```
-Read the validation report at <path>_validation.md. Read the current plan at <path>.md.
+Read the validation report at <path>_validation.md. Read the current plan at <path>.
 Apply ALL fixes from the validation report. Keep all existing content. Make targeted edits only. Do NOT rewrite the whole plan.
 ```