30 Claude Prompts Built for Data Scientists
Every prompt below asks for a finished EDA report, experiment plan, or model writeup, not a lecture on statistics. Fill in the bracketed inputs and Claude hands back a draft you can bring to your next stand-up. Not "give me some advice".
In short: This page contains 30 copy-paste ready prompts, organized into 6 categories with a description and pro tip for each. The first 5 prompts are free instantly, no signup needed. Hand-curated and tested by the AI Academy team.
EDA & Data Profiling
5 promptsExploratory Data Analysis (EDA) Report
1/30✨ What it does
Claude structures a first-look exploratory report around your dataset's real columns and the business question behind it. Scan the findings, then decide whether the data is ready to model.
You are a senior data scientist who turns raw datasets into structured first-look reports for a team. <context> A new dataset has landed and the team needs a first-look report before deciding how to model it. </context> <inputs> - Dataset name or description: [PLACEHOLDER] - Columns with types: [PLACEHOLDER] - Sample size: [PLACEHOLDER] - Business question the analysis should inform: [PLACEHOLDER] </inputs> <task> Produce an EDA report covering summary statistics per column, notable distributions, correlations worth flagging, and data issues found. </task> <constraints> - Base every claim on the columns and sample described, do not invent statistics. - Mark any statistic you cannot compute without the actual data as [ESTIMATE PLACEHOLDER]. - Tie the findings section back to the stated business question. </constraints> <format> A report with sections Summary Statistics, Distributions, Correlations, Data Issues, Next Steps. </format>
Pro tip: List column types precisely (numeric, categorical, datetime). Claude will tailor which statistics it flags per column type.
Data Quality Audit Report
2/30✨ What it does
Claude rates a dataset's quality field by field and gives a clear proceed-or-stop call before it trains a model. Fix the failing fields, then only feed the dataset once the audit clears for you.
You are a senior data scientist auditing a dataset before it feeds a model. <context> A dataset is about to be used for a model and needs a documented quality audit first. </context> <inputs> - Dataset description: [PLACEHOLDER] - Known fields: [PLACEHOLDER] - Sample issues noticed (missing values, duplicates, type mismatches): [PLACEHOLDER] - Intended model or analysis use: [PLACEHOLDER] </inputs> <task> Audit completeness, consistency, and validity per field group, and recommend fixes before modeling proceeds. </task> <constraints> - Rate each area Good, Fair, or Poor with a stated reason. - Do not invent an issue that isn't implied by the input. - Order remediation steps by priority. </constraints> <format> A table with columns Field/Area, Rating, Issue, Fix, plus a one-line go/no-go for modeling as-is. </format>
Pro tip: List even one or two concrete issues you've noticed. Claude will use them as evidence instead of a generic audit.
Feature Summary Table With Distributions
3/30✨ What it does
Claude builds a one-glance feature reference table tied to your actual target variable. Keep the table open while you engineer features, then drop columns that do not belong.
You are a senior data scientist preparing a feature reference before feature engineering starts. <context> Feature engineering is about to start and the team wants a quick reference table of every feature first. </context> <inputs> - Features with type (numeric, categorical, datetime): [PLACEHOLDER] - Rough range or category counts, if known: [PLACEHOLDER] - Target variable: [PLACEHOLDER] </inputs> <task> Build a feature summary table with type, range or cardinality, missingness, and a one-line note on relevance to the target. </task> <constraints> - Every feature listed in the input must appear as a row. - Mark missingness [UNKNOWN] if not given rather than guessing a number. - The relevance note must reference the stated target variable. </constraints> <format> A table with columns Feature, Type, Range/Cardinality, Missing %, Relevance Note. </format>
Pro tip: Name the target variable explicitly even if it seems obvious. The relevance notes are only useful when Claude knows what it's predicting.
Missing-Data Handling Plan
4/30✨ What it does
Claude classifies why each field is missing data and recommends a specific, justified handling method. Apply the method it names, then document the choice in your model notes.
You are a senior data scientist deciding how to handle gaps in a dataset before modeling. <context> A dataset has meaningful gaps in several fields and a documented plan is needed before deciding how to fill them. </context> <inputs> - Fields with missing data and rough missing percentage: [PLACEHOLDER] - Likely reason for missingness, if known: [PLACEHOLDER] - Downstream use of the data: [PLACEHOLDER] </inputs> <task> For each field, classify the missingness pattern (MCAR, MAR, or MNAR, with reasoning) and recommend a specific handling method (drop, impute, or flag) with justification. </task> <constraints> - Every field listed must get a recommendation. - Justification must reference the missing percentage or reason given. - Do not recommend dropping a field with high stated importance without flagging the tradeoff. </constraints> <format> A table with columns Field, Missing %, Likely Pattern, Recommended Method, Justification. </format>
Pro tip: If you have a guess at why data is missing (a form field made optional, a sensor outage), include it. It's the strongest signal for MAR versus MNAR.
Outlier Detection and Treatment Plan
5/30✨ What it does
Claude recommends a detection method and treatment decision per field, tuned to how sensitive your model is to outliers. Apply the treatments, then retrain and compare the metrics yourself.
You are a senior data scientist deciding how to handle outliers before training a model. <context> Numeric fields likely contain outliers, and the team needs a documented detection and treatment approach before modeling. </context> <inputs> - Fields to check: [PLACEHOLDER] - Rough value ranges or known extreme values: [PLACEHOLDER] - Sensitivity of the downstream model to outliers (for example linear vs tree-based): [PLACEHOLDER] </inputs> <task> Recommend a detection method per field (IQR, z-score, or a domain threshold) and a treatment decision (cap, remove, or keep and flag) with reasoning tied to the model type. </task> <constraints> - The detection method must fit the field's described distribution. - The treatment decision must account for the stated model sensitivity. - Flag any field where an outlier might be genuine signal rather than an error. </constraints> <format> A table with columns Field, Detection Method, Treatment, Reasoning. </format>
Pro tip: State the model type (linear vs tree-based) even roughly. It's the single biggest factor in whether an outlier should be capped or left alone.
Experiment Design & A/B Testing
5 promptsA/B Test Design Document
6/30✨ What it does
Claude turns a proposed test idea into a design document with a falsifiable hypothesis and named guardrail metrics. Lock the design, then refuse to change the primary metric after your launch.
You are a senior data scientist who designs experiments for a product team. <context> Product wants to test a change and needs a rigorous test design document before anything launches. </context> <inputs> - Hypothesis being tested: [PLACEHOLDER] - Primary metric: [PLACEHOLDER] - Secondary metrics: [PLACEHOLDER] - Expected traffic or users per week: [PLACEHOLDER] - Minimum detectable effect of interest: [PLACEHOLDER] </inputs> <task> Produce a test design covering the hypothesis, variants, primary and secondary metrics, the randomization unit, and guardrail metrics. </task> <constraints> - The hypothesis must be falsifiable and specific, not "the change will help". - Guardrail metrics must be distinct from the primary metric. - State the randomization unit explicitly: user, session, or account. </constraints> <format> A document with sections Hypothesis, Variants, Metrics (Primary/Secondary/Guardrail), Randomization Unit, Duration Rationale. </format>
Pro tip: State your expected weekly traffic even as a rough number. It's what lets Claude give an honest duration rationale instead of a vague one.
Sample Size and Power Calculation Memo
7/30✨ What it does
Claude shows the sample-size math and gives a rounded, defensible test duration stakeholders can plan around. Put that duration on the calendar, then do not stop the test early on your side.
You are a senior data scientist explaining test duration to stakeholders who want a launch date. <context> Before launching a test, stakeholders want to know exactly how long it needs to run and why. </context> <inputs> - Baseline conversion rate or metric value: [PLACEHOLDER] - Minimum detectable effect: [PLACEHOLDER] - Desired significance level and power (or "use standard 95%/80%"): [PLACEHOLDER] - Weekly traffic: [PLACEHOLDER] </inputs> <task> Walk through the sample size calculation logic and state the resulting required sample size and estimated test duration in weeks. </task> <constraints> - Show the inputs used in the calculation explicitly. - State assumptions clearly, for example that it's a two-sided test. - Round the duration up to a whole number of weeks. </constraints> <format> A short memo with a stated formula or logic section, then a results line: Required N, Estimated Duration. </format>
Pro tip: Give the baseline metric value even as a rough recent average. The required sample size is highly sensitive to it.
Experiment Readout Report
8/30✨ What it does
Claude writes a ship, hold, or iterate readout that separates statistical significance from whether the result actually matters. Carry the recommendation into the decision meeting, then do not ship a pretty-but-empty result from your test.
You are a senior data scientist writing up finished test results for stakeholders. <context> An A/B test has finished collecting data and the results need a clear writeup before a ship decision is made. </context> <inputs> - Test name: [PLACEHOLDER] - Primary metric result per variant, with sample sizes: [PLACEHOLDER] - Secondary metric results: [PLACEHOLDER] - Statistical significance info, if calculated: [PLACEHOLDER] </inputs> <task> Write a readout stating the result, whether it's statistically significant, the practical significance, and a ship, hold, or iterate recommendation. </task> <constraints> - Distinguish clearly between statistical significance and practical significance. - The recommendation must follow from the stated numbers, not from assumed intent. - Flag if the sample size seems too small to trust the result. </constraints> <format> A report with sections Result Summary, Significance, Recommendation, Caveats. </format>
Pro tip: Include the sample size per variant, not just the metric values. Claude will flag an underpowered result instead of treating it as conclusive.
Causal Inference Analysis Plan
9/30✨ What it does
Claude recommends a causal method that fits your data structure and names exactly which assumption it rests on. Check that assumption against the data you have, then run the method only if it holds.
You are a senior data scientist designing an analysis when a true randomized test isn't possible. <context> Randomization wasn't possible for this question, and a causal analysis plan is needed for observational data instead. </context> <inputs> - Treatment or intervention of interest: [PLACEHOLDER] - Outcome metric: [PLACEHOLDER] - Available covariates: [PLACEHOLDER] - Why randomization wasn't possible: [PLACEHOLDER] </inputs> <task> Recommend a causal inference approach, such as difference-in-differences, propensity score matching, or an instrumental variable, suited to the situation, with the key assumption it relies on and how to check it. </task> <constraints> - The recommended method must fit the described data structure. - State the core identifying assumption explicitly. - Name at least one way to test or validate that assumption with the available covariates. </constraints> <format> A memo with sections Recommended Method, Why This Method, Key Assumption, Validation Approach. </format>
Pro tip: List every covariate you have, even ones you don't think matter. They're often exactly what makes a matching or DiD approach valid.
Experiment Pre-Registration Document
10/30✨ What it does
Claude locks in a single primary hypothesis, method, and stopping rule before any data comes in. File the pre-registration, then refuse to peek until your test ends.
You are a senior data scientist who locks in analysis decisions before looking at results, to avoid p-hacking. <context> The team wants to commit to a hypothesis and analysis plan before any results are looked at. </context> <inputs> - Hypothesis: [PLACEHOLDER] - Primary metric and analysis method planned: [PLACEHOLDER] - Sample size or duration planned: [PLACEHOLDER] - Secondary analyses planned, if any: [PLACEHOLDER] </inputs> <task> Write a pre-registration document locking in the hypothesis, primary analysis, and stopping rule before data collection begins. </task> <constraints> - The primary metric and method must be singular and specific, not "we'll look at a few metrics". - State the stopping rule: fixed horizon, or sequential test with correction. - Label every secondary analysis explicitly as exploratory. </constraints> <format> A document with sections Hypothesis, Primary Analysis Plan, Stopping Rule, Exploratory Analyses (labeled as such). </format>
Pro tip: Pick one primary metric before writing this, even if you're tempted to track five. The document only holds you accountable if it's singular.
Model Documentation & Evaluation
5 promptsModel Card
11/30✨ What it does
Claude documents a model's intended use, training data, and a concrete failure mode before it ships. Attach the card to the review, then block production if a limitation you listed is still open.
You are a senior data scientist documenting a model before it goes into production or review. <context> A trained model needs standard documentation covering its intended use, training data, and limitations before it's approved for production. </context> <inputs> - Model name or type: [PLACEHOLDER] - Training data description: [PLACEHOLDER] - Intended use: [PLACEHOLDER] - Known limitations: [PLACEHOLDER] - Key performance metric(s) and value: [PLACEHOLDER] </inputs> <task> Produce a model card covering intended use, training data summary, performance metrics, and known limitations and risks. </task> <constraints> - Intended use must be specific, not "general purpose". - The limitations section must include at least one concrete failure mode based on the described training data. - Report metrics using only the values stated, do not invent numbers. </constraints> <format> A model card with sections Overview, Intended Use, Training Data, Performance, Limitations and Risks. </format>
Pro tip: Describe the training data's known gaps (a time period, a region, a user segment it under-represents). That's exactly what a good limitations section needs.
Model Evaluation Report
12/30✨ What it does
Claude compares candidate models on your actual metrics and recommends one based on what the business actually needs. Deploy the recommended model, or rerun if a metric you care about was missing.
You are a senior data scientist comparing candidate models before a deployment decision. <context> Multiple candidate models were trained and need a comparative evaluation writeup before one is chosen for deployment. </context> <inputs> - Models compared: [PLACEHOLDER] - Evaluation metrics used: [PLACEHOLDER] - Metric values per model: [PLACEHOLDER] - Business context for what matters most: [PLACEHOLDER] </inputs> <task> Compare the models on the given metrics, identify the tradeoffs between them, and recommend one for deployment given the stated business context. </task> <constraints> - Use only the metric values provided. - Explicitly name the tradeoff, for example precision versus recall, if models differ on more than one metric. - The recommendation must reference the business context given, not just the highest metric. </constraints> <format> A comparison table (Model, Metric 1, Metric 2, and so on) followed by a Tradeoffs and Recommendation section. </format>
Pro tip: State the business context plainly, for example whether false positives or false negatives cost more. That single sentence changes the recommendation.
Feature Importance and Explainability Writeup
13/30✨ What it does
Claude translates feature importance scores into plain-language explanations a non-technical stakeholder can use. Walk them through the top drivers, then act on the ones you can actually change.
You are a senior data scientist translating model internals into something a stakeholder can act on. <context> Stakeholders want to understand what's driving a model's predictions, not just how accurate it is. </context> <inputs> - Model type: [PLACEHOLDER] - Top features and their importance scores or SHAP-style values: [PLACEHOLDER] - Business meaning of the top features: [PLACEHOLDER] </inputs> <task> Explain what the top features mean for predictions in plain language a non-technical stakeholder can act on. </task> <constraints> - Translate every technical feature name into a plain-language explanation of its real-world meaning. - Do not claim a causal effect from an importance score alone. - Note if any top feature raises a fairness concern worth flagging. </constraints> <format> A writeup with a ranked list of top features, each with its importance score and a plain-language explanation. </format>
Pro tip: Give the business meaning of each top feature yourself if you know it. Claude will lean on your framing instead of guessing at what a feature name implies.
Model Monitoring Plan
14/30✨ What it does
Claude defines exactly what to monitor and what happens when a threshold trips, before the model goes live. Wire the alerts, then rehearse the response for the first trip on your watch.
You are a senior data scientist setting up production monitoring for a model that's about to go live. <context> A model is about to go live and needs a monitoring plan that catches drift or degradation before it causes real damage. </context> <inputs> - Model name: [PLACEHOLDER] - Key input features to monitor: [PLACEHOLDER] - Performance metric used in production: [PLACEHOLDER] - Expected retraining cadence: [PLACEHOLDER] </inputs> <task> Define what to monitor (input drift, prediction drift, performance metric), the thresholds that should trigger an alert, and an escalation or retraining trigger. </task> <constraints> - Every metric monitored needs a stated threshold or a method for setting one. - Alert thresholds must be tied to a concrete consequence, for example retrain or page the on-call. - The retraining cadence must reflect the stated expectation. </constraints> <format> A table with columns What to Monitor, Method, Alert Threshold, Action if Triggered. </format>
Pro tip: Name your actual key input features, not just 'the inputs'. Drift monitoring is only useful when it's scoped to specific fields.
Bias and Fairness Assessment
15/30✨ What it does
Claude checks whether a model's performance actually differs across the specific groups you name, with no invented findings. Review the gaps, then hold deployment if a group of yours is worse.
You are a senior data scientist running a fairness check on a model that affects people. <context> A model affecting people needs a documented fairness check before deployment, scoped to the groups that are actually relevant here. </context> <inputs> - Model's decision or prediction: [PLACEHOLDER] - Protected or sensitive groups relevant to the use case: [PLACEHOLDER] - Performance metrics available by group, if any: [PLACEHOLDER] - Deployment context: [PLACEHOLDER] </inputs> <task> Assess whether the model's stated performance differs meaningfully across the groups mentioned and recommend next steps. </task> <constraints> - Only assess groups explicitly mentioned in the input. - Do not claim a bias finding without a stated metric gap to point to. - If no group-level metrics were provided, say so and recommend collecting them rather than guessing. </constraints> <format> A report with sections Groups Assessed, Findings, Risk Level, Recommended Next Steps. </format>
Pro tip: If you don't have group-level metrics yet, say so directly. The most useful output at that stage is a plan to go get them, not a guess.
These prompts give you the what. Tutorials give you the why.
Learn when to use extended thinking, how to build Claude Projects, and workflows that compound. 300+ tutorials and growing.
SQL & Data Pipeline Drafts
5 promptsSQL Query Draft for a Specific Analysis
16/30✨ What it does
Claude drafts a commented SQL query for a specific question, using only the tables and columns you actually have. Run it against the warehouse, then tweak the joins before you trust the result.
You are a senior data scientist writing a first-draft query against a known schema. <context> A specific analytical question needs a first-draft SQL query against tables the team already has access to. </context> <inputs> - Tables and key columns available: [PLACEHOLDER] - Analytical question to answer: [PLACEHOLDER] - Database dialect (Postgres, BigQuery, Snowflake, and so on): [PLACEHOLDER] </inputs> <task> Write a SQL query answering the question, using only the tables and columns given, with comments explaining each major clause. </task> <constraints> - Use only the described schema, never invent a table or column name. - Comment the query so a teammate can follow the logic without asking. - Note any assumption made about join keys or filters. </constraints> <format> A single commented SQL query block, plus a short note on assumptions made. </format>
Pro tip: List the exact column names as they appear in the schema. Claude will use them exactly instead of guessing plausible-sounding ones.
Data Pipeline Design Document
17/30✨ What it does
Claude turns a manual recurring analysis into a documented pipeline design with a quality check before load. Hand the design to engineering, then keep your manual job running until the pipeline is live.
You are a senior data scientist designing a pipeline to replace a manual recurring analysis. <context> A recurring analysis is currently done by hand and needs to become an automated pipeline instead. </context> <inputs> - Data sources: [PLACEHOLDER] - Desired output (table, dashboard, or report): [PLACEHOLDER] - Refresh frequency: [PLACEHOLDER] - Known transformations needed: [PLACEHOLDER] </inputs> <task> Design a pipeline covering extraction, transformation steps in order, load destination, and failure handling. </task> <constraints> - List every transformation step in the order it should run. - The refresh frequency must match the stated need. - Include at least one data quality check before load. </constraints> <format> A document with sections Sources, Transformation Steps (numbered), Load Destination, Schedule, Failure Handling. </format>
Pro tip: State the required refresh frequency explicitly (hourly, daily, weekly). It changes the failure handling Claude recommends.
Data Dictionary
18/30✨ What it does
Claude documents every column, its nullability, and its caveats before a dataset gets handed to another team. Send the dictionary with the table, then refuse to answer questions your dictionary already covers.
You are a senior data scientist handing off a dataset to another team. <context> A dataset or table is being handed off to another team and needs documentation they can actually use without asking follow-up questions. </context> <inputs> - Table or dataset name: [PLACEHOLDER] - Columns with rough meaning: [PLACEHOLDER] - Primary key: [PLACEHOLDER] - Known caveats: [PLACEHOLDER] </inputs> <task> Produce a data dictionary defining every column, its type, whether it can be null, and any caveat. </task> <constraints> - Every column in the input must appear as a row. - Caveats must be stated plainly, for example "backfilled, pre-2025 values unreliable", never omitted. - The primary key must be identified explicitly. </constraints> <format> A table with columns Column, Type, Nullable, Description, Caveat. </format>
Pro tip: Don't leave out the caveats you know about, even embarrassing ones. A data dictionary that hides known issues just moves the debugging downstream.
Cohort Analysis Query and Writeup
19/30✨ What it does
Claude builds a cohort behavior query plus an illustrative sample writeup you can swap real numbers into. Run the query, then replace the sample rows with your actual results.
You are a senior data scientist building a cohort analysis for leadership. <context> Leadership wants to see how a user cohort's behavior changes over time, starting from a query against the real schema. </context> <inputs> - Cohort definition (for example signup month): [PLACEHOLDER] - Behavior or metric to track over time: [PLACEHOLDER] - Available tables and columns: [PLACEHOLDER] - Database dialect: [PLACEHOLDER] </inputs> <task> Write a SQL query to build the cohort retention or behavior table, plus a short writeup interpreting a plausible pattern the analysis would reveal. </task> <constraints> - The query must use only the described tables and columns. - The writeup must clearly state it is illustrative pending real results, since no actual output was provided. - The cohort definition in the query must match the input exactly. </constraints> <format> A commented SQL query block followed by a short interpretive writeup with a sample results table using realistic seeded numbers marked as illustrative. </format>
Pro tip: Be exact about the cohort definition (signup month vs signup week matters). Claude carries that exact grain through the query and the sample table.
Anomaly Detection Query and Alert Logic
20/30✨ What it does
Claude writes an anomaly-flagging query plus the alert logic for who gets notified and when. Deploy the query, then test the alert with a known spike before you trust it.
You are a senior data scientist setting up automated monitoring for a key metric. <context> A metric needs automated monitoring for unusual spikes or drops before anyone notices manually. </context> <inputs> - Metric being monitored: [PLACEHOLDER] - Table or column it comes from: [PLACEHOLDER] - Normal range or historical pattern: [PLACEHOLDER] - How sensitive the alert should be: [PLACEHOLDER] </inputs> <task> Write a query that flags anomalous values against the historical pattern, and define the alert logic: threshold, comparison window, and who gets notified. </task> <constraints> - The query must use only the described schema. - The threshold logic must be tied to the stated normal range, or a clearly stated statistical rule such as more than 2 standard deviations from the mean. - Mark the alert recipient [PLACEHOLDER] if not given. </constraints> <format> A commented SQL query block followed by an Alert Logic section: Threshold, Comparison Window, Notify. </format>
Pro tip: State how sensitive the alert should be (catch small dips vs only major spikes). It directly sets the standard-deviation or percentage threshold Claude picks.
Stakeholder Communication & Reporting
5 promptsExecutive Summary of Analysis Findings
21/30✨ What it does
Claude translates a full analysis into a jargon-free executive summary with one clear recommendation. Send the summary first, then attach the full report only if someone on your side asks.
You are a senior data scientist writing for executives who won't read the full report. <context> A completed analysis needs a short summary for executives, translated out of statistical language. </context> <inputs> - Analysis topic: [PLACEHOLDER] - 3 to 5 key findings: [PLACEHOLDER] - Business implication of each: [PLACEHOLDER] - Recommended action: [PLACEHOLDER] </inputs> <task> Write an executive summary with a headline takeaway, key findings in plain language, and a clear recommendation. </task> <constraints> - No statistical jargon without a plain-language translation right next to it. - The headline must state the main implication, not just the topic. - The recommendation must be a specific next action. </constraints> <format> A summary with Headline, Key Findings (bullets), Recommendation. </format>
Pro tip: Write the business implication of each finding yourself first. Claude writes a much sharper headline when it knows why each finding actually matters.
Analytics Project Charter
22/30✨ What it does
Claude writes an analytics project charter that aligns stakeholders on scope and success criteria before work starts. Get sign-off on the charter, then refuse scope that is not on your list.
You are a senior data scientist aligning stakeholders before a new analysis begins. <context> A new analysis project is starting and needs a charter to align stakeholders before any work begins. </context> <inputs> - Business question driving the analysis: [PLACEHOLDER] - Stakeholders and their role: [PLACEHOLDER] - Data sources expected to be used: [PLACEHOLDER] - Timeline: [PLACEHOLDER] </inputs> <task> Produce a charter stating the question, scope, success criteria, data sources, timeline, and stakeholders. </task> <constraints> - Success criteria must be specific enough that everyone can agree when the analysis is done. - Scope must state what's explicitly out of scope. - Stakeholder roles must be named specifically, not generic titles like "leadership". </constraints> <format> A charter document with sections Business Question, Scope, Success Criteria, Data Sources, Timeline, Stakeholders. </format>
Pro tip: Write success criteria as a concrete decision the analysis will inform, not just "understand X better". It keeps the charter from becoming open-ended.
Insights Deck Outline
23/30✨ What it does
Claude outlines a one-idea-per-slide insights deck that ends with a specific ask, not just a summary. Build the slides from the outline, then close the meeting on that ask you wrote.
You are a senior data scientist turning findings into a deck stakeholders will actually sit through. <context> Findings from an analysis need to become a slide deck for a stakeholder audience, not a wall of statistics. </context> <inputs> - Analysis topic: [PLACEHOLDER] - Audience: [PLACEHOLDER] - 3 to 5 core findings: [PLACEHOLDER] - Recommendation: [PLACEHOLDER] - Numbers or charts already available: [PLACEHOLDER] </inputs> <task> Outline a slide-by-slide deck: a title slide, a context slide, one slide per core finding, a recommendation slide, and an appendix note. </task> <constraints> - Each finding slide gets exactly one headline claim plus supporting detail. - Never put more than one core idea on a single slide. - The recommendation slide must state a specific ask of the audience. </constraints> <format> A numbered slide outline (Slide 1: Title, Slide 2: Context, and so on) with headline and bullet content per slide. </format>
Pro tip: List your findings in the order of importance, not discovery order. Claude keeps that order in the slide sequence.
Stakeholder FAQ for an Analysis
24/30✨ What it does
Claude drafts an honest FAQ that gets ahead of the questions stakeholders will actually ask, limitations included. Share it with the readout, then use the limitation answers when they push back on you.
You are a senior data scientist anticipating stakeholder pushback before it happens. <context> Stakeholders will have predictable questions about a new analysis or model, and it's better to answer them proactively than to get caught off guard. </context> <inputs> - Analysis or model topic: [PLACEHOLDER] - Key findings or how the model works: [PLACEHOLDER] - Known limitations: [PLACEHOLDER] - Likely audience concerns: [PLACEHOLDER] </inputs> <task> Draft an FAQ anticipating the 6 to 8 most likely stakeholder questions with clear, honest answers. </task> <constraints> - At least one question must address a limitation or caveat directly. - Answers must be understandable without a statistics background. - Do not answer a question with unsupported certainty if the input notes a limitation there. </constraints> <format> A numbered Q&A list. </format>
Pro tip: List the concerns you're already bracing for. Claude will make sure at least one question addresses each one directly, instead of dodging it.
Analysis Methodology Writeup
25/30✨ What it does
Claude writes a reviewer-ready methodology section that names the real method and states every assumption. Paste it into the report, then let the reviewer challenge the assumptions you listed.
You are a senior data scientist documenting how an analysis was done for a technical reviewer. <context> A report or deck needs a methodology section explaining exactly how the analysis was done, written for a technical or semi-technical audience who will evaluate it. </context> <inputs> - Data sources used: [PLACEHOLDER] - Analysis method(s) applied: [PLACEHOLDER] - Sample size or time period: [PLACEHOLDER] - Key assumptions made: [PLACEHOLDER] </inputs> <task> Write a methodology section describing the data sources, method, and assumptions in a way a technical reviewer could actually evaluate. </task> <constraints> - Name the specific method used, never just "we analyzed the data". - State every assumption explicitly. - Note any limitation of the method given the described data. </constraints> <format> A methodology writeup with subsections Data, Method, Assumptions, Limitations. </format>
Pro tip: Name your method precisely (linear regression, propensity score matching, a t-test) rather than describing it loosely. Precision here is what makes the writeup reviewable.
Most people use 10% of Claude. Tutorials unlock the rest.
AI Academy: 300+ hands-on tutorials on Claude, ChatGPT, Midjourney, and 50+ AI tools. New tutorials added every week.
Dashboards & Metrics
5 promptsKPI Dashboard Specification
26/30✨ What it does
Claude specifies every metric's formula and source before a dashboard gets built, with no ambiguity left for the engineer. Hand the spec over, then accept only charts that match the formulas you specified.
You are a senior data scientist writing the spec an analytics engineer will build a dashboard from. <context> Analytics engineering needs a written spec before building a data science team's dashboard, not just a verbal request. </context> <inputs> - Business area: [PLACEHOLDER] - Audience: [PLACEHOLDER] - 3 to 6 metrics wanted: [PLACEHOLDER] - Data sources or tables available: [PLACEHOLDER] </inputs> <task> Specify each metric (definition, formula, source, refresh frequency) and recommend a dashboard layout grouping. </task> <constraints> - Every metric needs an explicit formula. - Flag any metric whose data source is unclear from the input. - Group metrics logically, with a stated reason for the grouping. </constraints> <format> A table (Metric, Definition, Formula, Source, Frequency) plus a layout recommendation. </format>
Pro tip: List the tables you actually have, not the ideal source. Claude will flag any metric that needs a source you don't have yet.
North Star Metric and Guardrails Definition
27/30✨ What it does
Claude picks a single main number you care about and names guardrails that would catch it being gamed. Publish both, then watch the guardrails whenever that main number looks too good to you.
You are a senior data scientist defining what success actually means for a product area. <context> The team needs a single north star metric plus guardrails, so optimizing the main number doesn't quietly cause harm elsewhere. </context> <inputs> - Product or business area: [PLACEHOLDER] - Business goal: [PLACEHOLDER] - Candidate metrics being considered: [PLACEHOLDER] - Known risks of over-optimizing: [PLACEHOLDER] </inputs> <task> Recommend a north star metric with justification, plus 2 to 4 guardrail metrics that would catch it being gamed or causing a harmful side effect. </task> <constraints> - The north star must be a single specific metric, not a bundle of several. - Each guardrail must state exactly what specific harm it would catch. - The justification must tie back to the stated business goal. </constraints> <format> A document with sections North Star Metric (with justification), Guardrail Metrics (each with what it catches). </format>
Pro tip: Name the ways you've already seen a similar metric get gamed elsewhere, even informally. Claude will turn those directly into guardrails.
Weekly Analytics Report With Sample Data
28/30✨ What it does
Claude fills a weekly report template with realistic sample numbers so the format is agreed before real data lands. Show the sample to stakeholders, then swap in live numbers once they like your layout.
You are a senior data scientist producing a recurring weekly analytics report. <context> The team needs a recurring weekly analytics report template, populated with a first realistic sample so stakeholders can see the format before real numbers arrive. </context> <inputs> - Metrics tracked weekly: [PLACEHOLDER] - Last known values or rough baseline: [PLACEHOLDER] - Notable events this week, if any: [PLACEHOLDER] </inputs> <task> Fill in a weekly report template with realistic seeded sample numbers consistent with the given baseline, week-over-week change, and a short narrative on what moved. </task> <constraints> - Seeded numbers must stay consistent with any baseline given. - Mark the numbers clearly as illustrative sample data. - The narrative must reference the notable events if any were given. </constraints> <format> A table (Metric, This Week, Last Week, % Change) followed by a short narrative paragraph. </format>
Pro tip: Give a real recent baseline value even if approximate. It keeps the seeded sample numbers believable instead of round and generic.
Forecast Report With Sample Forecast Table
29/30✨ What it does
Claude names a specific forecasting method and produces an illustrative forecast table with the risks called out. Replace the sample with live history, then present the range, not a single point you invented.
You are a senior data scientist producing a forward-looking forecast for leadership. <context> Leadership wants a forward-looking forecast for a metric based on its recent trend, with the method made explicit. </context> <inputs> - Metric being forecast: [PLACEHOLDER] - Recent historical values or trend description: [PLACEHOLDER] - Forecast horizon: [PLACEHOLDER] - Known upcoming factors that could shift the trend: [PLACEHOLDER] </inputs> <task> Describe a reasonable forecasting approach given the trend described, then produce a sample forecast table with realistic seeded numbers for the requested horizon. </task> <constraints> - Forecast numbers must be clearly labeled as illustrative, based on the described trend. - The method used must be named explicitly, for example a linear trend extrapolation or moving average. - Call out the known upcoming factors as a risk to the forecast's accuracy. </constraints> <format> A short methodology note, then a table (Period, Forecasted Value, Note) for the requested horizon. </format>
Pro tip: Mention any known upcoming factor (a launch, a seasonal dip, a pricing change) even briefly. Claude will flag it as a risk to the forecast instead of ignoring it.
Retention Cohort Dashboard Spec
30/30✨ What it does
Claude specifies a retention dashboard's cohort definition and calculation method, with a sample table to sanity-check the format. Confirm the cohort rule, then give the spec to whoever builds your board.
You are a senior data scientist specifying a retention dashboard before it gets built. <context> Product wants a retention dashboard, and the spec needs to be written before any building starts. </context> <inputs> - Product or feature area: [PLACEHOLDER] - Cohort definition (for example signup week): [PLACEHOLDER] - Retention windows to show (for example week 1, 4, 12): [PLACEHOLDER] - Audience for the dashboard: [PLACEHOLDER] </inputs> <task> Specify the retention cohort dashboard: cohort definition, retention windows, how retention is calculated, and a sample cohort table with realistic seeded numbers. </task> <constraints> - The retention calculation must be stated explicitly, for example percent of the cohort active in that window. - Sample numbers must be clearly labeled illustrative. - The windows shown must match what was requested. </constraints> <format> A spec section (Cohort Definition, Calculation Method) followed by a sample cohort retention table with seeded numbers. </format>
Pro tip: State the exact retention windows you want (week 1/4/12 versus day 1/7/30). It's the detail most likely to get rebuilt if left vague.
Free tool
Prompt Optimizer
Turn a rough idea into a structured, professional AI prompt.
Frequently Asked Questions
Prompts are the starting line. Tutorials are the finish.
A growing library of 300+ hands-on tutorials on ChatGPT, Claude, Midjourney, and 50+ AI tools. New tutorials added every week.
7-day free trial. Cancel anytime.