Purpose
Translate raw model output statistics into a stakeholder-ready business narrative that explains what the model does, how much to trust it, what decision it enables, and where it will fail — without jargon and without dumbing down the honest caveats. Solves the gap where a technically sound model dies in a meeting because the audience can't connect a 0.87 AUC to a dollar or a decision.
When to Use
Invoke this skill when the user asks to:
- Explain model results to executives, product managers, or clients
- Turn a model evaluation report into a slide narrative or exec summary
- Answer "so what does this mean for the business?" about a model
- Translate metrics like precision, recall, AUC, RMSE, or feature importance into plain language
- Prep for a stakeholder review, steering committee, or go/no-go decision meeting
- Justify deploying, retraining, or shelving a model to a non-technical decision-maker
Inputs Required
Before starting, collect:
- Model type: Classification, regression, forecasting, clustering, recommendation, or other
- What it predicts: The target variable in plain terms (e.g., "which customers will cancel next month")
- Key metrics: The actual numbers — accuracy, precision, recall, F1, AUC, RMSE, MAE, R², etc. (paste what you have)
- Business goal: The decision or outcome the model is meant to support
- Cost of errors: What a false positive vs. false negative actually costs (money, time, trust, risk)
- Audience: Executives / product / sales / clinical / regulatory / general — sets vocabulary and depth
- Baseline: What happens today without the model (current process, guesswork, or a prior model)
If cost-of-errors or baseline is missing, state the assumption explicitly and flag it as a question to confirm with the business.
Instructions
Step 1: Establish the Decision the Model Serves
Open every narrative from the decision, not the model. State in one sentence what business action the model changes: who acts differently, on what, and how often. If the model doesn't change a decision, say so — that's the most important finding.
Step 2: Translate Each Metric Into a Plain-Language Meaning
Convert numbers into consequences the audience can feel. Use this mapping discipline:
- Accuracy → "Out of 100 predictions, it gets X right" — but flag if classes are imbalanced (accuracy lies when 95% of cases are one class)
- Precision → "When the model says YES, it's right X% of the time" → tie to cost of chasing false alarms
- Recall → "Of all the real cases, it catches X%" → tie to cost of missing real cases
- AUC / ROC → "How well it separates the two groups; 0.5 is a coin flip, 1.0 is perfect" → give the plain rank interpretation, not the integral
- RMSE / MAE → "On average, its estimate is off by X [units]" → convert to the business unit (dollars, days, inventory)
- R² → "It explains X% of the variation in [outcome]" → not the same as being right, say so
- Feature importance → "The factors that most drive the prediction are…" → translate feature names to business terms
- Confusion matrix → describe the four cells as real events with real costs, not a grid
Never present a metric without its so-what. Every number gets one sentence of business meaning.
Step 3: Frame the Precision/Recall Trade-off as a Business Choice
Non-technical stakeholders should own the threshold decision, because it's a cost trade-off, not a math decision. Present it as: "If we tune it to catch more real cases, we also flag more false alarms. Given that a missed case costs [X] and a false alarm costs [Y], the recommended balance is [Z]." Make the trade-off legible and hand the lever to the business.
Step 4: Quantify the Business Impact Against Baseline
Compare the model to what happens today. Estimate impact in business units:
- Current-state error/cost vs. model-assisted error/cost
- Volume × improvement × unit value = rough annual impact
- Use conservative ranges, not single-point false precision State assumptions in the open. A defensible range beats a precise-looking number nobody trusts.
Step 5: State Limitations and Failure Modes Honestly
List where the model should not be trusted:
- Data drift risks (what changes in the world would break it)
- Segments where it performs worse (small samples, edge cases)
- What it does NOT predict or cause (correlation vs. causation reminders)
- Fairness/bias exposure if the audience or domain is regulated or sensitive Frame limitations as guardrails for good decisions, not as apologies.
Step 6: Give a Clear Recommendation
End with a decision, not a shrug. One of: deploy as-is, deploy with a human-in-the-loop, pilot on a segment, retrain with more data, or don't deploy. Justify it in one paragraph tied to the cost-of-errors and business goal.
Output Format
- Structure: Executive summary first (3–4 sentences a busy leader can read alone), then supporting sections
- Length: 550–850 words
- Format: Prose narrative with short bolded section headers; one optional plain-language table translating metrics to business meaning
- Sections: Executive Summary → What the Model Does → How Much to Trust It (metrics translated) → The Trade-off Decision → Business Impact vs. Today → Where It Fails → Recommendation
- Tone: Confident and plain — like a senior data scientist who respects the audience's intelligence but not their patience for jargon. No hedging, no equations, no undefined acronyms.
Quality Checklist
Before delivering output, verify:
- [ ] Every metric provided has a one-sentence plain-language "so what" — no naked numbers
- [ ] No undefined technical terms (AUC, F1, R², etc. are explained on first use or replaced)
- [ ] The precision/recall trade-off is framed as a business cost decision, not a technical one
- [ ] Business impact is estimated against the baseline in business units (dollars, time, or volume)
- [ ] At least two honest limitations or failure modes are stated
- [ ] The narrative ends with one explicit recommendation, not a list of options with no pick
Notes
- If classes are imbalanced, lead with precision/recall or a cost-weighted view — accuracy alone will mislead the room and destroy your credibility when someone catches it.
- Executives care about the decision and the downside; product cares about the trade-off lever; regulated audiences care about failure modes and fairness. Weight the sections toward the audience provided.
- When impact numbers are estimated, always show the assumption — a caveated range survives scrutiny; a confident-looking point estimate invites a takedown.
- If the model doesn't actually change any decision, the most valuable output is saying that plainly and stopping there.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills