After a client call, the same admin always follows: reread the notes, work out what was actually decided, write down who owes what by when, and send a recap before memories drift.
That job is repetitive and has a clear right answer, which makes it a good fit for a Claude skill. So I made one. It is under 100 lines of Markdown, MIT licensed, and free. Below are the design decisions behind it, most of which apply to any skill.
A skill is a folder with a SKILL.md file in it. The file starts with YAML frontmatter holding a name and a description, followed by instructions in Markdown. There is no code, no dependencies and no API calls. Claude reads the instructions when the skill is relevant and follows them.
---
name: call-notes-to-actions
description: "Turns a meeting transcript, call recording notes, or rough meeting"
notes into a crisp summary with decisions, an action-item table (owner, action,
due date), open questions, risks, and a ready-to-send follow-up email. Use when
someone asks to summarize a call or meeting, extract action items, write meeting
minutes, or draft a follow-up email after a client call.
---
That is the whole interface.
Claude reads the description to decide whether the skill applies to a request. A short, tidy one-liner like "Turns meeting notes into action items" is accurate, but it shares very few words with what people actually type.
So the description names three things: the inputs (transcript, call recording notes, rough notes), the outputs (summary, decisions, action-item table, follow-up email), and an explicit "Use when..." clause listing the requests: summarise a call, extract action items, write meeting minutes, draft a follow-up email.
A useful exercise: write down five ways you might ask for the skill, then check that each one shares vocabulary with the description. Instructions that never load do nothing.
The obvious risk with meeting notes is minutes that look polished but include decisions nobody made. The skill has a few short rules for this, and I now reuse them in every skill:
Only extract what was said. No invented decisions, owners or dates.
Mark inference, don't hide it. If an owner or due date is implied but never stated, the skill fills it in and appends (proposed). You still get a usable draft, and you can see exactly which parts are guesses.
Give vagueness somewhere to go. Calls are full of "we should look into that". Those become action items with owner TBD instead of being dropped, so nothing quietly disappears.
Keep decisions and questions apart. The instructions define both: a decision is something agreed, and a question is something still open. Without that line, ambiguous points tend to end up in the decisions list, where they look settled.
The skill specifies the exact output: a summary of at most three bullets, numbered decisions, an action table with owner | action | due | status, open questions, risks, the follow-up email, and a "To confirm" block to delete before sending.
A fixed shape has two benefits. The output is skimmable in the same way every time. And gaps become visible: an empty owner cell stands out, while the same gap inside a paragraph does not.
The email is built from the same table, under the headings "We agreed / I'll / Could you / Still open". Because the recap and the table come from one source, they shouldn't disagree, which is a common failure when you write the recap by hand.
The last section is a checklist the skill goes through silently before answering:
Per line, this is probably the most useful part of the file. It isn't a guarantee, because it's still a model checking its own output, so you should still read the result before sending. But it turns vague quality goals into specific things to check.
"Next Friday" is a trap. The skill converts relative dates using the meeting date, or today's date if the meeting date is unknown, and notes that assumption in the "To confirm" block. Any LLM workflow that handles dates needs an explicit rule about which day it counts from. Otherwise you get deadlines that sound confident and are wrong.
In Claude Code:
/plugin marketplace add FairdraftStudio/call-notes-to-actions-skill
/plugin install call-notes-to-actions@fairdraft-studio
In the Claude app: turn on code execution and file creation under Settings > Capabilities, then go to Customize > Skills > Upload skill and choose call-notes-to-actions.zip from the repo.
Then paste a transcript and say "summarise this call and draft the follow-up email". The repo has a worked example with an input and its output.
Repo (MIT): https://github.com/FairdraftStudio/call-notes-to-actions-skill. I also make paid skills and matching Word / Google Docs templates for client paperwork, linked from the README. This post and the skill were drafted with help from Claude and reviewed by me. Not affiliated with or endorsed by Anthropic.