Deep Research Brief: Decision-Ready Research in One Skill

Ask an AI assistant "should we switch CRMs?" and you'll get an answer. It will be well-organized, confidently written, and almost completely useless for making the actual decision. That's not because the model is bad. It's because you asked a vague question and got a vague answer dressed up in bullet points.

I built deep-research-brief to fix the process, not the model. It's a skill that refuses to research anything until it understands the decision you're trying to make. Then it plans the research, runs or structures it, and hands you a one-page brief with an options table, risks, a recommendation with a stated confidence level, and — this is the part I care about most — a hard wall between facts, analysis, and opinion.

This is the workflow I use for vendor evaluations, market questions, and "the boss asked me to look into X" tasks. Here's why most AI research fails, what this skill does differently, a worked example, and how to install it in two minutes.

The problem: confident summarizing is not research

Most of what gets called "AI research" is actually this: the model retrieves a handful of things it half-remembers or half-reads, blends them into smooth prose, and presents the blend with the same confident tone whether the underlying material was a vendor's pricing page or a Reddit comment from 2021.

Three specific failures show up over and over:

1. No decision framing. Real research serves a decision. "Tell me about CRM options" and "we're a 40-person B2B company deciding by end of quarter whether to leave HubSpot, and migration cost is the main worry" are completely different research tasks. Without the second framing, you get an encyclopedia article. With it, you get an answer.

2. Facts and opinions arrive pre-mixed. When a human analyst writes "Vendor A costs $45/seat/month, which is expensive for what you get," there are two claims in that sentence: a fact you can verify and a judgment you might disagree with. AI output fuses these constantly. You can't audit what you can't separate — and if you're presenting this research to your manager or your team, you will be asked "where did that number come from?" and "is that a fact or your take?"

3. No sources, no dates, no way to check. Pricing changes. Products ship features. A summary that doesn't tell you where each claim came from and when it was true is a summary you have to redo by hand before you can trust it — which defeats the purpose.

The fix isn't a smarter model. It's a repeatable workflow that forces structure at every step. That's exactly what a skill is for.

What deep-research-brief does differently

The skill runs a four-stage pipeline. Each stage produces something you can see and correct before the next one starts.

Stage 1: Clarifying questions — always, no exceptions

Before any research happens, the skill asks 3–5 questions:

• What decision does this research feed? Not the topic — the decision. "Switch CRMs or stay" is a decision. "CRMs" is a topic.
• When is the decision being made, and by whom? A brief for you is different from a brief for your VP.
• What are the hard constraints? Budget ceilings, must-have integrations, compliance requirements, team size, contract end dates.
• What do you already know or believe? So the research can confirm or challenge it instead of repeating it.
• What would make this an easy "no"? Dealbreakers first — they prune half the research tree.

This mirrors how I think about interviewing the user before writing code — my grill-me writeup covers why the questions-first pattern beats eager answering everywhere, not just in research.

Stage 2: A research plan you can veto

The skill then writes a short plan: the decision restated in one sentence, 4–7 sub-questions that would collectively answer it, the source types to check for each (vendor docs, pricing pages, independent reviews, community threads, analyst material), and the actual search queries it intends to run. You approve, edit, or redirect the plan before time gets spent. Thirty seconds of plan review saves an hour of wrong research.

Stage 3: Research — live or bring-your-own

If web search is available in your environment, the skill runs the queries itself. If it isn't — or if your best sources are internal docs, a sales call transcript, or a vendor proposal PDF — you paste material in and the skill slots it into the plan's structure. Either way, every claim gets logged with its source and date, and conflicts between sources get flagged instead of silently averaged. This is also a context-discipline play: structured collection keeps the working context tight, which is the same principle behind context-engineering.

Stage 4: The brief

The output is a fixed template, every time:

• One-page summary — the decision, the recommendation, and the three facts that matter most.
• Options table — each option with pros, cons, and costs, in comparable terms.
• Risks — what could go wrong with the recommended path, with likelihood and impact.
• Recommendation with confidence level — High, Medium, or Low, and why it's at that level.
• "What would change my mind" — the specific facts that, if they turned out differently, would flip the recommendation. This section is the honesty test; a brief that can't name its own tripwires is an opinion piece.
• Appendix of sources — every source, dated, with a one-line note on what it supported.

And throughout, every claim is tagged: [FACT] with a source, [ANALYSIS] reasoned from facts, or [OPINION] flagged as judgment. Your reader can audit any line back to its origin.

Worked example: the CRM question (abbreviated)

Here's roughly how a real run goes. I ask: "Should we switch CRMs?"

The skill asks: What CRM now, and what's broken? Who decides, by when? Budget and team size? Must-have integrations? What would make you stay put?

