Prompt Design for Data Tasks AI Prompts

Design a prompt that takes a detected data anomaly and produces a clear, business-friendly explanation with hypotheses. Context: anomaly detection systems generate alerts, but data teams spend significant time translating statistical findings into actionable business language. This prompt automates that translation. 1. Anomaly context input structure: Define the inputs the prompt receives: - metric_name: the metric that anomalized - current_value: the observed value - expected_value: the baseline or predicted value - deviation_pct: percentage deviation from expected - time_period: when the anomaly occurred - segment_breakdown: how the anomaly distributes across dimensions (region, product, channel) - related_metrics: other metrics that moved at the same time - recent_events: known business events in the same time window (promotions, deployments, holidays) 2. Prompt instructions: - 'You are a senior data analyst. Explain this data anomaly to a business audience.' - 'Do not use statistical terminology. Replace with plain business language.' - 'Do not speculate beyond what the data supports. Distinguish between confirmed facts and hypotheses.' 3. Output structure (enforce with the prompt): - What happened: 1–2 sentences describing the anomaly in plain English - Where it is concentrated: which segments, regions, or dimensions account for most of the deviation - Likely causes: 2–3 hypotheses ranked by likelihood, each with supporting evidence from the data - What is needed to confirm: what additional data or investigation would confirm the top hypothesis - Recommended action: a specific next step for the business team 4. Tone calibration: - For a 5% deviation: 'A moderate shift worth monitoring' - For a 20% deviation: 'A significant change that warrants investigation' - For a 50%+ deviation: 'An extreme anomaly requiring immediate attention' - Instruct the model to match tone to deviation magnitude 5. Few-shot examples: - Provide 2 example anomalies with full context and the ideal explanation output - Include one where the cause is known (holiday effect) and one where it is unknown Return: the complete anomaly explanation prompt, 2 few-shot examples, and a rubric for evaluating explanation quality (accuracy, clarity, actionability).

Design a prompt that instructs an LLM to clean and standardize a specific type of messy data field. Field type: {{field_type}} (e.g. company names, phone numbers, addresses, product descriptions, job titles) Source data sample: {{data_sample}} 1. The challenge with LLM data cleaning: - LLMs are inconsistent without explicit rules — the same model may normalize 'IBM Corp.' differently on two calls - The prompt must eliminate ambiguity by providing exhaustive rules and examples 2. Prompt structure for data cleaning: a. Task definition (1 sentence): 'Normalize the following {{field_type}} to a standard format.' b. Normalization rules (numbered list, in order of priority): - Rule 1: [most important normalization, e.g. 'Convert to Title Case'] - Rule 2: [second rule, e.g. 'Remove legal suffixes: LLC, Inc., Corp., Ltd.'] - Rule 3: [third rule, e.g. 'Expand common abbreviations: St. → Street, Ave. → Avenue'] - Continue until all cases are covered c. Conflict resolution: 'If two rules conflict, apply the earlier rule.' d. Uncertainty handling: 'If you are not confident in the correct normalization, return the input unchanged and append a [?] flag.' e. Output format: 'Return ONLY the normalized value. No explanation.' 3. Few-shot examples (critical for consistency): - Include 6–10 input → output pairs covering the most common messy patterns - Include at least 2 edge cases (very short, very long, non-standard characters) - Include 1 example where the model should return the value unchanged with [?] 4. Batch processing version: - Extend the prompt to clean a list of 20 values in one call - Output as a JSON array preserving input order - Include an index field so outputs can be joined back to inputs Return: single-record cleaning prompt, batch cleaning prompt, test set of 20 messy values, and expected normalized outputs.

