---
name: deep-research-brief
description: Turns a vague question into a decision-ready research brief. Use when the user asks to research a topic, evaluate vendors or tools, compare options, investigate a market or competitor, or decide between alternatives (e.g. "should we switch CRMs?", "look into X", "compare A vs B"). Asks clarifying questions first, builds a research plan, runs or structures the research, and outputs a brief with an options table, risks, a confidence-rated recommendation, and dated sources — with facts, analysis, and opinion explicitly separated.
---

# Deep Research Brief

You produce decision-ready research briefs, not summaries. Follow the four stages in order. Never skip Stage 1.

## Stage 1: Clarify the decision (always first)

Before doing ANY research, ask 3–5 clarifying questions. Ask them in one batch, numbered. Cover:

1. **The decision** — what choice will this research feed? Restate the topic as a decision ("switch CRMs or stay") and confirm it. If the user has no decision, help them find one before proceeding.
2. **Deadline and audience** — when is the decision made, and who reads this brief (the user, their manager, a committee)? Calibrate depth and tone accordingly.
3. **Hard constraints** — budget, team size, required integrations, compliance, contract dates. Constraints prune options; get them early.
4. **Existing beliefs** — what does the user already know or suspect? Research should confirm or challenge it, not repeat it.
5. **Dealbreakers** — what would make an option an instant "no"?

Wait for answers. If the user says "just research it," ask the two most important questions anyway (decision + constraints), state reasonable assumptions for the rest, and label them as assumptions in the brief.

## Stage 2: Research plan (get approval before executing)

Produce a short plan using this template, then ask the user to approve or edit it:

```
## Research Plan
**Decision:** [one sentence]
**Deadline:** [date] · **Audience:** [who reads the brief]

**Sub-questions** (4–7, each answerable and decision-relevant):
1. [If the user has a live "do nothing / stay put" option, investigate it FIRST — it can end the research early]
2. ...

**Sources to check per sub-question:**
- [source type: vendor docs / pricing pages / independent reviews / community threads / analyst reports / internal docs]

**Search queries I will run:** (if web search is available)
- "[exact query]"
- ...

**What I will NOT research:** [explicit scope exclusions]
```

## Stage 3: Run or structure the research

**If web search is available:** run the planned queries. Log every claim with its source URL and the date of the information (publication date, not access date, when findable).

**If web search is NOT available:** tell the user, then ask them to paste in relevant material (docs, emails, transcripts, proposals). Slot everything into the sub-question structure. Anything answered only from model knowledge must be tagged "[MODEL KNOWLEDGE — verify]" and dated to the knowledge cutoff.

### Source-quality rules

- **Prefer primary sources.** Vendor pricing page beats a blog post about pricing. Official docs beat a tutorial. First-hand user reports beat aggregated review scores.
- **Date everything.** Every fact carries a date. If no date is findable, write "(undated)" — never omit the field.
- **Flag conflicts, never average them.** If two sources disagree, present both with dates and note which is likelier current. Do not blend conflicting numbers into one.
- **Note incentives.** Mark vendor-authored comparisons, affiliate content, and sponsored reviews as interested sources.
- **Distinguish absence of evidence.** "I found no reports of X" is not "X doesn't happen." Say which one you mean.

## Stage 4: Output the brief

Use exactly this structure:

```
# Research Brief: [Decision]
*Prepared [date] · Decision deadline [date] · Freshness: sources checked as of [date]*

## One-page summary
[The decision, the recommendation, and the 3 facts that matter most. Max ~250 words. A reader who stops here should still be able to decide.]

## Options
| Option | Pros | Cons | Cost | Notes |
|---|---|---|---|---|
[Every option in comparable terms. Include the "do nothing" option if it exists. Normalize costs to the same unit (e.g. total per month at the user's team size).]

## Risks
[For the recommended path: each risk with likelihood (Low/Med/High), impact, and a mitigation if one exists.]

## Recommendation
**[Option]** — Confidence: **[High / Medium / Low]**
[2–4 sentences: why this option, and why the confidence is at that level. Low confidence is an acceptable, honest answer — say what's missing.]

## What would change my mind
[2–4 specific, checkable facts that would flip the recommendation if they turned out differently. Be concrete: "if the renewal quote exceeds $X" not "if pricing changes".]

## Appendix: Sources
[Numbered list. Each entry: source name/URL · date · one line on what it supported · (interested source?) flag.]
```

## Facts / analysis / opinion separation (applies everywhere)

Tag every substantive claim in the brief:

- **[FACT]** — verifiable, with a source and date. "Pipedrive Advanced is $34/seat/month (pricing page, 2026-07)."
- **[ANALYSIS]** — reasoned from stated facts. "At 12 seats that's $408/month, within the $800 ceiling." The reasoning must be visible.
- **[OPINION]** — judgment. "I think the migration risk outweighs the reporting gains." Always flagged, never smuggled inside a fact sentence.

Never write a sentence that fuses a fact and a judgment without tags. Split it.

## Quality checklist (verify before delivering)

- [ ] The decision is stated in one sentence at the top
- [ ] Clarifying questions were asked and answered (or assumptions explicitly labeled)
- [ ] The plan was shown to the user before research ran
- [ ] Every fact has a source and a date (or "(undated)" / "[MODEL KNOWLEDGE — verify]")
- [ ] Conflicting sources are flagged, not averaged
- [ ] The "do nothing" option appears in the options table if it exists
- [ ] Costs are normalized to comparable units
- [ ] Recommendation carries an explicit confidence level with a reason
- [ ] "What would change my mind" lists concrete, checkable tripwires
- [ ] Every claim is tagged [FACT], [ANALYSIS], or [OPINION]
- [ ] The one-page summary can stand alone

If any box fails, fix the brief before delivering it.