I answer: HubSpot Starter, 12-person sales team, reporting is the pain point, decision by end of Q3, ~$800/month ceiling, must integrate with our Postgres warehouse, we'd stay if reporting could be fixed without migrating.

The plan comes back: Sub-questions include "Can HubSpot's reporting gap be closed with an add-on or tier upgrade?" (note: this could end the research early — the stay-put option gets investigated first because I said it was live), "What do Pipedrive and Attio cost at 12 seats with warehouse sync?", and "What do migration horror stories from HubSpot actually look like — time, data loss, adoption dip?"

The brief lands with: an options table (Stay + upgrade tier / Pipedrive / Attio) with per-seat costs and totals against my $800 ceiling; a risk section noting [FACT] several documented migrations reported 4–8 weeks of pipeline-data cleanup, sourced and dated; and a recommendation: stay and upgrade the reporting tier, confidence Medium — with "what would change my mind" listing two tripwires: if the upgraded tier still can't produce the two reports the team needs, or if the renewal quote comes in above the alternatives' total cost. That's a brief I can forward as-is.

Install

Download the skill file, then place it at:

~/.claude/skills/deep-research-brief/SKILL.md

One directory, one file. Open Claude Code and say "use deep-research-brief to figure out whether we should switch CRMs" — or any decision-shaped question. The skill triggers on research and vendor-evaluation requests automatically. If you want the full picture of what Claude Code is and why skills work this way, I wrote a plain-English explainer.

The weekly workflow: staying ahead at work

The skill is most valuable when it stops being a one-off tool and becomes a habit. Here's mine:

Monday (15 min): Write down the one decision-shaped question that would most help your team this quarter if it were answered well. Run Stage 1 and Stage 2 only — questions and plan. Let it sit.

Midweek (30 min): Run the research stage. Paste in anything internal — meeting notes, vendor emails, that Slack thread. If your notes are a mess, run them through meeting-notes-to-actions first, then feed the cleaned-up output into the brief.

Friday (15 min): Generate the brief, read it critically, and send it to whoever owns the decision — even if they didn't ask. A dated, sourced, confidence-rated brief that separates facts from opinion is rare enough in most workplaces that doing it weekly quietly makes you the person leadership asks first.

One brief a week is roughly fifty researched decisions a year. Nobody else on your team is doing that.

FAQ

Does this need web search to work? No. With search available, it researches live. Without it, it structures whatever you paste in — internal docs, transcripts, PDFs, memory. The discipline (sources, dates, fact/opinion separation) applies either way; the skill just marks unsourced material as such.

How is this different from just asking Claude to "research X thoroughly"? "Thoroughly" isn't a process. This skill enforces one: decision framing before research, a plan you approve, source-quality rules, and a fixed output template. You get the same shape of brief every time, which means you can actually compare this week's brief to last month's. Repeatability is the whole point — the same reason structured prompting beats improvised prompting generally.

What if I disagree with the recommendation? Then the brief has done its job. Because facts, analysis, and opinion are tagged separately, you can accept the facts, keep the analysis, and swap the recommendation — and say exactly why. That's a real disagreement, not a vibes disagreement.

Isn't the clarifying-questions step annoying for quick lookups? For quick factual lookups, don't use this skill — just ask. This is for decisions: anything where you'd be embarrassed to be wrong in front of your team. The five questions take two minutes and routinely cut the research scope in half.

Won't the sources go stale? Yes — which is why every source is dated and the brief states its own freshness. When you revisit the decision in six months, you can see at a glance which facts need re-checking. An undated brief can't tell you that; this one can.

Does it work for non-vendor decisions? Anything decision-shaped: market entry, hiring a contractor vs. an agency, build vs. buy, which conference to sponsor, whether a trend is worth acting on. If there are options, constraints, and a deadline, the template fits.

Resources & links

• /skills/meeting-notes-to-actions — turn raw meeting notes into structured actions; feeds cleanly into this skill's research stage.
• /skills/context-engineering — the discipline of controlling what's in the model's context; the theory behind Stage 3.
• /skills/grill-me — the questions-before-answers pattern applied to writing code instead of research.
• /skills/karpathy-guidelines — writing skill instructions models actually follow; useful if you customize this SKILL.md.
• /blog/six-claude-prompts-ahead-of-99-percent — six prompt patterns that outperform what most people type; two of them live inside this skill.
• /blog/cut-claude-token-usage-in-half — keeping long research sessions cheap and focused.
• /blog/prompt-engineering-complete-guide-2026 — the full guide to structured prompting; this skill is that guide applied to research.
• /blog/claude-code-explained-for-normal-people — what Claude Code is and how skills like this one plug into it.

If briefs like this are useful to you, I send one practical AI workflow like this every week — join me at alexandrrich.substack.com.