meeting-notes-to-actions
Skill0 starsChanged 39 days agoMITView on GitHub
Converts raw meeting notes or transcripts into a four-part record - a 3-5 sentence summary, the decisions actually made, an action table with owner, verb-phrased action, due date, and status, and the open questions - without inventing owners, dates, or tasks. Use when someone pastes notes and asks "pull the action items out of this", "summarize this meeting", "who owns what from this transcript", or "what did we actually decide". Do NOT use for preparing the agenda before a meeting happens - use meeting-agenda instead - or for turning extracted actions into engineering tickets - use jira-ticket-writer instead.
9 other projects use a version of this.
Adopted by
Most recently taken up by
- Lethe044/agentskill-kittheir own version, first seen Nov 1, 2026
- Amazon-Quick/Amazon-Quick-official-catalogtheir own version, first seen Oct 28, 2026
- dss-time/repo-doctor-skillstheir own version, first seen Oct 15, 2026
- Baba01hacker666/dummyskillstheir own version, first seen Oct 13, 2026
- create-aquarius/business-skills-jatheir own version, first seen Sep 17, 2026
- rickbauer327-cell/solo-stack-startertheir own version, first seen Sep 15, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- Amazon-Quick/Amazon-Quick-official-catalog★ 50same name
- Lethe044/agentskill-kit★ 48same name
- mDevsLabs/Skills★ 2same name
- rickbauer327-cell/solo-stack-starter★ 2same name
- ahnchen1983/agentic-substrate★ 1same name
- dss-time/repo-doctor-skills★ 1same name
- Baba01hacker666/dummyskills★ 0same name
- create-aquarius/business-skills-ja★ 0same name
- kakarot-oncloud/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- 1on1-agendaSkill
- async-communicationSkill
- feedback-writerSkill
- okr-builderSkill
- stakeholder-updateSkill
- weekly-reviewSkill
The file
We split this skill into the rules it gives an agent
11 rules. 0 are common, 11 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 7 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
If the notes are too thin to extract from (no verbs, no names), say so and return what is extractable rather than padding.
- Distinctive: line 84
Do not invent owners, dates, or tasks.
- Distinctive: line 85
Do not quietly drop ownerless actions or assign them to a plausible person - UNASSIGNED in caps is the feature, not a formatting failure.
- Distinctive: line 86
Do not phrase actions as topics.
- Distinctive: line 87
Do not promote debated-but-unsettled items to Decisions.
- Distinctive: line 88
Do not editorialize or add advice.
- Distinctive: line 89
Do not paraphrase names or normalize spellings.
- Distinctive: line 93
All four sections present, in order.
- Distinctive: line 94
Every action row has all four columns filled (with UNASSIGNED / TBD where applicable) and starts with a verb.
- Distinctive: line 95
No duplicate rows for the same commitment.
- Distinctive: line 96
Every decision and action traces to a specific line in the source.
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Meeting Notes to Actions
The expensive failure with meeting notes is not messiness - it is the commitment that silently evaporates because nobody wrote down who owns it. This skill extracts, rather than reformats: decisions and commitments come out of the noise, gaps in ownership are made loudly visible instead of papered over, and nothing is invented that was not in the room.
Operating procedure
Step 1: gather inputs
- The raw material: notes, transcript, chat log, or bullet dump. Accept it as-is.
- The meeting date if stated or supplied - relative dates like "Friday" can only be resolved to a calendar date when the meeting date is known; otherwise keep the relative form exactly as written.
- Attendee names if available, used only to disambiguate ("Alex" when two Alexes attended); never to guess owners.
If the notes are too thin to extract from (no verbs, no names), say so and return what is extractable rather than padding.
Step 2: extract in three passes
Pass the material three times, one lens per pass - a single pass reliably misses commitments buried inside discussion:
- Decisions: a choice between options that was settled. "We're going with quarterly billing" is a decision. Something debated but left open is not - it goes to Open Questions.
- Commitments: any first-person or assigned promise - "I'll handle X", "Priya will send Y", "we should do Z by Friday" - becomes an action item.
- Unresolved threads: questions raised and dropped, disagreements without a settlement, "let's discuss offline."
Collapse duplicate mentions of the same action into one row, keeping the most specific phrasing and the latest stated date.
Step 3: apply the action-item rules
- Owner: exactly one name per action, preserved exactly as written in the notes. If no owner was named, write UNASSIGNED - visibly, in caps - so the gap gets fixed in review rather than discovered at the deadline. Never assign the note-taker, the meeting organizer, or the most plausible person by inference.
- Action: phrase as a verb-first instruction ("Send the pricing draft to sales"), never a topic ("Pricing draft"). A topic cannot be done; a verb can.
- Due: only when explicitly stated. Resolve relative dates ("by Friday") to calendar dates only if the meeting date is known. Otherwise write TBD. Do not infer urgency into a date.
- Status: default "Not started" unless the notes say the work already began.
Step 4: assemble the four sections, in order
- Summary - 3 to 5 sentences: what was discussed and why it mattered. No filler, no play-by-play.
- Decisions - one line each: the decision plus the rationale if one was stated.
- Action items - the table: Owner · Action · Due · Status.
- Open questions / follow-ups - each with who should resolve it, if that was stated.
Step 5: verify against the source
Before returning, check every table row traces to a specific line in the notes. If a row cannot be pointed back to the source, delete it - an invented action is worse than a missed one, because it spends someone's time on work nobody asked for.
Worked extraction example
Raw notes:
- pricing discussion went long. sarah thinks we should test $49, marc pushing $59
- decided: go with $49 for the beta cohort, revisit after 100 signups
- marc: "I'll get the updated pricing page copy to design by Thursday"
- need someone to set up the signup dashboard before launch - nobody volunteered
- also sarah mentioned the pricing page again later, marc said "yeah yeah Thursday"
- legal review of new ToS?? tabledExtracted:
Decisions:
- Beta cohort priced at $49; revisit after 100 signups. (Rationale: test lower price point first.)
| Owner | Action | Due | Status |
| Marc | Send updated pricing page copy to design | Thursday | Not started |
| UNASSIGNED | Set up the signup dashboard before launch | TBD | Not started |
Open questions:
- Legal review of the new ToS - tabled; no owner named.
Note what the rules did: the two mentions of Marc's pricing-page task collapsed into one row; the dashboard task kept its commitment but exposed the ownership gap as UNASSIGNED rather than guessing Sarah; "Thursday" stayed relative because no meeting date was given; the $49-vs-$59 debate produced one decision line, not two actions; and the ToS item landed in open questions because "tabled" is not a decision.
Deliverable
Produce the four-section record - summary, decisions, action table (Owner · Action · Due · Status), open questions - where every row is traceable to the source notes, every ownerless action reads UNASSIGNED, and every unstated date reads TBD.
Do NOT
- Do not invent owners, dates, or tasks. The output's value is that it can be trusted; one fabricated row poisons the whole table.
- Do not quietly drop ownerless actions or assign them to a plausible person - UNASSIGNED in caps is the feature, not a formatting failure.
- Do not phrase actions as topics; "Q3 offsite" is not an action, "Book venue for Q3 offsite" is.
- Do not promote debated-but-unsettled items to Decisions; they belong in Open Questions.
- Do not editorialize or add advice. The role is recorder, not participant - neutral and factual, unless the user explicitly asks for recommendations.
- Do not paraphrase names or normalize spellings; preserve them exactly as written.
Quality bar
- All four sections present, in order; the summary is 3-5 sentences.
- Every action row has all four columns filled (with UNASSIGNED / TBD where applicable) and starts with a verb.
- No duplicate rows for the same commitment.
- Every decision and action traces to a specific line in the source.
- Zero content exists in the output that did not exist, at least implicitly, in the notes.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

