WritingEveryday skill

Meeting Notes To Actions

Turns raw meeting notes or a transcript into clear decisions, action items with owners, and open questions.

What it does

The meeting ends, you have a page of half-sentences, and a week later two people remember the decision differently and nobody has done the thing everyone assumed someone else was doing.

With this skill active, the assistant reads your notes or transcript all the way through before it sorts anything, then splits it into three separate lists: what was actually decided, what one named person owns with a real date, and what is still unresolved. It is deliberately strict about the middle one. "We're leaning towards June" goes in the open questions, not the decisions, and a task nobody claimed is written down as unclaimed rather than quietly handed to whoever was nearest.

You get those three lists plus a short recap you can paste straight into email or chat, and a list of the gaps it refused to fill in for you.

You end up with decisions, owned actions with real dates, open questions, and a recap you can send in one paste.

When to reach for it

Use it right after any meeting where people will need to remember who agreed to what: project reviews, client calls, planning sessions, anything with more than three people in the room.

Skip it for a conversation with one action you will remember anyway, and know that it cannot rescue notes that never recorded who said things. If your notes have no names in them, it will hand back questions rather than invented owners.

What's inside

meeting-notes-to-actions/
├── SKILL.md
└── references/
    ├── examples.md
    └── patterns.md
SKILL.md
---
name: meeting-notes-to-actions
description: Turns rough meeting notes or a call transcript into three separate lists (what was decided, what someone owns with a real date, and what is still open), then writes a short recap the user can send to everyone who was in the room. Use after any meeting where people left unsure who owns what.
---

# Meeting Notes To Actions

You are the person in the room who wrote down who said they would do what. Everything you produce has to survive someone reading it a week later and saying "that is not what we agreed", so you write only what the notes actually support.

## Workflow

Sorting before reading is the mistake that ruins the output. The first pass is read-only.

1. **Read the whole input once, changing nothing.** You cannot tell a decision from a suggestion until you know how the meeting ended.
2. **Establish the frame:** meeting date, who was there, what it was for. Owners and dates depend on this.
3. **Sort every line into five buckets:** decision, action, open question, context, discard.
4. **Apply the decision test** to everything you put in the decision bucket. Most of it will move.
5. **Attribute each action:** one owner, one date. Never guess either.
6. **Write the three lists** in the fixed shape below.
7. **Write the send-to-the-team recap,** three to five lines.
8. **List what you could not attribute** as questions for the user.

```text
Meeting notes checklist
[ ] Whole input read before any sorting
[ ] Frame established: date, attendees, purpose
[ ] Every line placed in one of the five buckets
[ ] Decision test applied to each claimed decision
[ ] Every action has an owner or is explicitly marked unassigned
[ ] Every relative date resolved against the meeting date and written both ways
[ ] Compound actions split: one verb, one deliverable per line
[ ] Sensitive content kept out of the shareable recap
[ ] Gaps listed as questions rather than filled in
```

## Step 2: the frame

Ask for these three if the input does not carry them:

- **The meeting date.** Without it "by Friday" cannot be resolved and every date in your output is guesswork.
- **Who was in the room, by name.** Transcripts often label people as Speaker 1 and Speaker 2, and a wrong owner is worse than no owner.
- **What the meeting was for,** in one line. This tells you which of the twenty things discussed actually mattered.

If the user cannot supply them, work anyway and say exactly which parts of the output are weaker because of it.

## Step 3: the five buckets

Every line goes in exactly one.

| Bucket | What belongs there |
|---|---|
| Decision | A settled choice that changes what happens next |
| Action | A task with a person attached, or one that clearly needs a person |
| Open question | Discussed, not resolved. Needs a decision, a number, or someone not in the room |
| Context | Background the reader needs to understand a decision. Keep it to one or two lines total |
| Discard | Side chatter, jokes, scheduling talk, repeated points, thinking out loud |

The discard bucket is the one that makes the output readable. Most of a transcript belongs in it.

## Step 4: the decision test

Groups talk their way toward decisions and then leave without making them. All three of these must be true, or it is an open question:

1. **Someone with the standing to decide said it,** in a way that closed the topic rather than opened it.
2. **Nobody pushed back afterwards.** Agreement followed by "although" is not agreement.
3. **Something actually changes.** If nothing would be different tomorrow, it was a conversation.

"We're leaning towards June" fails all three. "Let's go with June, I'll tell the client" passes all three. When it is genuinely borderline, put it in open questions and write it as the question that remains: "Confirm June rather than July as the launch month."

Being too strict here is safe. Being too generous produces a document that tells people something was agreed when it was not, which is how meetings get repeated.

## Step 5: attribution

**Owners.** Take the name the notes give you. If someone said "I'll pick that up" and the transcript labels them Speaker 3, write `[Speaker 3 - name needed]` rather than picking the likeliest person. If nobody claimed it, write `[unassigned]`. An unassigned action is not a failure of your work; it is the single most useful line in the document, because it is the thing that will otherwise silently not happen.

A team name is acceptable only when the notes never named a person: `[Design team]`, flagged.

**Dates.** Resolve every relative date against the meeting date and write both forms, so nobody has to recalculate:

- "by Friday" said on Tue 5 Aug becomes `due Fri 8 Aug`
- "end of next week" becomes `due Fri 15 Aug`
- "before the launch" stays as `due before launch - date needed`, because you do not know the launch date
- nothing said becomes `no date set`

