30 Claude Prompts for ML Engineers

You are a machine learning engineer writing model documentation for internal and external review. <context> I trained a model and have rough notes, and I need a proper model card before this goes to a stakeholder or a public repository. </context> <inputs> - Model name and version: [NAME AND VERSION] - Intended use: [WHAT THE MODEL IS FOR] - Training data summary: [SOURCE, SIZE, TIME RANGE] - Evaluation results: [KEY METRICS AND VALUES] - Known limitations: [LIST IF ANY, OR SAY NONE IDENTIFIED YET] </inputs> <task> Write a model card covering intended use, out of scope uses, training data, evaluation results, limitations, and ethical considerations. </task> <constraints> Follow the structure used by common model card frameworks such as Google's or Hugging Face's. Do not overstate performance, state metrics exactly as given. If limitations were not provided, prompt me with likely candidates to consider rather than inventing final claims. </constraints> <format> Return as markdown with headers matching a standard model card: Overview, Intended Use, Training Data, Evaluation, Limitations, Ethical Considerations. </format>

You are a machine learning engineer documenting data lineage for compliance and reproducibility. <context> I need to document where the data for a training run came from before an audit or a handoff to another team. </context> <inputs> - Dataset name: [DATASET NAME] - Source systems: [LIST OF SOURCE SYSTEMS OR TABLES] - Transformations applied: [LIST OF CLEANING OR JOIN STEPS] - Time range covered: [START AND END DATE] - Known data quality issues: [LIST OR SAY NONE KNOWN] </inputs> <task> Write a data lineage summary that traces the dataset from raw source to final training format, listing every transformation step in order. </task> <constraints> Be precise about order of operations, a wrong order in a lineage doc is worse than a missing detail. Flag any step where you had to guess at intent and mark it for me to confirm. Avoid restating the same transformation twice under different names. </constraints> <format> Return as a numbered pipeline from Source to Final Dataset, then a short section titled Open Questions for anything you flagged. </format>

You are a machine learning engineer focused on responsible deployment documentation. <context> I have a working model and need to clearly state what it should and should not be used for before other teams start integrating it. </context> <inputs> - Model purpose: [WHAT THE MODEL WAS BUILT TO DO] - Target users: [WHO WILL CALL THIS MODEL] - Data it was trained on: [BRIEF DESCRIPTION] - Contexts it was NOT tested in: [LIST IF KNOWN] - Regulatory context if any: [E.G. GDPR, HEALTHCARE, FINANCE, OR NONE] </inputs> <task> Write the Intended Use and Out of Scope Use sections of a model card, listing specific scenarios where the model should not be applied. </task> <constraints> Be concrete, for example name specific user populations or decision types that were not represented in training rather than saying use with caution. If regulatory context applies, note the relevant consideration without giving legal advice. </constraints> <format> Return two sections: Intended Use as a short paragraph, then Out of Scope Use as a bulleted list. </format>

You are a machine learning engineer who writes the model selection section of internal design docs. <context> I evaluated several candidate models and need to summarize the comparison for a design doc that non ML reviewers will also read. </context> <inputs> - Candidate models: [LIST OF MODEL NAMES] - Metrics compared: [LIST OF METRICS] - Results table: [PASTE RAW NUMBERS OR DESCRIBE] - Constraints that mattered: [E.G. LATENCY, COST, INTERPRETABILITY] - Final recommendation: [WHICH MODEL YOU ARE LEANING TOWARD, OR SAY UNDECIDED] </inputs> <task> Write a model comparison summary that explains the tradeoffs between candidates in plain language and states a recommendation with reasoning. </task> <constraints> Explain metrics in terms a non specialist reviewer can follow, not just numbers in a table. If I said undecided, present the tradeoffs neutrally instead of forcing a recommendation. Keep it to one page. </constraints> <format> Return a comparison table first, then a short written recommendation section. </format>

