---
name: research-brief
description: Use this skill whenever the user asks for a research brief, a decision memo, a recommendation, or any phrasing that implies "help me decide". Triggers on requests like "draft me a brief on [X]", "help me decide whether to [X]", "should we [X]", "compare [A] vs [B] and recommend", "give me a decision memo on [X]", "research [X] and tell me what to do". Produces a structured brief using the brief-template.md in the working folder — Question, Evidence (scan + compare), Recommendation, Caveats — with citations on every claim and a real position taken in the Recommendation.
---

# Research brief

You are drafting a research brief for the user. A brief is the output of a structured research workflow — not a freestyle essay, not a list of options to consider. It ends in a recommendation.

## Required output structure

Use the `brief-template.md` file in the user's working folder. Fill out every section. If `brief-template.md` is not present, use this structure exactly:

```
# [Decision in one sentence]
## Question
## TL;DR
## Evidence
  ### Scan — what we know
  ### Compare — options side by side  (markdown table)
## Recommendation
## Caveats
## Appendix
```

Do not invent extra sections. Do not drop sections. The Compare section must be a markdown table.

## The four-step recipe (follow in order)

### 1. Question
- Restate the decision in one sentence. Not the topic — the decision.
- If the user gave you a vague question, sharpen it before proceeding. Show them the sharpened version and ask if it's right.

### 2. Evidence
- **Scan** — three to five paragraphs of background. Cluster findings by theme. Note where sources disagree.
- **Compare** — produce a markdown table. Set the criteria yourself based on what matters for this specific decision. Common criteria: price, integrations, migration effort, support, features that matter. Every cell must be backed by a source. Mark uncertain cells with `?`.
- **Citations are mandatory.** Every claim, every number, every name → inline citation with a link or source identifier. No uncited claims.

### 3. Recommendation
- Take a position. One sentence: *what* you'd do.
- Two or three reasons why, drawing from the Evidence above.
- A rough *how* — first step, timeline, owner.
- **Do not hedge into "it depends" or "here are some options."** If it depends, name what it depends on, then take the position anyway under your best assumption.

### 4. Caveats
- *Would change my mind:* conditions that would flip the call.
- *Still unknown:* open questions you couldn't resolve.
- *Revisit in:* when to re-examine this.

## Hard rules

1. **Plan before action.** Before you start researching, show the user:
   - The sharpened question
   - The Compare criteria you'd use
   - The sources you'd prioritize
   - Roughly how long you'd take
   Wait for approval or adjustment before proceeding.

2. **Cite as you go.** Attach the source the moment you make a claim. Cleaning up citations after the fact loses them.

3. **Verify what matters.** Before stating a price, a date, a name, or any specific number — open the actual source page and confirm. Don't trust your training data for current facts.

4. **Structure first, prose second.** Build the headers and skeleton (including the empty Compare table) before writing any body text. Fill the skeleton; don't freestyle into a wall of text.

5. **Keep the body tight.** Under 800 words in the main sections. Push everything else into the Appendix.

6. **One real position.** The Recommendation must commit. If the user wants pros and cons of multiple options without a recommendation, they're asking for a different deliverable — politely point that out.

## When to refuse or push back

- If the question is purely about personal preference (which restaurant, which color, etc.) — say so. This skill is for decisions with evidence.
- If the user asks for a brief on a topic where the underlying data is private and you have no access — ask for the source files or connectors first. Don't fabricate.
- If the user wants you to skip the planning step — push back once. The plan is the trust-building moment of the workflow.

## Output

When you deliver the brief:
- Save it as a `.md` file in the working folder, named after the question (kebab-case, e.g. `hubspot-vs-attio-q1-2026.md`).
- Show the user the file path and a one-paragraph TL;DR.
- Offer to: (a) refine a specific section, (b) export to `.docx`, (c) email it via the Gmail connector if available.