Extract action items

Pull tasks, owners, and dates out of messy notes as structured data, with an explicit rule for the owner nobody named.

When to use it

Turning a transcript or a page of notes into a task list a tool or a person can act on, where a missed owner is a dropped ball.

What it prevents

The guessed owner. Told to extract tasks, a model will assign a name to an unowned action rather than leave it blank — and a confidently wrong owner is worse than an obvious gap, because it looks handled. The explicit null rule is what keeps the unassigned tasks visible.

The prompt

Extract every action item from the meeting notes below.

### Output format
Return JSON and nothing else: [{"task": "string", "owner": "string or null", "due": "YYYY-MM-DD or null"}]

### Requirements
- One object per distinct action. Do not merge two tasks into one.
- Use null for an owner or date the notes do not state. Do not infer them.
- Preserve the task wording; do not rephrase it.

### Example
[{"task": "Send the revised quote to the client", "owner": "Priya", "due": null}]

### Notes
"""
Priya to send the revised quote. We should book the venue before Friday — someone from ops.
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Avoids dangling references — why this matters
• Includes an example — why this matters
• Separates data from instructions — why this matters
• Avoids over-aggressive phrasing — why this matters

How to adapt this one

Point it at your notes and keep the two disciplines: one object per distinct action, and null for anything the notes do not state. The wording-preservation rule matters if the output feeds a person — a rephrased task can quietly change its meaning. Adapt the fields (add a priority, a project) but keep the anti-inference rule, because the gaps are the whole reason you are extracting rather than reading.

The mistake this prompt avoids

Letting the model merge or invent. Two related tasks become one and a vague “we should” becomes a firm assignment to whoever was nearest in the text. Extraction from discussion is mostly a discipline of not smoothing — one action per item, no owner the notes did not name, no task you cannot point to a line for.

A variation

Processing a recurring meeting's notes? Feed last session's open items alongside the new transcript and ask the model to mark which previously-open actions are now resolved, still open, or newly dropped. The value of standing notes is continuity, and a model comparing two sessions catches the quietly-abandoned task faster than the person who owned it will.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.