---
name: insight-reporter
description: Use when the task is to turn completed analysis into a stakeholder-ready communication artifact. Triggers include executive summary, final report, decision memo, stakeholder memo, recommendation brief, client-facing writeup, presentation narrative, non-technical summary, or "communicate these findings." Also use when the user asks for a fresh-chat handoff summary after a completed analysis session. Do NOT use for raw EDA, metric calculations, model validation, dashboard layout, or experiment validity checks — those belong to data-explorer, metric-analyst, model-auditor, dashboard-designer, and experiment-analyst respectively.
---

> Part of the [data-scientist](https://github.com/DAlanMtz/data-scientist) skill suite. Install `data-scientist` for full lifecycle methodology, routing, and review orchestration.

# Insight Reporter

## Purpose

Turn completed analysis results into stakeholder-ready communication. The audience is a decision-maker — not an analyst. The deliverable is a document that presents a clear answer, supported by evidence, with appropriate caveats, and ends with a recommended action.

This skill does not re-run analysis. It takes findings as inputs and structures them for communication. The posture is honest, direct, and evidence-bounded: conclusions follow from evidence, uncertainty is visible, and the recommendation is actionable.

## When To Use This Skill

Use `insight-reporter` when:

- The user asks for an executive summary, final report, decision memo, stakeholder memo, or recommendation brief.
- The user asks to "write up" or "communicate" analysis findings for a non-technical audience.
- The user asks for a presentation narrative, a client-facing writeup, or a concise findings document.
- The user asks for a fresh-chat handoff summary after completing analysis work.
- Findings exist (or are assumed) and the task is to structure them for a decision-maker, not to produce new analysis.

## When Not To Use This Skill

| Situation | Use instead |
|---|---|
| Raw EDA, data profiling, schema inspection | `data-explorer` |
| Metric definitions, KPI logic, SQL queries | `metric-analyst` |
| A/B testing, statistical testing, experiment readout | `experiment-analyst` |
| Model validation, leakage, calibration | `model-auditor` |
| Dashboard, scorecard, HTML visual layout | `dashboard-designer` |
| No findings yet — analysis is still needed | `data-scientist` (parent) → appropriate specialist |

## Relationship to Parent Skill

| Responsibility | Owner |
|---|---|
| Analysis, investigation, modeling | Parent `data-scientist` or specialist sibling |
| Routing to this skill | Parent `data-scientist` (`workflow/specialist-routing.md`) |
| Evidence, findings, conclusions | The completed analysis being communicated |
| Structuring findings for stakeholders | **This skill** |
| Evidence hierarchy and caveats | **This skill** |
| Communication review | **This skill** |

## Entry Gates

Before beginning, confirm or state as working assumptions:

1. **Findings or analysis context** — What was found? What did the analysis show? (If not provided, draft with explicit placeholder assumptions.)
2. **Audience** — Who will read this? Executive, technical stakeholder, client, board? (Assume "senior non-technical stakeholder" if unknown.)
3. **Decision or action** — What decision does this communication support, or what action should follow? (State as "decision unknown — draft for clarity" if absent.)
4. **Artifact type** — Executive summary, decision memo, recommendation brief, or fresh-chat handoff?

Missing entry gate items are not blockers. State them as explicit assumptions and proceed. Ask only if the item materially prevents drafting a useful document.

## Required Workflow

1. **Identify audience and decision.** State who will read this and what they need to decide or do. If unknown, state working assumptions.
2. **Extract the main answer.** What is the one-sentence conclusion? State it first, not last.
3. **Build the evidence hierarchy.** Separate primary evidence (directly supports the conclusion), secondary evidence (corroborating), and context (background that does not change the conclusion).
4. **Separate facts, interpretation, and recommendation.** Facts: what the data shows. Interpretation: what it means. Recommendation: what to do. Do not blend these.
5. **Add caveats and uncertainty.** What assumptions were made? What data was missing or limited? What could change the conclusion?
6. **Write the recommendation and next action.** One clear recommended action. Name who should take it and by when if known.
7. **Run the communication review** (Review Checklist below). Fix issues silently or disclose as noted caveats.
8. **Handoff.** If this communication closes a project, produce a fresh-chat handoff summary for the parent `data-scientist` skill to use for artifact inventory and closeout.

## Output Formats

Select based on the task:

| Format | Use when |
|---|---|
| **Executive summary** | 1–2 page synthesis for senior stakeholders; answer first, then evidence |
| **Decision memo** | Structured single-page format with recommendation, evidence, and open questions |
| **Final analysis report** | Full writeup with methodology, findings, caveats, and recommendation sections |
| **Recommendation brief** | Short 3–5 paragraph synthesis focused on what to do and why |
| **Fresh-chat handoff summary** | Session context, completed work, key findings, open risks, recommended starting point |

Default to **decision memo** when the artifact type is unspecified and a decision is involved. Default to **executive summary** when the audience is leadership and no specific format is requested.

## Standard Decision Memo Format

```
**[Title]**
Date: [date or "current"]
Audience: [who this is for]
Prepared by: [analyst or team, if known]

**Bottom line:** [1–2 sentence conclusion and recommendation]

**Key findings:**
- [Finding 1 — fact, not interpretation]
- [Finding 2]
- [Finding 3]

**Evidence basis:** [What analysis supports the findings — method, data, time window]

**Interpretation:** [What the findings mean in business terms]

**Recommendation:** [Specific action]
**Next step:** [Who does what, by when]

**Caveats and assumptions:**
- [Limitation 1]
- [Limitation 2]

**Open questions:** [What would change the recommendation if answered differently]
```

## Review Checklist

Run before finalizing any communication artifact:

| # | Check | Pass condition |
|---|---|---|
| IR1 | Conclusion is supported by evidence | Every stated conclusion traces back to a finding — no invented claims |
| IR2 | Caveats are visible | Assumptions, data limits, and uncertainty are stated — not hidden or buried |
| IR3 | Uncertainty is not suppressed | Language does not overclaim; hedges match the evidence strength |
| IR4 | Recommendation follows from findings | The recommended action is logically connected to the stated evidence |
| IR5 | Next action is clear | One specific next step is named — not "we should consider further analysis" |
| IR6 | Audience detail level is appropriate | Jargon, depth, and length match the stated audience |
| IR7 | Facts, interpretation, and recommendation are separated | The reader can distinguish what happened, what it means, and what to do |

**Common failure modes:**
- Confidence language that outpaces the evidence ("this proves that…")
- Recommendations buried at the end after excessive context
- Caveats hidden in footnotes or omitted entirely
- Interpretation presented as fact
- No clear next action

## Handoff Back to `data-scientist`

When the communication artifact is complete:

- If this closes a project, produce the Fresh-Chat Handoff Summary format from `data-scientist`'s `workflow/control-tree.md`.
- Note what artifacts exist (reports, memos, dashboards) and their location.
- State any open items the stakeholder raised that require follow-up analysis.
- Recommend whether a full closeout is appropriate or whether follow-up analysis is needed first.