AI Prompts for Data Professionals

Write an A/B test design brief for the following proposed change: {{change_description}} The brief must include: 1. Hypothesis - We believe that [change] will cause [outcome] because [rationale] - Null hypothesis: the change has no effect on the primary metric 2. Primary metric: the single metric this test will be judged on 3. Secondary metrics: 2–3 supporting metrics to monitor 4. Guardrail metrics: 2–3 metrics that must not significantly degrade 5. Test setup - Unit of randomization: user / session / account / device - Traffic split: 50/50 or other (justify any deviation) - Targeting: all users, or a specific segment? Why? 6. Statistical parameters - Significance level α = 0.05 (two-tailed) - Minimum detectable effect (MDE): the smallest change worth detecting - Required statistical power: 80% - Required sample size per variant (calculate) - Required experiment duration given current daily traffic of {{daily_traffic}} 7. Risks: what could go wrong? How will you detect it? 8. Decision criteria: exactly when will you ship, iterate, or kill? Return: the complete test brief as a shareable document.

Scan all business metrics in this dataset for unusual spikes or drops: 1. For each metric, compute the week-over-week and month-over-month percentage change 2. Flag any change greater than 2 standard deviations from the historical average change rate 3. For flagged metrics, check whether the spike is isolated to one dimension (e.g. one region, one product) or affects the whole metric 4. Determine whether the spike is a one-off event or the start of a new trend 5. Rank flagged metrics by business impact (highest volume or revenue first) Return a spike report table and a plain-English summary of the top 3 most concerning changes.

Design a safe migration process for this breaking schema change. Breaking change: {{change_description}} (e.g. renaming column customer_id to account_id, or changing the grain from order to order_line) Affected table: {{table_name}} Known consumers: {{consumer_list}} 1. Impact assessment: - Query the data lineage graph to find ALL consumers of the affected table and column - For each consumer: team, table/report name, how the breaking column is used, migration effort (Low/Medium/High) - Identify any external consumers (APIs, applications) that cannot be migrated centrally 2. Migration strategy: Expand and Contract (strangler fig pattern): Phase 1 — Expand (add, don't remove): - Add the new column/structure alongside the existing one - Populate both: old column = old value, new column = new value - Publish schema with both old and new columns - Notify all consumers: 'New column available, please migrate. Old column will be removed on {{sunset_date}}' Phase 2 — Migrate: - Support consumer teams in migrating their pipelines/reports to the new column - Track migration progress per consumer team - Provide a migration deadline: {{deadline}} Phase 3 — Contract (remove the old): - Verify all consumers have migrated (query lineage + direct confirmation) - Remove the old column - Publish final schema version 3. Rollback plan: - At each phase: what is the rollback procedure if a critical consumer cannot migrate in time? - Rollback requires reverting only Phase 1 changes — no data is lost 4. Communication plan: - Initial announcement: {{notice_period}} before Phase 1 - Weekly migration status updates to all consumers - Final warning: 1 week before Phase 3 Return: impact assessment table, phase-by-phase implementation plan, consumer communication templates, and rollback procedure.