You are a machine learning engineer who maintains a changelog for a production model across versions. <context> I just shipped a new version of a model and need a changelog entry that downstream teams will actually read. </context> <inputs> - Previous version: [VERSION NUMBER] - New version: [VERSION NUMBER] - What changed: [ARCHITECTURE, DATA, OR TRAINING CHANGES] - Metric deltas: [OLD VALUE TO NEW VALUE FOR KEY METRICS] - Breaking changes for downstream consumers: [LIST OR SAY NONE] </inputs> <task> Write a changelog entry describing what changed, why, and the measured impact, including any action downstream teams need to take. </task> <constraints> Lead with the breaking changes if there are any, do not bury them at the bottom. State metric deltas as before and after values, not just percent change, so the reader has context. </constraints> <format> Return as a dated changelog entry with sections Summary, Metric Changes, Breaking Changes, Action Required. </format>

You are a machine learning engineer building evaluation harnesses for LLM powered features. <context> I am shipping a feature backed by an LLM and need a rubric to score outputs before I trust automated grading. </context> <inputs> - Feature description: [WHAT THE FEATURE DOES] - Example good output: [PASTE ONE] - Example bad output: [PASTE ONE] - Dimensions that matter: [E.G. ACCURACY, TONE, FORMAT, SAFETY] - Scale preferred: [E.G. 1 TO 5, PASS OR FAIL] </inputs> <task> Write an evaluation rubric with clear criteria for each dimension and score level, anchored by the example outputs given. </task> <constraints> Make each score level distinguishable, avoid rubrics where a 3 and a 4 are hard to tell apart. Reference the actual examples I gave rather than generic descriptions. Keep the rubric usable by a human grader in under two minutes per item. </constraints> <format> Return a table with rows for each dimension and columns for each score level, followed by one sentence per cell describing what qualifies. </format>

You are a machine learning engineer who builds regression test suites for model behavior. <context> I need a set of test cases for my eval harness that specifically target edge cases, not just typical inputs. </context> <inputs> - Model or feature under test: [DESCRIPTION] - Typical input example: [PASTE ONE] - Known failure categories: [LIST, E.G. LONG INPUTS, AMBIGUOUS PHRASING, RARE ENTITIES] - Number of test cases needed: [NUMBER] - Expected output format: [DESCRIBE] </inputs> <task> Generate test cases that stress the known failure categories, each with an input and the expected behavior or output. </task> <constraints> Do not generate near duplicate test cases, each one should target a distinct edge condition. Where the correct expected output is genuinely ambiguous, say so instead of guessing. </constraints> <format> Return as a numbered list, each item with Input, Failure Category Targeted, and Expected Behavior. </format>

You are a machine learning engineer setting up continuous evaluation for a production model pipeline. <context> I want a regression suite that runs automatically before any model deploy so we catch quality drops before users do. </context> <inputs> - Model type: [MODEL TYPE] - Current manual QA process: [DESCRIBE BRIEFLY] - Past incidents caused by regressions: [LIST IF ANY] - Deploy frequency: [E.G. DAILY, WEEKLY] - CI or pipeline tool in use: [TOOL NAME] </inputs> <task> Design a regression suite structure that covers the failure modes from past incidents, specify what should block a deploy versus just warn, and outline how it plugs into the existing pipeline tool. </task> <constraints> Be realistic about what can run within a deploy frequency of the one stated, do not propose a suite that takes longer to run than the time between deploys. Separate hard blockers from soft warnings explicitly. </constraints> <format> Return sections titled Test Categories, Blocking Criteria, Warning Criteria, and Pipeline Integration Notes. </format>

You are a machine learning engineer setting up an LLM as judge evaluation pipeline. <context> I want to use an LLM to automatically grade outputs from another model at scale, and need a grading prompt that produces consistent scores. </context> <inputs> - Task being graded: [DESCRIBE THE TASK, E.G. SUMMARIZATION, CLASSIFICATION EXPLANATION] - Grading criteria: [LIST, E.G. FACTUAL ACCURACY, CONCISENESS] - Score scale: [E.G. 1 TO 10, BINARY] - Reference answer available: [YES OR NO] - Example output to calibrate on: [PASTE ONE] </inputs> <task> Write a grading prompt for the judge model that states the criteria, the scale, and how to handle the reference answer if one exists, calibrated against the example given. </task> <constraints> Instruct the judge to give a short justification alongside every score, not just a number, so scores can be audited later. Warn against the judge favoring longer outputs by default, a known bias in LLM grading. </constraints> <format> Return the grading prompt as ready to paste text, followed by a two sentence note on how to spot check the judge's consistency. </format>

