SQL Analysis Plan Prompt

Public field comparison

SQL Analysis Plan Prompt

SQL Analysis Plan Prompt

Plan a SQL analysis with tables, joins, metrics, filters, edge cases, and validation queries.

Design an execution-ready SQL analysis plan covering data grain, tables, joins, metrics, filters, query structure, validation queries, risks, and acceptance evidence.

—

Use this prompt to turn an analytics question and database context into a reviewable SQL design with explicit metric logic, join controls, validation queries, and safe execution guidance.

Laravel Change Review
Database Migration Planning
Zero-Downtime Deployment Review
Rollback Planning
Regression Testing
Production Readiness Checks

KPI and dashboard query planning
Multi-table join and grain review
Analytics metric definition and SQL design
Data reconciliation query planning
SQL validation and regression-check design
Read-only warehouse query readiness review

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Analysis goal or decision
SQL dialect and platform
Schema and relationships
Metric definitions and grain
Filters and reporting window
Constraints and source materials

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In Codex, replace every bracketed variable with the requested analysis context. Provide the relevant schema or DDL, data dictionary, existing SQL, metric definitions, lineage notes, sample records, query plans, row-count evidence, platform constraints, and known data-quality issues. Then run the prompt. If database or command access exists, state its scope and whether read-only execution is authorized; otherwise Codex should produce a plan and SQL drafts without claiming execution.

Use this when you need a production-ready sql result in Data Analysis, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A data team needs a monthly active-customer metric from orders, accounts, and subscription history in Snowflake. Supply the table definitions, relationship notes, metric policy, reporting timezone, existing query, and cost limits. Codex produces the grain and metric specification, join-cardinality plan, CTE blueprint, SQL skeleton, reconciliation queries, fanout checks, and a read-only execution handoff without claiming the queries were run.

Advanced

Advanced

Codex

Codex

sql

sql

codex
data-analysis
sql
analytics

codex
sql
data-analysis
query-planning
data-validation

SQL Analysis Plan Prompt | AMO.ng

SQL Analysis Plan Prompt | AMO.ng

Plan a SQL analysis with tables, joins, metrics, filters, edge cases, and validation queries.

Plan SQL analyses with explicit grain, joins, metrics, filters, query stages, validation SQL, evidence, risks, and safe execution controls.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Data Analysis specialist using Codex. Your task is: [Goal or task].
+Create an execution-ready SQL analysis plan for the following request.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Inputs
+- Analysis goal or decision: [Analysis goal or decision]
+- SQL dialect and platform: [SQL dialect and platform]
+- Schema and relationships: [Schema and relationships]
+- Metric definitions and grain: [Metric definitions and grain]
+- Filters and reporting window: [Filters and reporting window]
+- Constraints and source materials: [Constraints and source materials]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "SQL Analysis Plan Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Input requirements
+Treat the analysis goal, SQL dialect, target result grain, relevant tables or schema, metric definitions, and reporting window as minimum inputs. Table DDL, data dictionaries, existing queries, lineage notes, sample rows, query plans, row counts, and known data-quality issues are useful supporting evidence.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+If a missing detail could change the metric meaning, result grain, join cardinality, population, time boundary, or privacy treatment, ask a focused blocking question before finalizing the plan. If bounded progress is still safe, continue with alternatives and mark the affected decisions as unresolved. Do not invent tables, columns, keys, relationships, business definitions, row counts, query results, or platform capabilities.
 
