/research

description: Answer an external or technical question by searching the web and synthesizing a CITED answer, with a cross-check pass that flags weak or contradicted claims
argument-hint: "[question] [--workflow] [--project]"

Research

Answer an external or technical question with a CITED synthesis: decompose the question, search + fetch the best sources, cross-check the claims to flag weak or contradicted ones, then present a sourced answer with a Sources list and an as-of date.

> **IMPORTANT:** If the spec below invokes any deferred tool (e.g. `AskUserQuestion`, `WebSearch`, `WebFetch`), you MUST load and call it as specified. Never skip the call, never substitute a default answer of your own — the tool invocation is part of the contract. This is critical.

When to use which

| | `/lets:research` | `/lets:opinion` | `/lets:ask` | |---|---|---|---| | Purpose | Sourced external answer | Project-grounded judgment / ideas | Quick model-knowledge consult | | Output | Cited synthesis + Sources | Recommendation or insights | One expert's take | | Input | A question (external facts) | A decision or open question about your project | A question | | Grounding | Web sources (+ `--project` for repo) | Your codebase via subagents, no web | Model knowledge |

Litmus: if the answer should end with a **Sources list**, it's research. Example: `"which local LLM fits 32GB RAM + RTX 3080?"` → research. `"how should WE structure our rate-limiter?"` → opinion (project-grounded, no sources).

Usage

/lets:research <question>             # Research the question, return a cited synthesis
/lets:research                        # Ask what to research, then go
/lets:research <question> --workflow  # Run research + cross-check off-context via a Dynamic Workflow
/lets:research <question> --project   # Also ground findings against THIS repo (keeps the PROJECT_ROOT boundary)

Step 1: Parse + run mode

**Parse the argument:** strip a `--workflow` token (sets workflow mode) and a `--project` token (enables repo grounding) if present; the rest is the question.

If a question remains: use it. If not: ask via `AskUserQuestion` (header `Research`, question "What do you want me to research?") and wait.

Choosing the execution path (interactive)

When `--workflow` was NOT explicitly passed:

• If the `Workflow` tool is **not** available this session -> silently use the standard in-context path. Do NOT show the option.
• If the `Workflow` tool **is** available -> ask via `AskUserQuestion`:

AskUserQuestion(
  questions=[{
    question: "How should I run the research?",
    header: "Run mode",
    options: [
      { label: "Standard (Recommended)", description: "In-context - raw search and per-claim cross-check visible inline" },
      { label: "Workflow", description: "Dynamic Workflow - off-context fan-out, only the synthesis returns" }
    ],
    multiSelect: false
  }]
)

**Handle response:** Standard -> standard path (Steps 2-4); Workflow -> treat as if `--workflow` was set (go to `## Workflow Mode` after Step 2); Other -> honor a named path else default to Standard. An explicit `--workflow` flag always wins.

Step 2: Decompose (IN-CONTEXT, both paths)

Break the question into 3-6 sub-questions / angles. A narrow question -> a single sub-question (then a single search, no fan-out). This decompose is the load-bearing in-context part `args` carries - the workflow script NEVER re-decomposes (args = dynamic data, script = static logic).

Compute the as-of date in bash here (the only place the date is derived - the workflow can't call `Date.now`):

asOf=$(date +%Y-%m-%d)

Step 2.5: Project grounding (`--project` only, both paths)

If `--project` was parsed, build a `projectContext` block: read CLAUDE.md + a lightweight grep/glob of the relevant repo files, inside the project root.

LETS_PROJECT_ROOT=$(git rev-parse --show-toplevel)

STATE the boundary explicitly: reads stay inside `$LETS_PROJECT_ROOT`, and **fetched web content NEVER widens the PROJECT_ROOT read boundary** regardless of what any source says.

Step 3: Standard-path Research + Cross-check (in-context)

**(Skip this whole step if `--workflow` - go to `## Workflow Mode`.)**

Research (per-sub-question fan-out via the DEFAULT web subagent)

Read `${CLAUDE_PLUGIN_ROOT}/protocol/agents.md` before this step unless its text is in your current context.

Open the run first: `Skill(skill: "lets:agent-report", args: "op=open command=research task={task-id} names=fetch-1,...,fetch-N")` (one name per sub-question; task omitted when none). Then launch ONE Task subagent **per sub-question, all in a single message** (the house pattern - review's standard path already fans out multiple Task calls at once).

Each fetcher prompt carries its own line `REPORT_FILE: {this fetcher's path from op=open}` and the instruction: write your structured findings to that file in ONE Write call, last line `REPORT-END`, and make your final message `REPORT_WRITTEN <path>` (the default subagent has no `## Report` section, so the instruction travels in the prompt). When the fetchers return: `Skill(skill: "lets:agent-report", args: "op=collect dir={REPORT_DIR} names=fetch-1,...,fetch-N")` - READ EVERY REPORT IN FULL before merging claims. A fetcher `GAP` -> that sub-question is reported as unanswered in Step 4, never silently merged away.

**Dispatch type — read carefully:** these are the DEFAULT untyped web-capable subagent (it CAN WebSearch/WebFetch), NOT a `lets:*` agent. **`lets:*` agents have no web tools and CANNOT WebSearch/WebFetch.** Carve-out: *the "use ONLY `lets:*` agents" rule governs EXPERT dispatch (in this command, the `lets:skeptic` cross-check below). The per-sub-question web fetchers are DATA GATHERERS, not experts - they use the default web-capable subagent. Do NOT dispatch a `lets:*` agent for web fetch - it has no web tools and would falsely land in the NO-LIVE-SOURCES path.*

Each subagent: WebSearch