Investigate a topic, verify the evidence, and save a reusable report.

• Turn a research question into a saved markdown brief under

  .hypercore/research/

  .
• Prefer evidence gathering and synthesis over freeform writing.
• Keep the core skill lean and load support files only when they change the search or reporting plan.

research

research

• the user only wants writing, rewriting, or presentation polish without new evidence gathering
• the user only needs a narrow library or API lookup with no synthesis; use direct official-doc lookup instead
• the main job is code modification, debugging, or implementation rather than gathering evidence

.hypercore/research/

rules/validation.md

• "Research AI agent framework tradeoffs for me."
• "Compare WebSocket and SSE for realtime notifications."
• "Look up the latest Korea SaaS market trends and summarize them."

• "Rewrite this report so it sounds more executive."
• "Implement the migration after you read the docs."

• "Research react useEffectEvent" or a local slash invocation such as "

  /research react useEffectEvent

  " Use

  research

  only if the user wants synthesis across multiple sources; otherwise do a direct official-doc lookup.
• "Research" with no topic, or a local slash invocation such as "

  /research

  " Ask immediately for the missing topic before doing any collection work.

--quick

--deep

1. This core

   SKILL.md

   to confirm that the job is research and to pick the depth.
2. rules/research-workflow.md when actively running a research task so request confirmation, channel priority, collection, save, and closeout stay consistent.
3. Apply sourcing, dedupe, recency, and stop-condition checks through the local rules/research-workflow.md and rules/validation.md cues before running multiple live searches.
4. references/channel-selection.md when choosing between local repo search, official docs, GitHub evidence, and live web sources.
5. rules/parallel-research.md before using subagents/background agents or splitting collection across parallel lanes.
6. references/report-template.md when drafting or saving the report.
7. rules/validation.md before declaring the research complete.

.hypercore/research/

• If the topic is missing, ask for it before any search.
• If the request is broad, high-stakes, or

  --deep

  , use sequential thinking to define 3-5 research questions, scope, date constraints, and stop conditions before searching.
• Use parallel research only when the questions or channels are independent enough to dedupe and synthesize later; load

  rules/parallel-research.md

  first.
• If the request is narrow and low-risk, state a short plan and start collecting without turning the skill into a planning exercise.
• Prefer repo-local search for internal project questions, official docs for package or API questions, GitHub evidence for release or implementation history, and live web sources for market, news, or trend work.
• When the user asks for "latest", "current", "today", or similar wording, verify with live sources and write exact dates in the report instead of relative dates.
• Save before closing. Do not stop at a chat answer if the skill was invoked to produce a report.

• Keep search queries distinct across the whole run, including subagents; do not repeat the same query across channels or lanes.
• Prefer primary or official sources first for technical and product claims.
• Attach a link to every non-obvious claim in the final report.
• Use comparison tables when judging alternatives.
• Record unresolved conflicts or missing evidence explicitly instead of smoothing them over.

• Hardcoding a specific year into evergreen search or reasoning rules
• Claims without citations
• Comparison conclusions without a visible evidence basis
• Placeholder tool or role names when the local runtime already offers a clearer direct path
• Product-specific subagent syntax as a universal requirement
• Parallel lanes without objective, scope, source floor, output, and stop condition