**Splitting.** One action is one verb and one deliverable. "Sam will send the numbers and book the follow-up" is two lines with the same owner. Anything with "and" in the middle needs a second look.

## Output format

Use this shape every time. Empty sections say "None" rather than disappearing, because an absent section reads as an oversight.

```text
[Meeting name] - [date]
Present: [names]

Decisions
- [what was decided, one line, past tense]

Action items
- [Owner] [one verb, one deliverable] - due [day date]

Open questions
- [the unresolved thing, written as a question]

Needs your input
- [anything you could not attribute, as a question to the user]
```

Then, separately:

```text
Send to the team
[Three to five lines a person can paste into email or chat. Decisions first,
then who owns what, then the one thing that is still open. No preamble.]
```

## Example

**Input** (typed notes, meeting date Tue 5 Aug, present: Sam, Priya, Marc):

> pricing again. sam thinks we're too cheap for enterprise, priya not sure. sam will send new numbers friday. marc raised that support costs are up 30% since march - not in any of the models. still not sure if we launch in june or july, priya wants to check with the client first. someone needs to update the pricing page whenever we land this. marc's coffee machine story, ignore.

**Output:**

```text
Pricing review - Tue 5 Aug
Present: Sam, Priya, Marc

Decisions
- None. Pricing direction was discussed but not settled.

Action items
- [Sam] Send revised enterprise pricing numbers - due Fri 8 Aug
- [Priya] Check launch timing with the client - due no date set
- [unassigned] Update the pricing page once pricing is agreed - due after pricing decision

Open questions
- Are we underpriced for enterprise? Sam says yes, Priya is not convinced.
- Do we launch in June or July?
- Support costs are up 30% since March and appear in none of the pricing models. Who owns adding them?

Needs your input
- Nobody claimed the pricing page update. Who should own it?
- Did Priya get a deadline for the client conversation?
```

```text
Send to the team
Pricing is still open - no decision today. Sam is sending revised enterprise
numbers by Friday 8 Aug, and Priya is checking launch timing with the client.
Marc flagged that support costs are up 30% since March and are missing from
every pricing model, which we need to resolve before we can settle a number.
Still open: June or July launch, and who updates the pricing page.
```

Notice that "Sam thinks we're too cheap" became an open question rather than a decision, the coffee machine story disappeared, and the unassigned page update survived as a line rather than being quietly assigned to Marc.

## Rules

- Never invent an owner, a date, or a decision. Unassigned and "no date set" are correct answers.
- Discussed is not decided. When in doubt, it is an open question.
- Cut side chatter, personal remarks and anything about people who were not in the room.
- One action per line. Compound tasks get split.
- Keep the wording plain enough that someone who missed the meeting understands it without asking.
- Do not soften a commitment someone made out loud, and do not harden a maybe into a yes.
- If the notes contain almost nothing usable, say so and ask two or three specific questions rather than producing a thin document that looks complete.

## Edge cases

- **Anonymous transcript labels.** Keep the label, flag it: `[Speaker 2 - name needed]`. Ask the user to map labels to names once, then rerun.
- **The meeting decided nothing.** Say so in the first line. A meeting with three open questions and no decisions is a useful finding, and hiding it wastes another meeting.
- **Two decisions that contradict each other.** People change their minds mid-meeting. Take the later one, and note the reversal in one line so nobody acts on the earlier one.
- **Agreement by silence.** One person proposes, nobody speaks, the topic moves on. That fails the decision test. Write it as an open question phrased for confirmation.
- **Sensitive content.** Performance, salaries, redundancies, a named person's mistakes. Keep it out of the shareable recap entirely and tell the user in one line that you did and why.
- **Recurring meeting.** Ask whether last week's open items should be carried forward. If the notes reference "the thing from last week" without saying what it is, list it under Needs your input.
- **Actions for someone who was not there.** Record the owner as stated and add `- not in the meeting, needs telling`. This is the most commonly dropped action item there is.
- **Someone volunteered while being stared at.** Record it exactly as said. It is not your job to renegotiate it, but flag it under Needs your input if the notes show hesitation.
- **Notes in two places.** Typed notes plus a chat thread. Read both before sorting, and when they disagree, follow the transcript and note the disagreement.

## Files

- `references/examples.md` - three complete runs: scrappy typed notes, a raw transcript with anonymous speaker labels, and a project meeting where nothing was decided. Read one end to end before your first pass.
- `references/patterns.md` - the phrases that signal a real decision against the ones that only sound like it, a date resolution table, splitting rules for compound actions, and the recap template. Read it at steps 4 and 5.

Install it

Claude Code (this project)

Unzip the download into .claude/skills/. The folder is already named right.

Claude Code (every project)

Unzip into ~/.claude/skills/ to use it everywhere.

claude.ai

Upload the zip under Settings, then Capabilities, then Skills (paid plans).

How to call it

Just describe the task. The description line inside the skill does the matching. Or call it directly:

/meeting-notes-to-actions turn these meeting notes into action itemswho agreed to do what in this callsummarise this transcript into decisions and next stepswhat did we actually decide and what is still openwrite a follow-up I can send the team after this meeting

Works beyond Claude

Skills use the open Agent Skills format. The exact same folder works in OpenAI Codex, Gemini CLI, Cursor, GitHub Copilot and other tools that read the format.

Using a plain chat app? Paste SKILL.md into ChatGPT or Gemini as instructions. You lose auto-triggering, but the method still works.

agentskills.io

Related skills

Status Report Writer Task Breakdown Decision Journal SOP Writer

Read the step-by-step guides