Ulw Research

Research

This is a Hermes-native research workflow skill.

Why This Exists

research exists to make Hermes a careful research engine: it routes research demands to source-backed evidence gathering - from live web citations to studied reference implementations - verifies contested claims, and distills decision-grounding output so planning starts from evidence instead of guesses.

Do Not Use When

• The user asks for a full plan-to-PR delivery cycle; use ultrawork (its delivery_boundary capability) or a planning workflow after research instead.
• The request is purely local repo inspection with no external, current, citation, or source-comparison need.
• The study target is this repository itself rather than external references; use codebase-onboarding.
• The user needs coding execution, review, CI, or merge evidence rather than research synthesis.
• The requested output is a typed candidate list or acquisition status without factual synthesis; use source-finder.
• The user needs a market, customer, or pricing decision brief with evidence-versus-inference treatment; use research-brief.
• The user asks for recurring monitoring, a source inbox, or Scout/Analyst/Briefer operations; use research-department.
• One cited retrieval round settles the question and no reference implementation needs reading; use web-research.

Examples

Good example:

• Prompt: 딥리서치로 다른 오픈소스 구현들을 깊게 보고 스펙 잡기 전에 근거를 만들어줘.
• Expected behavior: Run the Hermes research lane at depth: decompose axes, study the most relevant reference implementations with pinned refs, verify contested claims, then distill a decision-grounding dossier for the planning step.
• Why: The user explicitly asked for deep pre-spec grounding built on other open-source implementations.

Bad example:

• Prompt: 이 레포 코드 구조만 파악해줘.
• Expected behavior: Route to codebase-onboarding because the study target is this repository, not external sources or reference implementations.
• Why: Local repo orientation needs no external evidence gathering or claim verification.

Completion Checklist

• The research question, source boundaries, recency assumptions, and confidence level are named.
• Observed sources, inference, synthesis, and unresolved retrieval gaps are separated.
• Follow-up planning or handoff uses the research summary without calling it execution evidence.

Recovery Notes

• If a source fails with HTTP 403, HTTP 429, a paywall, or a WAF or bot wall, load Hermes' blocked-page-recovery skill once for that source when it is available and never retry the same URL in a loop; cite an archive or cached copy it returns as a dated historical capture, never as the live page. If the skill is unavailable, recovery fails, the retrieval budget is spent, or the source needs a login or payment, name the retrieval gap with that reason. Record each blocked source as one research_source_recovery/v1.
• If web or repository access is unavailable, name the retrieval gap and use only observed local context instead of inventing findings.
• If no archive access exists or the capture provider's paid authority is exhausted, record a temporal retrieval gap with no network action and keep the as-of claim in the annex; never substitute the current page for it.
• If the evidence stays thin or contested, lower the stated confidence and keep the unresolved claims in the annex rather than flattening them.
• If leads keep expanding past the declared budget, stop, record open leads in the dossier, and ask whether to extend the budget.
• If enough evidence already exists and the real request is planning, hand off to ralplan with the recorded dossier.
• If the audience answer arrives after retrieval started, keep the evidence and re-render rather than re-running: the dossier feeds both branches.

Workflow Lane

• Current lane: Research and company ops (product-docs, source-finder, web-research, research, model-optimization, inference-serving, model-finetuning, research-brief, +20 more) - research, signals, ops, and briefings.
• If intent belongs to another lane, hand back to oh-my-hermes or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: omh-routing/references/skill-common-rail.md.

Use When

Use for research before planning, deciding, or handoff - from current web evidence and citations to exhaustive grounding with studied reference implementations and verified contested claims.

Strong routing signals: `research plan`, `literature review`, `research literature`, `review recent papers`, `deep research`, `deep-research`, `exhaustive research`, `saturation research`, `pre-spec research`, `research before spec`, `research before planning`, `reference implementation`, `reference implementations`, `reference implementation study`, `prior art`, `prior art research`, `study existing implementations`, `comparable implementations`, `compare open source implementations`, `decision-grounding research`, `autoresearch-goal`, `research goal`, `durable research`, `critic research`, `ディープリサーチ`, `深く調査`, `出典付きで調査`, `OSS実装を調査`, `조사`, `근거`, `고객 피드백`, `문헌 검토`, `논문들 검토`, `딥리서치`, `딥 리서치`, `심층 리서치`, `레퍼런스 구현`, `오픈소스 깊게 참고`, `深度调研`, `深入调研`, `带出处的调研`, `调研开源实现`

Catalog Metadata

Category: research Phase: decision-grounding Hermes role: researcher Quality tier: source-gated Reasoning demand: standard

Quality bar:

• Ask for the research question, source boundaries, freshness, jurisdiction, and version assumptions before retrieval.
• Ask who the output is for before retrieval and never infer it: a human reader gets a briefing document, a coding agent gets the dense handoff of findings, exact symbols, and file paths. The answer changes what the run records, not only how it is written up.
• On the human branch ask the output format (markdown, a print-ready page, or both) and the output language before writing, then hold the document to references/briefing-format.md - noun-phrase titles carrying a role label from its closed vocabulary, cause before effect, terms defined at first use, figures drawn in code blocks, and the fixed chapter-and-appendix structure.
• Keep the coding-agent branch dense: findings, exact symbols, file paths, and the plan-feed block, with no narrative framing and no briefing structure.
• Use official or primary sources first when current or external facts matter, then add source diversity when the topic is contested.
• Revise the search plan when new evidence exposes a gap or contradiction instead of stopping at the first pass.
• Gate contested claims: require at least two independent source domains, one counter-search for disconfirming evidence, and a primary source, or move the claim to the unresolved annex.
• Separate direct evidence, citation links, retrieval dates, inference, confidence, and residual uncertainty.
• Name retrieval gaps when Hermes or the wrapper cannot access the web.
• For AI or usability research, separate target-user/task assumptions, measured or reported usability dimensions, and generalizability limits from the evidence.
• Decompose the question into orthogonal research axes and disambiguate named entities before any deep reading.
• Fan out one research lane per axis in parallel when the runtime provides subagents or delegation - covering distinct evidence kinds such as web evidence, reference-implementation study, and claim verification - and merge every lane's leads into one shared ledger between waves; without parallel delegation, run the same lanes sequentially under the same contract.
• Study reference implementations directly: read the core modules of the most relevant open-source repos, pin the exact version or commit, and record mechanism, tradeoffs, and license per reference.
• Expand lead-by-lead: track open leads and dead ends, and continue until leads run dry or the declared budget is reached.
• Mark every figure as measured, assumed, or derived, and carry retrieval dates for time-sensitive facts.
• Keep historical-capture evidence and live-page evidence as two typed surfaces for a point-in-time or then-versus-now question; capture time, publication time, and retrieval time are independent clocks and none substitutes for another.
• Distill the dossier into a plan-feed block - decision drivers, viable options with evidence, rejected candidates with reasons, risks, and open questions - so planning consumes conclusions, not raw notes.
• Reserve the end of the run for synthesis; an interrupted run must still leave a partial dossier rather than lost context.
• A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when the interjection changes scope, say so and update the declared plan or todo instead of silently abandoning it. A mid-run message is the latest steering for the active task, not automatically a replacement objective: it replaces the objective when the user says so and steers the current one otherwise.
• A follow-up that needs new authority, materially expands the scope, or changes external state not already authorized is described first and started only on the user's approval: the turn ends by naming that next action and asking whether to take it, as one question carrying the choices the user has, never by declaring what will not be done; persistence never broadens the authorized scope. A refused escalation is answered the same way, with a safer alternative inside the boundary or the authorization the boundary asks for — never a workaround or an indirect execution.
• The closing brief scales to the change: one or two sentences plus the observed validation for a simple change, more only when the complexity earns it. Lead with the result or decision, in the user's words; omit abandoned approaches unless they explain a tradeoff the reader needs; narrate no internal bookkeeping (todo transitions, waits). When the work stops at a boundary or at a decision the user owns, end with the next action offered as a question, and state what was left undone as the option it leaves open, never as a refusal. Required closing lines stay outside this scaling: the observed run summary, and any prepared-not-observed or unmerged work, are stated whatever the brief's length.
• Summarize the evidence or dossier before any planning or coding handoff; research is not implementation evidence.