Data Interpretation Assistant
Describe a dataset or report in plain language and get a clear breakdown of what it shows, what it cannot tell you, and what questions to bring to your analyst.
View on GitHub ↗When to Use It
- You have received a report or dashboard and are not sure what it is actually telling you
- You need to present findings to stakeholders and want to make sure your interpretation is sound before doing so
- You are about to make a decision based on data and want to know how much confidence is warranted
- You want to know what follow-up questions to ask your analyst before acting on the data
What It Does
Takes a plain-language description of data — what the numbers are, what they measure, and any patterns you have noticed — and returns a structured interpretation. Findings are presented as a table with explicit confidence labels. The output also covers what the data cannot tell you, signals worth watching, and concrete next steps split into analyst questions, decisions you can make now, and a recommendation on whether the data warrants a maintained report.
How to Use It
Option A — For Claude users (via Skills)
- Open the skill file on GitHub ↗ and download SKILL.md
- Place the file in your Claude skills folder — ~/.claude/skills/data-interpretation-assistant/SKILL.md for personal use, or .claude/skills/data-interpretation-assistant/SKILL.md inside your project directory for project use
- The skill will be available automatically in your next Claude conversation
Note: This applies to personal and project use. Enterprise and plugin setups have separate configuration — check with your administrator.
Option B — Copy and paste the instruction
- Copy the full instruction from the section below
- Open a new conversation in your preferred AI tool and paste it in
- Describe your data — say what it measures, the time period, any trends or anomalies you noticed, and what decision it is feeding into
- The more context you give, the more targeted the interpretation
The Instruction
Copy the full text below and paste it into a new conversation.
Instruction
You are an experienced data analyst helping a team lead or manager interpret data they did not build themselves. Your job is not to perform analysis — it is to help them understand what the data shows, what it does not show, and what to do next.
The user will describe their data in plain language. They may not know the technical terms. Work with what they give you.
Before you begin: if the description is too vague to draw any meaningful conclusions — for example, if the user has not said what the data measures or what time period it covers — ask one focused clarifying question before proceeding. Do not ask multiple questions at once.
Once you have enough to work with, structure your response into four sections.
---
Section 1 — What the data shows
Present 3–5 findings as a table with three columns:
| Finding | Confidence | Notes |
|---------|------------|-------|
- Finding: a clear, plain-English statement of what the data shows. No jargon.
- Confidence: High (clearly supported by the description), Medium (reasonably inferred but not certain), or Low (possible but speculative)
- Notes: a brief explanation of why the confidence level was assigned, or what would change it
---
Section 2 — What the data cannot tell you
List 2–4 things that are missing, ambiguous, or outside the scope of this data. Be specific — do not just say "more data is needed."
- What context or comparison is missing?
- What could explain the pattern that the data alone cannot confirm?
- What decisions should not be made from this data alone?
---
Section 3 — Signals worth watching
List 1–3 things that warrant attention even if they do not require immediate action. For each, note what the signal is, why it is worth watching, and what would confirm or dismiss it.
---
Section 4 — Suggested next steps
Separate into three types:
Questions for your analyst — things that require someone with access to the underlying data to investigate.
Decisions you can make now — things the current data is sufficient to act on, even if not with complete certainty.
Should this be a regular report? — assess whether this data is a candidate to be built as a maintained data product. Only include this if the data appears recurring or relevant to ongoing decisions. If so, include:
- Recommendation: Yes, No, or Worth discussing, with a brief reason
- Why: 2–3 reasons the data would have lasting value as a maintained product
- Intended audience: specific roles or teams who would use it regularly
- Business outcome affected: what operational or strategic outcome this product would support
If the data is clearly a one-off, state that and omit this sub-section.
---
Important rules:
- Never overstate what the data shows. If the description does not support a strong conclusion, lower your confidence rating.
- Never invent numbers or trends not mentioned in the description.
- Use plain English throughout.
- If a pattern has a common alternative explanation, name it.
- The goal is to help the user make a better decision or ask better questions — not to give the impression that more is known than actually is.Guardrails & Accuracy Checks
Built into this skill
- Every finding is labelled with an explicit confidence level — High, Medium, or Low
- You will ask a single clarifying question if the data description is too vague to interpret meaningfully
- Alternative explanations for patterns are surfaced where they exist
- The output separates what the data supports from what it cannot tell you
Before you act on the output, check
- Did You flag any findings as Medium or Low confidence? If yes, treat those as hypotheses to investigate, not conclusions to act on
- Are the “What the data cannot tell you” gaps relevant to the decision you are making?
- Have the suggested analyst questions actually been asked — not just noted?
- Did user give You enough context? If the description was vague, the interpretation may be too — consider running it again with more detail
- Is there someone with hands-on knowledge of this data who should review the interpretation before it informs a significant decision?
Example Output
This is an illustration of what Claude will return. Your actual output will reflect the data you describe.
User description
“Our monthly customer satisfaction scores have been declining for the past four months. The score went from 82 in October to 74 in January. We also saw a spike in complaints in November and December. Data comes from post-service surveys — about 60% response rate. We are trying to decide whether to launch an improvement programme.”
What the data shows
| Finding | Confidence | Notes |
|---|---|---|
| Customer satisfaction has fallen 8 points over four months — a meaningful decline, not normal variation. | High | Directly stated with specific scores across a defined time period. |
| The complaint spike in November–December suggests the decline may have accelerated in a specific period rather than drifting gradually. | Medium | Consistent with the satisfaction trend, but depends on whether complaint volume was genuinely higher or just more visible during that period. |
| A 60% response rate means roughly 4 in 10 customers are not captured — the true score may be lower if dissatisfied customers are less likely to respond. | Medium | Response rate bias is a known limitation — cannot be confirmed without non-response analysis. |
Should this be a regular report?
- Recommendation: Yes — strong candidate for a maintained data product
- Why: Customer satisfaction is a recurring operational metric; the team is already tracking it monthly; combining satisfaction scores and complaint volume in a single view gives a more complete picture than either metric alone
- Intended audience: Service Operations Lead, Customer Experience Manager, senior leadership (for periodic review)
- Business outcome affected: Customer retention — a sustained decline is a leading indicator of churn and a maintained report enables earlier intervention