Prompt: Build a Data Dictionary from a Schema

Turns a raw table schema into a plain-English data dictionary, one row per column, without guessing at meanings the schema doesn't confirm.

The prompt

Open in Studio

You are a data analyst who documents a schema without inventing meaning the schema doesn't actually confirm.

Objective: Build a data dictionary for the table(s) below, for {{INTENDED READER — e.g. new analysts joining the team}}.

Context: {{TABLE SCHEMAS — paste the table name, columns, types and any sample values}}. Additional notes: {{ADDITIONAL NOTES — e.g. business rules or known quirks worth flagging}}.

Constraints:
- Produce exactly one row per column supplied; do not merge two columns into one row or add a row for a column that wasn't given
- For each column, state its name, data type, a plain-English description, and whether it can be blank or null
- If a column's purpose is genuinely unclear from its name, type and any sample values, write "Purpose unclear — confirm with data owner" rather than guessing
- Do not state a column's likely source system, update frequency or ownership unless that information was given in the additional notes

Example: a column named `cust_flag` with values 0 and 1 and no further context should be marked as unclear, not guessed to mean "is a returning customer".

Output format: Return a Markdown table with columns Column, Type, Description, Nullable, one row per supplied column, in the order the columns were given.

Before finishing, check the row count matches the number of columns supplied exactly, and that no description states something the schema and notes don't actually support.

Example

Input

INTENDED READER — e.g. new analysts joining the team: new analysts joining the team
TABLE SCHEMAS — paste the table name, columns, types and any sample values: table `orders`: id (int, e.g. 10042), order_date (date, e.g. 2026-03-14), status (text, sample values: "pending", "shipped", "cancelled"), cust_flag (int, sample values: 0, 1)
ADDITIONAL NOTES — e.g. business rules or known quirks worth flagging: status is set by the fulfilment system, not manually edited

Output

| Column | Type | Description | Nullable |
|---|---|---|---|
| id | int | Identifier for each order, e.g. 10042; the schema doesn't confirm whether values are unique. | Not stated in the supplied schema |
| order_date | date | The date associated with the order, most likely when it was placed (e.g. 2026-03-14) — confirm with data owner if the distinction matters. | Not stated in the supplied schema |
| status | text | The order's current fulfilment status, set automatically by the fulfilment system rather than edited manually; sample values seen are "pending", "shipped" and "cancelled". | Not stated in the supplied schema |
| cust_flag | int | Purpose unclear — confirm with data owner. Sample values are 0 and 1, but no naming convention or note confirms what this flag distinguishes. | Not stated in the supplied schema |

Why it works

Requiring exactly one row per supplied column keeps the dictionary a direct, checkable mirror of the real schema rather than a reorganised summary.
Explicitly allowing 'purpose unclear' instead of a guess stops a plausible-sounding but wrong description entering permanent documentation.
The pre-finish row-count check catches a merged or dropped column before the dictionary is published for the team to rely on.

Why the basic version fails

“Document this schema for me” often produces confident-sounding descriptions for every column, including ones the model has no real basis for — a column named cust_flag gets assigned a specific meaning that’s really just a guess, and that guess quietly becomes the team’s documented reference.

What this prompt fixes

Requiring exactly one row per supplied column keeps the dictionary tightly matched to the real schema, so nothing is silently merged or skipped. Explicitly allowing “purpose unclear” as a valid answer is what stops the model inventing a plausible but ungrounded meaning for an ambiguous column — which matters because a wrong guess in a data dictionary tends to get trusted and repeated by everyone who reads it afterwards.

Tips per model

ChatGPT is good at writing clear plain-English descriptions once given real column names and sample values; without samples, more columns will come back as “unclear”.
Claude tends to be more conservative about guessing a column’s meaning from its name alone, which is useful for exactly this kind of documentation task.
Include a few real sample values for each column where you can — they often resolve an otherwise-ambiguous column name without needing to ask the data owner at all.