How to turn meeting notes into decisions with Claude Code

What is the actual output you want from a meeting?

Not a summary. A summary of a planning meeting is pleasant to read on the day and worthless the following month, because it records what was said rather than what changed. The output worth building is a decision record: for each decision, what was decided, who owns it, the date, what would reverse it, and the exact line in the transcript where it was agreed.

Write the record so a person who missed the meeting can act on it without watching the recording. That is the whole test, and most notes fail it because they preserve the discussion and drop the conclusion.

How does Claude Code do this differently from a notes app?

It works on files in a folder, which sounds like a downgrade and is the entire advantage. Drop the transcript into the folder where your specs and requirement documents already live, and the same session that extracts decisions can also check them against what you wrote three weeks ago. When a meeting quietly reverses a decision recorded in an existing document, that contradiction is visible in one pass instead of surfacing at the worst possible moment during build.

Claude Code also loads a project instructions file at the start of every session, so the format you want is written down once rather than re-explained every Monday. Put the four fields, the quote rule and the owner rule in that file and the extraction becomes consistent across people, which matters more than it sounds: two PMs producing differently shaped records is the reason nobody searches them.

What prompt turns a transcript into a record?

Name the file, name the format, and demand evidence. The working version reads roughly like this: read the transcript in notes/2026-09-15-pricing-sync.md and produce three sections. First, decisions, each with the decision in one sentence, the owner, the date, one sentence on what would reverse it, and the verbatim line where it was agreed with the speaker name. Second, open questions, each with the person who needs to answer it and the date it blocks. Third, discussed but not decided, for anything that sounded like agreement but was hedged.

The third section does most of the work. It gives the model somewhere to put ambiguity, which is the alternative to inventing certainty. Without it, "yeah, probably, if engineering is fine with it" becomes "the team decided to ship annual billing", and three weeks later somebody builds it.

Which failure modes should you expect?

• Promoted hedges. Tentative agreement rewritten as a decision. The quote requirement catches this, because the quote still contains the hedge and a reader can see it.
• Inferred owners. A name attached to a task nobody assigned. Instruct it to write unassigned rather than guess, then fill the gap yourself in the same sitting.
• Silent scope loss. A long transcript where the last twenty minutes get compressed into one line, usually the twenty minutes containing the actual conclusion. Ask for a decision count and a timestamp range per section, and check that the range covers the whole call.

None of these are exotic. They are the ordinary behaviour of a system optimised to produce a clean, confident document, which is why the format has to fight for ambiguity rather than assume it will survive.

Does the record still make sense a week later?

This is the check worth running once before you trust the habit. Take last week's record, read it cold without the transcript, and see whether you can answer three things: what changed, why, and what would make you change it back. If the "what would reverse this" field is empty or generic, the decision was never really made, it was just announced, and the record is now recording an announcement.

That field is also the one people cut first because it feels like extra work. It is the reason the record beats a summary. A decision with a stated reversal condition is a decision you can revisit without re-arguing it from scratch, and a decision without one gets relitigated every time a new stakeholder joins.

How do you find a decision six months later?

This is where the files pay for themselves. One folder of dated records, one file per meeting, all in the same shape, is searchable by an agent in a way that a year of chat threads is not. Ask it to read every record in the folder and list every decision that touched billing, in date order, with the reversal condition attached, and you get an answer in one pass. Ask which of those decisions have since been contradicted by a later record and you get the thing nobody ever has time to assemble by hand.

The habit that makes this work is boring and non-negotiable: one file per meeting, a date in the filename, the same three sections every time. Consistency is what makes a folder queryable, and the moment two people use different headings the cross-record questions start returning partial answers with no warning that they are partial.

The honest limit is that a record only covers meetings that produced one. Most product decisions are made in a thread, a corridor or a one-on-one, and no extraction workflow reaches those. A decision folder that contains only your weekly planning meeting will confidently tell you that nothing was decided about billing in March, when in fact three things were, over chat. Treat the folder as the record of a specific forum rather than the record of the product.

Some meetings also should not go through this at all. Performance conversations, anything under a confidentiality agreement, and calls recorded without everyone understanding what happens to the transcript are worth keeping out by default rather than by exception.

Where does this fit alongside the rest of the AI workflow?

The extraction is the cheap half. The expensive half is the update that goes out afterwards, and that is a writing problem: the same three decisions land differently depending on whether the reader gets a bulleted dump or a narrative that explains the trade-off. Builders Camp's Product Storytelling bootcamp covers that layer over 1 week with 2 live sessions and 7 microlessons, including how to frame trade-offs and handle objections without drowning the reader in detail.

For the surrounding system, 10x Productivity with AI is the 1 week bootcamp aimed directly at this category of work: 2 live sessions, 8 microlessons, and a module specifically on turning meetings into action items, decisions and updates without manual cleanup. Claude Code for Product Managers goes narrower and deeper on the terminal workflow itself, including how to structure files and folders so an agent can reason across specs, research and decisions without losing the thread.

If your records live in a shared workspace rather than a repository, Notion for product managers covers that side, and NotebookLM is the better fit when the job is questioning a large pile of past notes rather than processing a single new one. For the underlying concept, the context window entry explains why a two hour transcript behaves differently from a twenty minute one.

Run it on the meeting you are least sure about

Pick the recurring meeting where nobody is quite certain what gets decided, and produce one record from its most recent transcript. The useful signal is not the record itself. It is the size of the "discussed but not decided" section, because a meeting that generates six open items and no decisions has just told you something about the meeting that no amount of better note-taking will fix.

See the Claude Code for Product Managers bootcamp

For the wider personal system around it, the 10x Productivity with AI bootcamp covers meeting automation, research synthesis and safe usage habits in 1 week.