Why not just let it choose the columns?

Because then the table answers the model's question rather than yours, and the columns change every time you run it. Fixing the schema is what makes the output comparable.

How do I handle a field that is sometimes two values?

Say so in the definition: “list all that apply, separated by semicolons”. Ambiguity you do not resolve in the definition gets resolved silently in the data.

Docs & research

Extract to table

Turn unstructured text — reviews, notes, job posts, a chapter — into a table with columns you defined, where missing data shows up as missing.

Use this when you need to compare many things on the same handful of attributes.

The pattern

Copy this and replace everything in [SQUARE BRACKETS] with your own specifics.

Prompt template

Extract the following fields from each item below. Output a single markdown table, one row per item, columns in exactly this order:

| [FIELD 1] | [FIELD 2] | [FIELD 3] | [FIELD 4] |

Field definitions:
- [FIELD 1]: [what counts, what does not, and the allowed values if it is a fixed set]
- [FIELD 2]: [...]

Rules:
- Write "—" for any field the item does not state. Never estimate, never infer, never leave a cell blank.
- Quote values verbatim where the field is a quote; normalise only where the field definition says to.
- Add no columns and no commentary. If an item is not an item at all, put it in a "Skipped" list underneath with a one-line reason.

Items:
[PASTE THE ITEMS, separated by a blank line.]

Why each part is there

Columns in exactly this order: You define the schema, not the model. Without a fixed schema the columns drift between batches, which makes the outputs impossible to stack.
Field definitions with allowed values: Where extraction accuracy actually comes from. “Experience level: one of entry / mid / senior; use the stated years if given” beats a column called “experience” by a wide margin.
The em-dash rule: The most important line in the prompt. Without it, an unstated field gets filled with a confident guess, and a guess in a table looks exactly like data.
The Skipped list: Gives the model somewhere to put the thing that does not fit, so it stops forcing bad rows into your table to satisfy the format.

Before and after

The lazy version

Make a table comparing these 15 job postings.

What goes wrong: You get whatever columns the model felt like, filled in wherever it could, silently guessed where it could not. The table looks complete and authoritative, and roughly a fifth of it is invention.

The pattern, filled in

Worked example

Extract the following fields from each item below. Output a single markdown table, one row per item, columns in exactly this order:

| Role | Stated salary range | Years required | Named ML skills | Remote? |

Field definitions:
- Role: the job title, verbatim.
- Stated salary range: only if a number appears; copy the currency and units as written.
- Years required: a number or a range; "—" if only vague words like "experienced" are used.
- Named ML skills: only named tools/techniques (e.g. PyTorch, XGBoost); not soft skills.
- Remote?: one of yes / no / hybrid / —.

Rules:
- Write "—" for any field the item does not state. Never estimate, never infer, never leave a cell blank.
- Quote values verbatim where the field is a quote; normalise only where the definition says to.
- Add no columns and no commentary. If an item is not a job posting, list it under "Skipped" with a one-line reason.

Items:
[15 postings, blank line between each]

What that buys you: A table you can sort. The salary column is honestly half em-dashes — which is itself the finding, since it tells you most of these postings hide pay, something a guessed-at table would have concealed.

Now do it on your own work

Collect 10+ messy items of one kind (course descriptions, product reviews, college pages). Define four columns and their allowed values BEFORE looking at the items, then extract. Spot-check three rows against their sources.

Check yourself — every box should be true

You wrote the field definitions before running the extraction.
At least one column includes a fixed set of allowed values.
Your table contains at least one “—” — and you verified that the source really does not state it.
Your three spot-checked rows match their sources exactly.

Then explain it back

Defining the allowed values for one column was harder than expected. Which column was it, and what did the difficulty reveal about the thing you were trying to measure?

Write two or three sentences in your own words. If you cannot, you copied a prompt rather than learning a pattern — which is the whole difference this library is trying to make.

Does this depend on which AI tool I use?

Tool-agnostic, but the output target matters: ask for markdown to read on screen, or CSV to paste into a spreadsheet — and if you ask for CSV, add “quote every field, and escape internal commas”, because unquoted CSV from a language model breaks on the first comma inside a value.

Why it actually works

You have just written a labelling schema — the same decisions, with the same edge cases, that go into building a dataset before any model can learn from it.

Where data becomes a dataset →

Prompting well is a skill you can pick up in a week. Understanding what is happening underneath is the 18-month curriculum — and it is what stays useful when the tools change.

FAQ

Why not just let it choose the columns?: Because then the table answers the model's question rather than yours, and the columns change every time you run it. Fixing the schema is what makes the output comparable.
How do I handle a field that is sometimes two values?: Say so in the definition: “list all that apply, separated by semicolons”. Ambiguity you do not resolve in the definition gets resolved silently in the data.

Next patterns

The Prompt Patterns Library is a separate, optional track — it does not change the 78-week curriculum or your roadmap. See what the curriculum actually covers →