You are a machine learning engineer who reports model performance broken down by data slice, not just overall averages. <context> I have overall evaluation numbers but suspect the model performs unevenly across subgroups, and I need a slice based report to check. </context> <inputs> - Overall metric and value: [METRIC NAME AND VALUE] - Candidate slices to check: [E.G. REGION, DEVICE TYPE, USER TENURE, LANGUAGE] - Sample sizes per slice if known: [LIST OR SAY UNKNOWN] - Business risk if a slice underperforms: [DESCRIBE BRIEFLY] </inputs> <task> Design a slice based evaluation report structure that computes the metric per slice, flags slices below a reasonable threshold, and notes where sample size is too small to trust the result. </task> <constraints> Do not treat a slice with very few examples the same as a well sampled one, call out low confidence results explicitly. Tie the threshold for flagging back to the business risk described. </constraints> <format> Return a table template with columns Slice, Sample Size, Metric Value, Confidence, Flag, followed by one paragraph on how to prioritize flagged slices. </format>

You are a machine learning engineer who maintains feature documentation in a shared feature store. <context> I added a new feature to the feature store and need documentation so other teams can decide whether to use it. </context> <inputs> - Feature name: [FEATURE NAME] - Definition: [HOW IT IS COMPUTED, PLAIN LANGUAGE OR FORMULA] - Source tables: [LIST OF SOURCE TABLES] - Update frequency: [E.G. HOURLY, DAILY, REAL TIME] - Known caveats: [E.G. NULL RATE, LOOKBACK WINDOW ISSUES, OR SAY NONE KNOWN] </inputs> <task> Write feature store documentation covering definition, computation logic, source data, freshness, and caveats a consumer should know before using it in a model. </task> <constraints> State the computation logic precisely enough that someone could reimplement it. If caveats were not given, ask about common ones like leakage risk or missing value handling rather than skipping the section. </constraints> <format> Return as markdown with headers: Definition, Computation Logic, Source Data, Freshness, Caveats for Consumers. </format>

You are a machine learning engineer preparing a feature engineering section for a design review. <context> I engineered several new features for a model and need to explain the reasoning to reviewers who will question whether each one is justified. </context> <inputs> - Model this feeds into: [MODEL NAME OR PURPOSE] - New features: [LIST FEATURE NAMES WITH ONE LINE EACH ON WHAT THEY CAPTURE] - Baseline features already in use: [LIST] - Evidence for value: [E.G. CORRELATION, ABLATION RESULT, DOMAIN KNOWLEDGE] </inputs> <task> Write a rationale section explaining why each new feature was added, what signal it is expected to capture, and what evidence supports including it. </task> <constraints> Do not justify a feature with domain knowledge alone if evidence was provided, lead with the evidence. If a feature has weak evidence, say so plainly instead of overselling it, reviewers will ask anyway. </constraints> <format> Return one short paragraph per feature, each ending with an Evidence line stating strong, moderate, or weak. </format>

You are a machine learning engineer producing a data dictionary for a dataset that other engineers will reuse. <context> I have a training dataset with many columns and need a data dictionary so future users do not have to reverse engineer column meanings. </context> <inputs> - Dataset name: [DATASET NAME] - Column list with brief notes: [PASTE COLUMN NAMES AND ANY NOTES YOU HAVE] - Target column: [TARGET COLUMN NAME] - Units or encodings that need explanation: [LIST IF ANY] </inputs> <task> Produce a data dictionary listing each column with its meaning, data type, unit or encoding, and whether it is the target, a feature, or an identifier. </task> <constraints> Where my notes are incomplete for a column, mark it as needs confirmation rather than guessing a plausible sounding meaning. Keep descriptions to one line each. </constraints> <format> Return a table with columns Column Name, Type, Role, Description, Needs Confirmation. </format>

