decision-brief

name	decision-brief
description	Template for structured options analysis with pros/cons and a recommendation. Loaded by the Researcher agent — not user-invocable.
user-invocable	false

Template: Decision Brief

Purpose

Use this template when the user needs to choose between options or alternatives. The brief should present each option fairly, compare them on relevant criteria, and provide a recommendation grounded in evidence.

Output Structure

Your report MUST follow this exact structure. Every section is required. Do not skip or reorder sections.

# Decision Brief: <Decision Statement>

## Context

What decision needs to be made and why. What are the constraints (timeline, budget, team, technical)? Who are the stakeholders? What does "success" look like?

## Options Considered

### Option 1: <Name>

**Description:** What this option entails — a clear, concrete explanation of what choosing this option means in practice.

**Pros:**
- Specific advantage with brief explanation.
- Another advantage.

**Cons:**
- Specific disadvantage with brief explanation.
- Another disadvantage.

**Estimated effort/cost:** Rough order of magnitude — time, money, team resources, complexity.

**Key risks:** What could go wrong if you pick this option? What assumptions is it built on?

### Option 2: <Name>

(Same structure as Option 1.)

### Option N: <Name>

(As many options as relevant. Minimum 2, typically 3-5.)

## Comparison Matrix

| Criterion       | Option 1 | Option 2 | Option N |
|-----------------|----------|----------|----------|
| <Criterion 1>   | ...      | ...      | ...      |
| <Criterion 2>   | ...      | ...      | ...      |
| <Criterion N>   | ...      | ...      | ...      |

(Choose criteria that matter most for the decision. Rate options concretely — not just "good/bad" but specific assessments.)

## Recommendation

State your recommendation clearly: "I recommend **Option X** because..."

Justify with evidence gathered during research. Reference specific pros, cons, and criteria from above.

State under what conditions the recommendation would change: "If [condition], then Option Y would be preferable instead."

## Dissenting Considerations

Present the strongest arguments against your recommendation. This section exists to ensure the decision-maker sees the full picture, not just the case for your pick. A good dissent section makes the recommendation more credible, not less.

## Open Questions

What additional information would strengthen the analysis? What couldn't you determine? What assumptions did you make that should be validated?

## Sources

1. [Source Name](URL) — What this source contributed to the analysis.
2. [Source Name](URL) — Description.
(Number all sources.)

Analytical Lens

• Steelman each option. Before comparing, make the strongest possible case for each option. Don't set up strawmen.
• Research each option independently before comparing. This prevents anchoring on the first option you investigate.
• Recommendation follows evidence. Do not decide your recommendation before research. Let the gathered evidence drive the conclusion.
• Be concrete about tradeoffs. "Option A is faster but less maintainable" is weak. "Option A can be implemented in ~2 weeks but requires a custom parser that only 1 team member can maintain" is strong.
• Name the criteria that matter. The comparison matrix should reflect criteria relevant to the specific decision, not generic "quality" axes. Derive criteria from the context and constraints.

Quality Checklist

Before delivering the report, verify:

• Context section makes the decision and its stakes clear
• Every option is described concretely enough that the reader knows what "choosing it" means
• Pros and cons are specific and evidence-based, not generic
• Each option was researched independently (not just "Option A is like Option B but...")
• Comparison matrix uses decision-relevant criteria
• Recommendation is justified by evidence in the report, not asserted
• Dissenting section presents genuine counterarguments, not token objections
• Open Questions identifies meaningful gaps, not just filler
• All sources are listed with URLs
• A decision-maker could act on this brief without additional research

Grimoire Publishing

• Sub-path: research-agent-deep/decision-briefs/
• Type tag: type/decision-brief
• source_agent: researcher

When publishing to the Grimoire, do not include YAML frontmatter in the file. The CLI manages frontmatter via create-file-metadata. Include descriptive topic tags alongside the type tag.

Gathering Strategy

1. Parse the brief to identify the options (they may be explicit or need to be discovered).
2. Research each option independently — run separate WebSearch queries for each. Don't research them all in one query.
3. For each option, look for: official documentation, benchmarks, case studies, community experience reports, known failure modes.
4. Search for head-to-head comparisons others have done — these often surface criteria you hadn't considered.
5. Check local files if the decision relates to the current project (e.g. existing architecture docs, past decisions, ADRs).
6. Aim for at least 3 substantive sources per option.