Turn messy notes into a plan you can actually use.

The useful output is a plan you can defend

A tidy table is not necessarily a good plan. If it gives an unassigned job to a convenient person, turns a tentative date into a deadline, or loses an unresolved question, it has made the notes look clearer by changing their meaning.

AI can be useful here because the job involves sorting and rephrasing language. But the boundary matters: ask for a proposed structure based on the notes, not a completed project plan assembled from assumptions. You remain responsible for deciding what is agreed and what happens next.

This walkthrough uses invented notes about a community workshop. It is a teaching example, not a transcript of a real meeting or a measured test of a particular model. Try it with the fictional material first; use your own information only when sharing it is appropriate.

Start with deliberately awkward notes

Here is our sample: “Workshop planned for October. Sam will check room availability. Maybe Tuesday evenings? Alex can draft the invitation once the venue is confirmed. Need a budget. Someone suggested recording the session; ask attendees first. Review the plan next Friday.”

Several things are missing. There is no exact workshop date, no approved budget, and no owner for deciding whether to record. “Next Friday” depends on the date of the conversation. “Maybe Tuesday evenings” is a suggestion, not a booking.

These gaps are not flaws to hide. They are some of the most valuable information in the notes. A good extraction should make them easier to see. If the model fills them in, the result may be less reliable than the original messy paragraph.

Watch one note become a checked action

The film focuses on a common mistake: changing “check room availability” into “book the room by Friday.” Those are different commitments. The rows shown are authored teaching examples; no model or task system is running.

From messy notes to a reviewed action

Two fictional notes show how a neat-looking plan can introduce a commitment that nobody made—and how to repair it.

Read the video explanation

The source notes say that Sam will check room availability and that the plan should be reviewed next Friday. Those are different actions.

An authored bad extraction says Sam should book the room by Friday. It changes checking to booking and borrows a date from another note.

Repair the row: check room availability; owner Sam; deadline not specified. Keep the original note beside the action.

Preserve dependencies: venue confirmation comes before drafting the invitation. Confirm owners and intended dates, then copy only reviewed actions. A proposal is not an assignment.

Give the tool a narrow contract

Specify the job, the source boundary, the output structure and the treatment of uncertainty. The following prompt is intentionally plain. Its value is in telling the tool what not to infer, rather than giving it a grand-sounding role.

Organise these notes into a proposed action plan. Use only the information provided. For each action, include the task, any stated owner, any stated deadline, and the exact note it came from. Write “not specified” when information is missing. Keep suggestions separate from agreed actions. Finish with questions I need to answer before acting.

Keep your instructions separate from the notes with a clear label such as “Source notes.” If the notes include a request or instruction somebody said during the meeting, that sentence is material to analyse; it is not automatically a new instruction to the assistant.

For an initial trial, ask it to return the plan in the conversation. Do not connect the exercise to a calendar, shared task manager or email sender. You want to inspect the proposal before it changes anything outside the chat.

What a faithful first pass could contain

Here is an authored example of the proposed output. It is not a claim that a tool will always produce these rows correctly.

Keep “October” as the proposed workshop month and “Tuesday evenings” as a possible schedule outside the agreed-action rows. Neither establishes a specific booked date. A short list can be easier to use than a table; what matters is retaining the same distinctions.

The questions to resolve are concrete: What is the intended review date? Who decides the budget? Is Alex agreeing to draft the invitation? Who asks about recording? Which venue and event date are confirmed? These are human questions; the tool should not assign names just to complete the table.

Review the extraction before the wording

First compare every action against its source. “Sam will check room availability” supports a task owned by Sam. It does not support “Sam will book the room by Friday.” Checking and booking are different actions; Friday was attached to reviewing the plan, not to this task.

Then check whether dependencies survived. Alex's invitation draft depends on venue confirmation. A flat list that places it next to the room check without preserving that dependency can invite work to begin too early.

Finally inspect what is absent. Did the output keep the question about recording? Did it separate a possible Tuesday schedule from a confirmed date? An extraction can contain no obviously false sentence and still omit something important. Accuracy includes coverage, not only the truth of the rows that remain.

Use a review table, not blind confidence

For each proposed row, record one of three decisions: accept, correct, or ask. Accept means the original note supports the row. Correct means you can repair a specific mismatch. Ask means the missing information requires someone else's decision.

A row can be well extracted but not ready to execute. “Agree a budget — owner not specified” may be a faithful representation of the notes, yet still need an owner. Do not punish the tool for exposing that gap. The next human action is to resolve it, not to persuade the tool to produce a name.

If a row contains an exact quote, check that it is genuinely exact. A source column makes review easier, but the model can also misquote or attach the wrong source. Treat the quotation as a pointer to inspect, not a certificate of correctness.

Resolve relative dates explicitly

Words such as tomorrow, next Friday and later this month depend on context. If you know the meeting date, supply it and ask the tool to show how it interpreted the relative expression. If you do not know it, leave the date unresolved.

Even a calendar-correct conversion may not reflect the speaker's intention. Different people use “next Friday” differently. For consequential deadlines, confirm the date with the person involved before adding it to a shared plan.

The same caution applies to language such as “Alex can help.” Capacity is not the same as assignment. Your structure should preserve the difference between an offer, a suggestion and an agreed responsibility.

Turn the reviewed plan into a next step

Once the extraction is accurate, ask which tasks can start without an unanswered question. Request a short explanation tied to the dependencies in the notes. This produces a proposal for sequencing, not an authoritative project schedule.

For the workshop, checking room availability can probably begin. Publishing invitations should wait for venue confirmation. Recording the event should not be treated as approved simply because it appeared in the discussion. The next step may be a conversation rather than a task.

Copy only reviewed actions into your actual system. Keep a link or reference to the original notes where appropriate, and make ownership visible. The person receiving the task should not have to guess whether they agreed to it or an AI assigned it.

Try the method on a different kind of project

For a personal creative project, your notes might say: “Try a photo zine. Ask Jo whether they want to help. Choose images after agreeing the theme. Maybe print a few copies.” The same review method keeps an invitation separate from an assignment, a dependency separate from a deadline, and a printing idea separate from an approved order.

Start with fictional or non-sensitive notes you can understand without extra context. Ask for only a few proposed items. Mark each accept, correct or ask, then choose a single next step that is actually supported. Keep a separate list of ideas that remain optional.

For workplace notes, check the applicable tool and information-sharing rules before supplying them. For any real project, keep the original notes available while reviewing, and avoid copying unresolved rows into a shared task system as if they were agreed.

Decide whether to repeat the workflow

Time the whole process: preparation, generation, checking and corrections. Notice the kinds of errors as well as the total time. If every trial requires you to reconstruct the notes from scratch, the workflow may not be helping.

If it does help, save the prompt and a short checklist of your recurring failure cases. Recheck when the tool or input type changes. The practical win is not that AI produced a table. It is that you reached a clearer, traceable plan with less effort and without quietly changing the decisions.

Go to the source

Primary sources checked on 13 October 2026. Publication dates and product details may differ; check the source for its scope.

• Google: Prompt design strategies