You are a machine learning engineer managing the lifecycle of features in a shared feature store. <context> I am deprecating a feature that other models depend on and need to notify consumers with a clear migration path. </context> <inputs> - Feature being deprecated: [FEATURE NAME] - Reason for deprecation: [E.G. DATA SOURCE SUNSET, REPLACED BY BETTER FEATURE, ACCURACY ISSUE] - Replacement feature if any: [FEATURE NAME OR SAY NONE] - Known consumers: [LIST MODELS OR TEAMS USING IT] - Deprecation timeline: [DATE OR NUMBER OF WEEKS] </inputs> <task> Write a deprecation notice explaining why the feature is being removed, what to migrate to, and the timeline, addressed to the known consumers. </task> <constraints> Be direct about the deadline, do not soften it with vague language like soon. If there is no replacement feature, say so plainly and suggest what consumers should do instead. </constraints> <format> Return as a short notice with sections: What Is Changing, Why, Migration Path, Deadline. </format>

You are a machine learning engineer who reviews data quality checks before a dataset is approved for training. <context> I ran data quality checks on a pipeline output and need to summarize the results for a teammate who will decide whether to approve the dataset. </context> <inputs> - Dataset name: [DATASET NAME] - Checks run: [LIST, E.G. NULL RATE, DUPLICATE RATE, SCHEMA MATCH, RANGE CHECK] - Results: [PASTE RAW RESULTS OR DESCRIBE PASS OR FAIL PER CHECK] - Any manual spot checks done: [DESCRIBE OR SAY NONE] </inputs> <task> Summarize the data quality check results into a pass or fail recommendation for each check, and an overall recommendation on whether the dataset is safe to train on. </task> <constraints> Do not average failures into an overall pass, if any check meaningfully failed the summary must say so clearly. Distinguish between checks that failed and checks that were not run. </constraints> <format> Return a table with columns Check, Result, Severity, followed by one line overall recommendation: Approve, Approve with Caveats, or Do Not Approve. </format>

You are a machine learning engineer on call for a production model incident. <context> A production model's key metric dropped and I need a structured root cause analysis before I can propose a fix. </context> <inputs> - Model affected: [MODEL NAME] - Metric that dropped: [METRIC NAME, FROM WHAT TO WHAT] - Timeline of the drop: [WHEN IT STARTED, HOW FAST] - Recent changes around that time: [DEPLOYS, DATA CHANGES, UPSTREAM CHANGES] - What you have already ruled out: [LIST OR SAY NOTHING YET] </inputs> <task> Write a root cause analysis that lists likely causes ranked by probability given the timeline and recent changes, and propose the fastest way to confirm or rule out each one. </task> <constraints> Rank causes by how well they match the timeline, not just plausibility in general. Do not repeat a cause I already said was ruled out. Keep each hypothesis to two sentences plus a confirmation step. </constraints> <format> Return a ranked list of hypotheses, each with Likely Cause, Why It Fits the Timeline, and How to Confirm. </format>

You are a machine learning engineer who defines monitoring requirements before a model goes live. <context> A new model is about to launch and I need to specify what the monitoring dashboard should track from day one. </context> <inputs> - Model purpose: [WHAT THE MODEL DOES] - Prediction volume: [REQUESTS PER DAY OR HOUR] - Metrics available in real time: [LIST] - Metrics only available with a delay: [LIST, E.G. TRUE LABELS ARRIVE LATER] - Past issues with similar models: [LIST OR SAY NONE] </inputs> <task> Specify a monitoring dashboard covering input distribution drift, prediction distribution, latency, and any delayed ground truth metrics, with alert thresholds for each. </task> <constraints> Separate what can alert in real time from what can only be checked once delayed labels arrive, do not conflate them. Base alert thresholds on the past issues mentioned where relevant. </constraints> <format> Return a table with columns Metric, Data Latency, Alert Threshold, Alert Severity. </format>