Design a prompt chain that guides an LLM through a multi-step data transformation task — equivalent to a mini ETL pipeline. Transformation task: {{transformation_task}} (e.g. 'normalize and deduplicate a customer list from 3 different source formats') 1. Why a single prompt fails for complex transformations: - Complex transformations require multiple dependent reasoning steps - A single prompt producing the final result skips intermediate validation steps - Errors in early steps propagate invisibly to the output - A prompt chain surfaces intermediate results for inspection and debugging 2. Pipeline prompt design pattern: Step 1 prompt — Schema analysis: - Input: raw data - Task: 'Analyze the structure of this data. For each column, identify: name, inferred type, example values, and potential quality issues.' - Output: structured schema analysis (JSON) Step 2 prompt — Transformation plan: - Input: schema analysis from Step 1 + transformation goal - Task: 'Based on this schema analysis, write a step-by-step transformation plan. Each step should specify: what to transform, how, and why.' - Output: numbered transformation plan Step 3 prompt — Transformation execution: - Input: raw data + transformation plan from Step 2 - Task: 'Execute the transformation plan exactly as specified. Apply each step in order. For each step, show the result.' - Output: transformed data Step 4 prompt — Quality validation: - Input: original data + transformed data - Task: 'Compare the original and transformed data. Check: (1) row count preserved or changes explained, (2) no data was lost unintentionally, (3) transformations were applied correctly. Flag any issues.' - Output: validation report 3. Error recovery design: - Each step prompt should include: 'If you encounter an error or ambiguity, stop and output: ERROR: [description] rather than proceeding with an assumption.' - This surfaces problems early rather than propagating bad data through the chain 4. Prompt chain orchestration: - Show how to chain these prompts programmatically: feed output of step N as input to step N+1 - Include JSON schema validation between steps to catch format errors before they propagate Return: all 4 step prompts, a Python orchestration script, and a test case with expected intermediate outputs.

Design a prompt that reliably generates correct SQL from natural language questions about a specific database schema. Database schema: {{schema_definition}} SQL dialect: {{dialect}} (PostgreSQL / BigQuery / Snowflake / DuckDB) Target user: {{user_type}} (data analyst / business user / developer) 1. Schema context injection: - Include the full DDL for all relevant tables in the prompt - Add a brief description above each table: what it represents and its grain - Add a brief description of each column that is not self-explanatory - Include sample data (3 rows per table) to help the model understand value formats - Specify relationships: 'orders.customer_id is a foreign key to customers.id' 2. Dialect-specific instructions: - List the dialect-specific functions to use: 'Use DATE_TRUNC for date truncation, not TRUNC' - Specify quoting conventions: 'Quote identifiers with double quotes' - Specify NULL handling conventions relevant to this dialect 3. SQL style guidelines (for readable, consistent output): - SELECT clause: one column per line, aligned - Use CTEs (WITH clauses) for multi-step logic, not nested subqueries - Always use explicit JOIN syntax, never implicit comma joins - Always qualify column names with table aliases when joining multiple tables - Add a comment above each CTE explaining what it computes 4. Ambiguity resolution rules: - 'When the question is ambiguous about date range, default to the last 30 days' - 'When the question asks for top N without specifying N, use 10' - 'When a metric could be calculated multiple ways, choose the simplest correct interpretation and add a SQL comment noting the assumption' 5. Error prevention instructions: - 'Never use SELECT * in the final output' - 'Always add a LIMIT clause when the question does not specify a row count' - 'For aggregations, always include GROUP BY for all non-aggregated columns' 6. Output format: - Return only the SQL query - No explanation unless explicitly asked - Add inline SQL comments for any non-obvious logic Return: the complete SQL generation prompt, 5 test questions ranging from simple to complex, the correct SQL for each, and a rubric for evaluating SQL correctness.

Write a prompt that reliably extracts structured data from unstructured text. Source text type: {{text_type}} (e.g. customer support tickets, invoice PDFs, clinical notes, news articles) Target schema: {{target_schema}} (the fields you want to extract) Apply these prompt engineering principles for data extraction: 1. Schema-first instruction: - Define the output schema explicitly before showing any examples - Name every field, its type, and what to do when it is missing (null vs omit vs default value) - Example: 'Extract the following fields. If a field is not present in the text, return null for that field.' 2. Constraint specification: - State the output format unambiguously: 'Return ONLY a JSON object. No explanation, no markdown, no preamble.' - Specify value formats: 'Dates must be in ISO 8601 format (YYYY-MM-DD)', 'Monetary values as numbers without currency symbols' - Specify enumeration constraints: 'status must be one of: [open, closed, pending]' 3. Ambiguity resolution rules: - What should the model do when a field is ambiguous? Provide explicit tie-breaking rules. - Example: 'If multiple dates appear, extract the most recent one as order_date' - Example: 'If the customer name appears in multiple formats, use the version that includes both first and last name' 4. Negative examples: - Show what NOT to include: 'Do not extract dates from headers or footers' - Show what NOT to infer: 'Do not infer fields that are not explicitly stated in the text' 5. Robustness to messy input: - Instruct the model to handle OCR errors, typos, and inconsistent formatting gracefully - 'If a field contains obvious OCR artifacts (e.g. 0 vs O), normalize to the most likely intended value' Return: the complete extraction prompt, a test with 3 sample inputs (clean, messy, and edge case), and expected outputs for each.