−Do not give generic advice. Optimize for a production-quality sql outcome.
+Codex operating boundaries
+- Inspect only files, schemas, queries, logs, and other materials supplied in the prompt or actually available in the Codex workspace.
+- State which materials were inspected and which referenced materials were unavailable.
+- Default to planning and drafting SQL. Do not connect to a database, modify files, execute SQL, or claim query results unless that access is explicitly available and the user has authorized the action.
+- Never execute INSERT, UPDATE, DELETE, MERGE, TRUNCATE, DROP, ALTER, DDL, data exports, or production commands as part of this planning task.
+- Even when execution is authorized, use read-only, non-production access unless a human explicitly approves otherwise. Apply platform controls such as row limits, partition filters, timeouts, dry runs, or cost estimates where available. Use EXPLAIN without runtime analysis by default.
+- Stop and request human review before handling exposed credentials, unrestricted personal data, regulated data, ambiguous access rights, potentially expensive full scans, or any request that could change production data.
+
+Evidence rules
+Classify important statements as one of: supplied fact, observed in an inspected artifact, assumption, hypothesis, conflict, unknown, or execution evidence. Cite the relevant file, schema object, query, log, or user-provided definition when possible. A proposed validation query is not execution evidence. Report an actual value only when captured output is available, and keep planned, drafted, executed, passed, failed, blocked, and unverified states distinct.
+
+Planning workflow
+1. Translate the request into a measurable question. Define the output grain, population, dimensions, measures, comparison basis, reporting timezone, date boundaries, and required columns.
+2. Build a source map. For each required field, identify the candidate table and column, source grain, key, freshness expectation, nullable behavior, and evidence. Mark unsupported mappings rather than fabricating them.
+3. Resolve metric semantics. Specify numerator, denominator, inclusions, exclusions, distinctness rules, null handling, status logic, currency or unit treatment, and whether late-arriving or corrected records can restate results.
+4. Design the join graph. State the join keys, join type, expected relationship such as one-to-one or many-to-one, temporal conditions, and the intended handling of unmatched rows. Identify many-to-many paths, slowly changing dimensions, duplicate keys, bridge tables, and fanout risks.
+5. Define filtering and time logic. Separate source-reduction filters from business filters. Address inclusive versus exclusive boundaries, timezone conversion, event time versus processing time, partition pruning, snapshot dates, and parameterization. Never interpolate untrusted values directly into SQL.
+6. Design the query in stages. Provide a named CTE or subquery map showing each stage's purpose, input grain, output grain, transformations, filters, and join dependencies. Recommend pre-aggregation or deduplication where needed to preserve grain.
+7. Draft a dialect-appropriate SQL skeleton when the supplied schema is sufficient. Use only evidenced identifiers. Mark unresolved identifiers or logic in comments; if schema evidence is insufficient, provide structured pseudocode instead of pretending the SQL is runnable.
+8. Assess correctness, privacy, security, and performance risks. Consider duplicate facts, null keys, orphan records, fanout, divide-by-zero, integer division, floating-point or currency precision, inconsistent status histories, late data, skew, full scans, non-sargable predicates, sensitive columns, row-level access rules, and accidental disclosure through small groups.
+9. Create validation queries. Include checks for source and stage row counts, key uniqueness, null rates, orphan joins, pre-join and post-join cardinality, fanout ratios, duplicate result rows, reconciliation to an independent control total, filter boundaries, known examples, and expected empty or edge cases. Add dry-run, EXPLAIN, or scan-cost checks when supported by the named platform.
+10. Define acceptance and handoff. For every validation, provide the expected observation, actual observation if execution evidence exists, evidence reference, status, and action on failure. Identify decisions requiring a data owner, metric owner, privacy reviewer, database administrator, or cost approver.
+
+Required deliverable
+Return the following sections:
+
+1. Analysis specification
+- Decision or question
+- Result grain and primary key candidate
+- Population, measures, dimensions, reporting window, timezone, and output columns
+- Explicit exclusions and unresolved semantic decisions
+
+2. Evidence and assumption ledger
+A table with: ID, statement, classification, evidence reference, confidence, impact if wrong, and resolution owner.
+
+3. Source-field map
+A table with: required concept, table, column or expression, source grain, key or relationship, freshness, null behavior, sensitivity, and status.
+
+4. Join and cardinality plan
+A table with: left source, right source, join keys, join type, expected cardinality, temporal condition, unmatched-row policy, fanout control, and validation query ID.
+
+5. Metric and filter specification
+For each metric, show its formula, numerator, denominator, aggregation, distinctness, null and zero handling, units, inclusions, exclusions, and time semantics. List parameters separately from hard-coded filters.
+
+6. Query-stage blueprint
+A table with: stage name, purpose, inputs, input grain, transformation, output grain, and dependencies. Follow it with the SQL skeleton or marked pseudocode.
+
+7. Validation matrix and validation SQL
+A table with: check ID, risk tested, validation query, expected observation or threshold, actual observation, evidence, status, and failure response. Use “not executed” for actual observations when no execution occurred.
+
+8. Risk and control register
+Cover correctness, data quality, privacy, security, performance, and operational risks. For each, provide likelihood, impact, prevention, detection, stop condition, and required approver.
+
+9. Execution handoff
+List the recommended read-only execution order, required permissions, safe environment, parameters, resource controls, review owners, unresolved blockers, and rollback or recovery guidance. For this read-only analysis, recovery should focus on cancelling expensive work, removing unsafe temporary artifacts, and preserving prior published outputs until validation passes.
+
+Do not describe the analysis as tested, verified, approved, production-ready, or complete unless the corresponding action occurred and supporting evidence is present. End with the smallest safe next action and the person or role responsible for it.