You are a machine learning engineer investigating a data drift alert on a production model. <context> A drift monitor fired on one of my model's input features and I need to figure out if it is a real problem before escalating. </context> <inputs> - Feature that drifted: [FEATURE NAME] - Drift metric and value: [E.G. PSI, KL DIVERGENCE, VALUE] - Time window compared: [E.G. LAST 7 DAYS VS PRIOR 30 DAYS] - Recent upstream changes: [LIST OR SAY NONE KNOWN] - Model's sensitivity to this feature: [HIGH, MEDIUM, LOW, OR UNKNOWN] </inputs> <task> Walk through how to investigate whether this drift is a data pipeline artifact, a genuine population shift, or noise, and recommend next steps for each possibility. </task> <constraints> Do not assume the drift is meaningful just because it triggered an alert, note that alerts can fire on noise at aggressive thresholds. Tie the urgency of your recommendation to the model's stated sensitivity to this feature. </constraints> <format> Return three short sections, one for each possibility: Pipeline Artifact, Genuine Shift, Noise, each ending with a recommended next step. </format>

You are a machine learning engineer writing a blameless postmortem after a model related production incident. <context> A model caused a production incident and it has been resolved, and I need to write the postmortem now while details are fresh. </context> <inputs> - Incident summary: [WHAT HAPPENED, ONE OR TWO SENTENCES] - Detection: [HOW IT WAS NOTICED AND WHEN] - Root cause: [CONFIRMED CAUSE] - Impact: [WHO OR WHAT WAS AFFECTED, HOW LONG] - Fix applied: [WHAT WAS DONE TO RESOLVE IT] </inputs> <task> Write a blameless postmortem with a timeline, root cause, impact, resolution, and a list of concrete follow up actions with owners left as placeholders. </task> <constraints> Keep the tone blameless, describe what happened to the system, not what a person did wrong. Make every follow up action concrete and assignable, not a vague commitment like improve monitoring. </constraints> <format> Return sections: Summary, Timeline, Root Cause, Impact, Resolution, Follow Up Actions as a checklist with an Owner column left blank. </format>

You are a machine learning engineer debugging a mismatch between offline training performance and live serving performance. <context> My model performs well in offline evaluation but worse in production, and I suspect training and serving skew. </context> <inputs> - Offline metric value: [METRIC AND VALUE] - Online metric value: [METRIC AND VALUE] - Feature computation method offline: [DESCRIBE, E.G. BATCH JOB, NOTEBOOK] - Feature computation method online: [DESCRIBE, E.G. REAL TIME SERVICE] - Anything already checked: [LIST OR SAY NOTHING YET] </inputs> <task> Walk through the most common causes of training and serving skew given the two computation methods described, and propose a specific test to check each one. </task> <constraints> Prioritize causes that specifically fit having two different computation paths, such as timing differences or default value mismatches, over generic advice. Give a concrete test for each cause, not just a description of the risk. </constraints> <format> Return a ranked list of likely causes, each with a one sentence explanation and a Test heading describing exactly how to check it. </format>

You are a machine learning engineer who regularly presents results to stakeholders without a technical background. <context> I have model results ready and need to explain them to a stakeholder who cares about business impact, not model internals. </context> <inputs> - Model results: [KEY METRICS AND VALUES] - Business metric this connects to: [E.G. REVENUE, CHURN, SUPPORT VOLUME] - Estimated business impact if known: [NUMBER OR SAY UNKNOWN] - Stakeholder's main concern: [E.G. COST, RISK, TIMELINE] - Technical caveats that matter: [LIST] </inputs> <task> Write a plain language summary connecting the model results to the business metric, addressing the stakeholder's main concern directly, and including the technical caveats in accessible terms. </task> <constraints> Do not use ML jargon like precision, recall, or overfitting without explaining it in one clause. If business impact is unknown, say so rather than fabricating a number. Keep it under 200 words. </constraints> <format> Return as a short memo with a one sentence headline, then two to three short paragraphs. </format>

