SpeedyFoxAi/hermes-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tools-update-cron: sync 2026-07-15 — 23 skill(s) updated

Browse Source
This commit is contained in:
Hermes Agent
2026-07-15 14:01:38 -05:00
parent 092bdf0517
commit fd8a7847d6
23 changed files with 3072 additions and 131 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
deep-research/SKILL.md
View File

@@ -1,14 +1,14 @@
---
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.3.0
version: 2.4.0
author: Hermes Agent
license: MIT
platforms: [linux]
metadata:
hermes:
tags: [research, deep-research, delegation, web-search, scraping]
related_skills: [ask-hermes, ask-claude, ask-dev, deep-web-research, writing-plans]
tags: [research, deep-research, delegation, web-search, scraping, research-ladder]
related_skills: [ask-hermes, ask-claude, ask-dev, deep-web-research, writing-plans, better-search, searxng-smart-search]
---
# deep-research — Exhaustive Web Research Delegation
@@ -17,7 +17,7 @@ metadata:
Dispatches a research question to the research profile, which runs with the `deep-web-research` skill loaded. The research agent does exhaustive, trail-following research — any tool, any trail, no rush — then condenses everything into a tight, concrete, evidence-backed answer. This agent just relays the result.
See `references/design-rationale.md` for the v2.0 architecture decisions and Claude validation findings.
See `references/design-rationale.md` for the v2.0 architecture decisions and Claude validation findings. See `references/research-ladder-and-two-skill-pattern.md` for the three-tier research ladder (`searxng-smart-search` / `better-search` / `deep-research`), the two-skill contract pattern (dispatcher + methodology), and the "don't overcomplicate" rule that emerged from the operator's plan-build sessions. See `references/inventory-before-dispatch.md` for the SSH probe script and workflow for inventorying a target box before dispatching environment-specific research.
**Trigger phrases:** "deep research", "ask web", "research this", "deep dive on", "exhaustive research on"
@@ -35,6 +35,13 @@ If the operator's question is ambiguous enough that the research agent would was
- Do NOT ask when the research agent can sensibly find out (e.g., "What year did X happen?" — the research will find it).
- Do NOT ask to delay dispatching. Asking is a cost, not a hedge.
**Scope dimensions to confirm before dispatch (high-value, often-missed):**
Beyond the question's subject, confirm any dimension that changes the *output shape* of the plan/research. Missing one forces a kill + re-dispatch mid-run, wasting the first session's turns. Known dimensions:
- **Hardware/environment target** — when the deliverable maps tools to specific hardware (e.g., "build a local pipeline on our hardware"), confirm *which* hardware before dispatch. Do not assume the full fleet from memory; the operator may be scoping to a single box. This is the #1 missed dimension.
- **Cloud vs. local vs. hybrid** — when a workflow could be replicated with cloud APIs, local self-hosted, or a mix, confirm which before dispatch.
- **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.
## Command
@@ -46,6 +53,7 @@ hermes -p research -s deep-web-research chat -q "<question>" -Q --max-turns 600
- Output line 1: `session_id: <id>` — capture this
- The research agent writes the condensed answer to `~/workspace/research/results/<YYYY-MM-DD>-<slug>.md`
- 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.
**Subsequent asks (resume the session):**
```
@@ -64,17 +72,20 @@ hermes -p research -s deep-web-research chat --resume <session_id> -q "<follow-u
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)
## Post-Dispatch Behavior (MANDATORY — non-negotiable)
**After dispatching, continue working with the user. Do NOT poll, wait, or check for results unless the user explicitly asks.**
**After dispatching, return control to the operator IMMEDIATELY. Do NOT poll, do NOT check, do NOT background, do NOT auto-deliver.**
- The research runs as a background process. It will complete on its own.
- Do NOT call `session_search` on the research session to check progress.
- Do NOT call `process wait` or `process poll` on the background process.
- Do NOT proactively surface results when the background process completes.
- **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.
**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.
## What the Research Agent Does
@@ -119,7 +130,19 @@ The research agent must determine the best tools for each research type — not
- User wants current, verified, cross-referenced information
- Phone number lookup, person research, topic investigation, fact verification
## When NOT to Use
## When NOT to Use (research ladder — pick the right tier)
The research ladder has three tiers. Pick the cheapest one that fits the question:
| Tier | Skill | Loops | Use when |
|---|---|---|---|
| Light | `searxng-smart-search` (inline MCP) | 1 | Single factual lookup, single search suffices |
| Medium | `better-search` | 1–3 | "Look into X", "do a better search", 2–3 targeted searches with AI evaluation |
| Heavy | `deep-research` (this skill) | Many (200+) | "Map the X landscape", OSINT, exhaustive coverage, contradiction-hunting |
**Routing decision belongs to the operator, not the dispatcher.** If the question is "what is the capital of France?", use `searxng-smart-search` directly. If it's "look into the latest X", use `better-search`. Only escalate to `deep-research` when the operator explicitly wants exhaustive multi-source work.
**Do NOT use `deep-research` for:**
- Simple factual question (capital of France, current time)
- Question I can answer from a single search
@@ -151,16 +174,24 @@ The research agent self-reports are not verified fact. If it claims a file write
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.
## Pre-Dispatch Reasoning Check (MANDATORY)
## Pre-Dispatch Reasoning Check (do NOT mutate the research profile's config)
Before EVERY deep research dispatch, set the research profile's reasoning_effort to `max`. This is a hard gate — do not dispatch without it.
**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).
```
hermes -p research config set agent.reasoning_effort max
**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:
```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
```
`max` is the highest effort setting universally supported by all models. No model-specific table needed. If the model changes to one that supports `xhigh`, the user will set it in config — the pre-dispatch check just ensures it's at `max` minimum.
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.
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.
## Research → Validate → Fix Pipeline