You are a machine learning engineer preparing to present a model to a cross functional review board. <context> I have a model review meeting coming up with people from legal, product, and engineering, and I need talking points that anticipate their questions. </context> <inputs> - Model being reviewed: [MODEL NAME AND PURPOSE] - Key results: [METRICS] - Known risks or limitations: [LIST] - Attendees and their likely concerns: [LIST BY ROLE, E.G. LEGAL CARES ABOUT BIAS] - Decision needed from the meeting: [WHAT APPROVAL OR SIGN OFF YOU NEED] </inputs> <task> Write talking points organized by likely question from each attendee type, with a prepared answer for each, ending with a clear ask for the decision needed. </task> <constraints> Do not write generic answers, tie each answer to the specific results and limitations given. If a limitation makes a strong answer impossible, write an honest partial answer rather than a deflection. </constraints> <format> Return grouped by attendee role, each with Likely Question and Prepared Answer, ending with a one sentence Ask. </format>

You are a machine learning engineer who owes stakeholders a status update on a project that is behind schedule. <context> My modeling project is behind schedule and I need to send an honest status update without causing unnecessary alarm. </context> <inputs> - Project name: [PROJECT NAME] - Original timeline: [ORIGINAL DEADLINE] - Current status: [WHAT IS DONE, WHAT IS BLOCKED] - Reason for delay: [ROOT CAUSE OF THE DELAY] - New estimated timeline: [NEW DATE OR SAY UNCERTAIN] </inputs> <task> Write a status update email that states the delay plainly, explains the cause without excessive blame or excuse, and gives a revised timeline or an honest statement of uncertainty. </task> <constraints> Do not bury the delay in the third paragraph, state it in the first sentence. Avoid corporate hedging phrases like circling back or looping in, just say what is happening. </constraints> <format> Return as an email with a subject line, then three short paragraphs: Status, Cause, Next Steps. </format>

You are a machine learning engineer pitching a new modeling project to get resourcing approved. <context> I want to propose a new model project and need a one page document to get buy in from my manager and a product stakeholder. </context> <inputs> - Problem being solved: [DESCRIBE THE PROBLEM] - Current approach if any: [DESCRIBE OR SAY NONE EXISTS] - Proposed approach: [BRIEF DESCRIPTION OF THE MODEL OR METHOD] - Estimated effort: [TIME OR HEADCOUNT] - Expected impact: [METRIC AND ESTIMATED SIZE, OR SAY TO BE VALIDATED] </inputs> <task> Write a one page project proposal covering the problem, current gap, proposed approach, effort estimate, and expected impact with an honest confidence level on that estimate. </task> <constraints> If expected impact is unvalidated, label it clearly as an estimate rather than presenting it as a guaranteed result. Keep the whole document to one page, cut detail rather than run long. </constraints> <format> Return sections: Problem, Current Gap, Proposed Approach, Effort Estimate, Expected Impact with confidence level noted. </format>

You are a machine learning engineer who explains model behavior to support or customer facing teams. <context> Support agents keep getting asked how our model makes its decisions and I need an explainer they can actually use with customers. </context> <inputs> - Model purpose: [WHAT THE MODEL DECIDES] - Main inputs it considers: [LIST TOP FEATURES IN PLAIN TERMS] - What it does NOT consider: [LIST IF RELEVANT, E.G. FOR FAIRNESS REASONS] - Common customer question: [WHAT PEOPLE ASK] - Level of detail appropriate: [E.G. ONE PARAGRAPH FOR A SUPPORT SCRIPT] </inputs> <task> Write a plain language explanation of how the model makes its decision, answering the common customer question directly, at the level of detail specified. </task> <constraints> Do not describe internal architecture or training details, customers do not need that and it is not the question being asked. Be honest about what the model does not consider if that is relevant to trust. </constraints> <format> Return as a short script a support agent could read or paraphrase, no headers needed, just the explanation text. </format>