Use in
ChatGPTClaudeGeminiGrok
Creates with
Your assistant
Output
DOC
LazyCoder skill

Turn meeting notes into actions

Use this recipe to create a document.

Free

Paste into your assistant. It asks the questions; you answer in chat.

More ways to use
Install the downloaded skill

Extract the ZIP. Copy its lc-meeting-notes-actions folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.

For Claude web, use the connector or copy the prompt. Keep private details in your assistant.

How to use this skill

Copy, paste into your assistant, then answer its questions. No form or account is required here.

Open in ChatGPT ↗

Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.

Open Claude ↗
Optional: prepare details on this device

Bring your details

Paste raw notes or a transcript. Messy is fine. In the app you can attach the file instead.
Everyone in the meeting, with roles. The AI uses only these names, so nobody gets invented.
Lets it turn “by Friday” into a real date and suggest dates for vague ones.
3 optional details
Goes in the recap email’s subject line.
Change it if the recap goes to a client or your boss.
Leave it to address everyone in the meeting.
This request goes last so your latest scope is clear. It stays in this tab.

Needed before the promised result: Your notes or transcript. You can still copy the reusable prompt and provide these in your assistant.

Saved only on this device. Copy counts contain the skill ID, never your text.

Read the prepared prompt
## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.

### Questions to ask only when missing
- What should I use for “Your notes or transcript”? [required] Paste raw notes or a transcript. Messy is fine. In the app you can attach the file instead.
- What should I use for “Who was there”? [optional] Everyone in the meeting, with roles. The AI uses only these names, so nobody gets invented.
- What should I use for “Meeting date”? [optional] Lets it turn “by Friday” into a real date and suggest dates for vague ones.
- What should I use for “Meeting name”? [optional] Goes in the recap email’s subject line.
- What should I use for “Tone of the recap”? [optional] Change it if the recap goes to a client or your boss. Authored default: neutral and brief Choices: neutral and brief; friendly; formal
- What should I use for “Who gets the recap”? [optional] Leave it to address everyone in the meeting. Authored default: everyone who attended

## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.

## Authored skill instructions
## 1. Outcome
Turn the meeting notes below into a finished meeting record and a recap email ready to send, in the sections set out in part 6. Done means: every commitment made in the meeting is in the actions table and traces to the notes, nothing is invented, and anything unclear is flagged for a person to fix instead of guessed.

## 2. Context
Meeting: [MEETING NAME]
Meeting date: [MEETING DATE]
People in the meeting: [NAMES AND ROLES]
The recap email goes to: everyone who attended

Notes:
"""
[PASTE YOUR NOTES OR TRANSCRIPT HERE]
"""

Who it's for: the people in the meeting and anyone who missed it. They use the record to see what was decided and what each of them owes by when, and the email to confirm it.

Blank fill-ins: a Meeting, Meeting date, People or Notes value that still reads as a capitalised placeholder in square brackets (such as [MEETING DATE]) was left blank. Bracketed text inside real notes, such as [inaudible], [00:12:30] or [Speaker 2], is part of the notes.
- Notes that say "see attached": use the attached file as the notes.
- No notes: reply only "No meeting notes came through. Paste or attach them and send again." Never invent a meeting.
- No meeting name: take it from the notes, or name the meeting after its main topic.
- No meeting date: use a date written in the notes. If there is none, keep every relative or vague date in the notes' own words, with no weekday and no suggested date; sort the actions in the order they came up; skip the "due within 3 working days" part of the priority rule; give no suggested next-meeting date; and say "No meeting date given, so dates were not converted" in the header.
- No people list: take the names from the notes and apply the name rules to them.

## 3. What to pull out
- Decisions: what the group agreed, chose, approved or ruled out.
- Actions: anything a person agreed or was asked to do.
- Risks and blockers: anything that could stop or delay an action or a decision, such as a missing input, someone away, or a clash of dates.
- Open questions: raised but not settled.
- Next meeting: its date if one was set, and what carries over to it.

Edge cases:
- A decision reversed or changed later in the meeting: keep only the final version and add "(changed from: <earlier version>)". Drop actions that belonged to the abandoned option. If you can't tell which version stands, make it an open question.
- The same action said more than once: one row, sourced from its clearest mention.
- Two owners or two dates for one action: if a later line corrects the first, use the correction. If not, write "Unsettled" in that cell.
- No owner, only a tentative one ("Priya?"), or only "someone should": Owner is "Unassigned". No date: Due is "Not stated". Never turn a suggestion into an assignment.
- Exact relative dates ("tomorrow", "by Friday" said earlier in that week): convert them using the meeting date and keep the words, e.g. "Fri 16 Oct 2026 (by Friday)". Vague or ambiguous ones ("soon", "ASAP", "early next week", "next Friday", or a weekday that falls on the meeting day): pick a sensible date and mark it "(suggested)".
- Names: an owner must be in the people list. Match a first name, nickname or initials only when it fits exactly one person. A name that fits nobody or several people is never an owner.
- Transcripts: a speaker label shows who spoke, not who owns the work; the owner is whoever agreed or was asked. Match generic labels ("Speaker 2") to a person only when the transcript makes it clear, for example by addressing them by name. Skip small talk.
- Long notes: work through all of it, topic by topic. If space runs short, shorten wording, never drop rows.

## 4. Steps
1. Read all the notes, then list every candidate decision, action, risk and question with its source.
2. Apply the edge cases in part 3, then convert dates using the meeting date.
3. Sort and number the actions as part 6 says.
4. For each action, fill Depends on. If an action is due before the action it waits on, add that to Risks and blockers.
5. Set each priority, write the output, then run the self-check.

## 5. Rules
- Use only names from the people list. Never invent a person, a decision or a commitment. The only dates you may supply are those marked "(suggested)" under the date and next-meeting rules.
- Start each action with a verb and keep it under 15 words.
- Source: the timestamp if the notes have one, otherwise a quote of at most 10 words.
- Priority: High if called urgent (including "ASAP"), if another row's Depends on names it, or if its stated or converted (not suggested) due date is within 3 working days of the meeting. Low if called optional or nice to have. Otherwise Medium.
- Write every date with its weekday, as in "Fri 16 Oct 2026", unless there is no meeting date (part 2 says what to do then).
- Write for someone who missed the meeting: spell out the notes' shorthand and abbreviations. Tone of the recap: neutral and brief.

## 6. Output
Use these sections in this order. Write "None" under any that is empty.
1. Header: meeting name, date and who was there (add "from the notes, please confirm" if no people list was given), then 2–3 sentences on what was settled and what is still open.
2. Decisions: numbered, one line each, final versions only.
3. Actions: a table with the columns # | Action | Owner | Due | Priority | Depends on | Source. Every action gets exactly one row, including those also listed in section 4. Order: rows with a date, stated or suggested, in date order; then "Not stated" and "Unsettled" rows, in the order they came up. Number the rows 1, 2, 3 in that final order. Depends on holds the # of the row it waits on, a named outside item, or "—".
4. Needs an owner or a date: each row whose Owner or Due is "Unassigned", "Not stated" or "Unsettled", once, by its #, saying what is missing and any options or proposed names the notes give.
5. Names to check: each name, once, that is not in the people list or fits more than one person.
6. Risks and blockers: one line each, with the action or decision number it affects and who raised it, if stated.
7. Open questions: one bullet each, with who could answer it, or "unclear who".
8. Next meeting: the date if one was set. If not, write "Not set", and if the meeting clearly recurs (for example weekly), add the next usual date marked "(suggested)". Then the carry-overs: parked items, open questions, and actions due before then that need a report back.
9. Recap email, ready to send:
   - Subject: the meeting name, the date, and "decisions and actions".
   - To: the recipients above. If they say everyone or all attendees, list the people in the meeting by name only, with no email addresses.
   - Body, at most 200 words: one opening line; the decisions in brief; "What we need from each of you", with one line per person listing their actions and due dates; a request for an owner or date for each item in section 4; the next meeting. If it runs over, shorten the decisions first, never the asks. End with "Thanks," and no name.

## 7. Self-check
Before replying, check each of these and fix any failure:
- Every action has exactly one row in the table, with a Source that matches the notes.
- Every row has one owner from the people list and one due date, or is listed in section 4.
- No decision appears in both an earlier and a final version, and no action belongs to an abandoned option.
- Every converted date has the right weekday, and every vague date is marked "(suggested)" (unless there is no meeting date, then it stays in the notes' own words).
- The rows follow the sort order, and every Depends on number points to the right row.
- Every action due before the action it waits on is listed under Risks and blockers.
- Every priority follows the priority rule.
- The email has a subject, a To line, a line for every person with an action, and the next meeting.
Then reply with the output only, ending with one line: "Checked: <n> actions, <n> decisions, <n> flagged." Flagged is the number of entries in sections 4 and 5; each entry appears once, so it counts once.

## 8. Setup
Works as one paste in any chat app, with no tools or plugins. If your notes are a file, or a transcript too long to paste, attach it and write "see attached" in the Notes block.
Review your result locally

Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.

Every action with an owner and a date, the decisions, and a follow-up email.

Version & review details

What you get

  • Every action with an owner and a date, the decisions, and a follow-up email.

Good fit

  • Every action with an owner and a date, the decisions, and a follow-up email.
  • Use this when you can provide: Your notes or transcript.

Not for

  • Unattended actions, sending or publishing without your review.
  • Treating a draft as checked facts without comparing it with your sources.

About this skill

You say
Help me turn meeting notes into actions. Ask me for any details you need first.
Show more

Turn the meeting notes below into a finished meeting record and a recap email ready to send, in the sections set out in part 6. Done means: every commitment made in the meeting is in the actions table and traces to the notes, nothing is invented, and anything unclear is flagged for a person to fix instead of guessed.

Requirements & limits

  • Your notes or transcript — required for the result. Paste raw notes or a transcript. Messy is fine. In the app you can attach the file instead.

Works as one paste in any chat app, with no tools or plugins. If your notes are a file, or a transcript too long to paste, attach it and write "see attached" in the Notes block.

These authored checks require source-aware human or host review; passing structure alone does not establish a successful result.

Result checklist

  • Every action has one owner, a due date and a priority, or is flagged for you
  • No names you didn’t list
  • Each action quotes the words it came from
  • Vague deadlines are marked “suggested”
  • A decision changed mid-meeting shows only its final version
  • A recap email with a subject line and an ask for each person
Full output specification
Use these sections in this order. Write "None" under any that is empty.
1. Header: meeting name, date and who was there (add "from the notes, please confirm" if no people list was given), then 2–3 sentences on what was settled and what is still open.
2. Decisions: numbered, one line each, final versions only.
3. Actions: a table with the columns # | Action | Owner | Due | Priority | Depends on | Source. Every action gets exactly one row, including those also listed in section 4. Order: rows with a date, stated or suggested, in date order; then "Not stated" and "Unsettled" rows, in the order they came up. Number the rows 1, 2, 3 in that final order. Depends on holds the # of the row it waits on, a named outside item, or "—".
4. Needs an owner or a date: each row whose Owner or Due is "Unassigned", "Not stated" or "Unsettled", once, by its #, saying what is missing and any options or proposed names the notes give.
5. Names to check: each name, once, that is not in the people list or fits more than one person.
6. Risks and blockers: one line each, with the action or decision number it affects and who raised it, if stated.
7. Open questions: one bullet each, with who could answer it, or "unclear who".
8. Next meeting: the date if one was set. If not, write "Not set", and if the meeting clearly recurs (for example weekly), add the next usual date marked "(suggested)". Then the carry-overs: parked items, open questions, and actions due before then that need a report back.
9. Recap email, ready to send:
   - Subject: the meeting name, the date, and "decisions and actions".
   - To: the recipients above. If they say everyone or all attendees, list the people in the meeting by name only, with no email addresses.
   - Body, at most 200 words: one opening line; the decisions in brief; "What we need from each of you", with one line per person listing their actions and due dates; a request for an owner or date for each item in section 4; the next meeting. If it runs over, shorten the decisions first, never the asks. End with "Thanks," and no name.

Version and review evidence

meeting-notes-actions
Version: recipe-f5b9db961a46ba329bbb3eb8
Release: publication-2cc5f3d871330e560bedbc0a
Fingerprint: f5b9db961a46ba329bbb3eb86214e7cb0c93e78d414a2bfb46e73905b004267d

Generated-result quality is not yet reviewed for this version. Existing content reviews do not verify a result made for you. Review method

No host-tested compatibility evidence is attached to this version. Listed apps are setup options.

Read the reusable instructions
## 1. Outcome
Turn the meeting notes below into a finished meeting record and a recap email ready to send, in the sections set out in part 6. Done means: every commitment made in the meeting is in the actions table and traces to the notes, nothing is invented, and anything unclear is flagged for a person to fix instead of guessed.

## 2. Context
Meeting: {{meeting}}
Meeting date: {{date}}
People in the meeting: {{people}}
The recap email goes to: {{recipients}}

Notes:
"""
{{notes}}
"""

Who it's for: the people in the meeting and anyone who missed it. They use the record to see what was decided and what each of them owes by when, and the email to confirm it.

Blank fill-ins: a Meeting, Meeting date, People or Notes value that still reads as a capitalised placeholder in square brackets (such as [MEETING DATE]) was left blank. Bracketed text inside real notes, such as [inaudible], [00:12:30] or [Speaker 2], is part of the notes.
- Notes that say "see attached": use the attached file as the notes.
- No notes: reply only "No meeting notes came through. Paste or attach them and send again." Never invent a meeting.
- No meeting name: take it from the notes, or name the meeting after its main topic.
- No meeting date: use a date written in the notes. If there is none, keep every relative or vague date in the notes' own words, with no weekday and no suggested date; sort the actions in the order they came up; skip the "due within 3 working days" part of the priority rule; give no suggested next-meeting date; and say "No meeting date given, so dates were not converted" in the header.
- No people list: take the names from the notes and apply the name rules to them.

## 3. What to pull out
- Decisions: what the group agreed, chose, approved or ruled out.
- Actions: anything a person agreed or was asked to do.
- Risks and blockers: anything that could stop or delay an action or a decision, such as a missing input, someone away, or a clash of dates.
- Open questions: raised but not settled.
- Next meeting: its date if one was set, and what carries over to it.

Edge cases:
- A decision reversed or changed later in the meeting: keep only the final version and add "(changed from: <earlier version>)". Drop actions that belonged to the abandoned option. If you can't tell which version stands, make it an open question.
- The same action said more than once: one row, sourced from its clearest mention.
- Two owners or two dates for one action: if a later line corrects the first, use the correction. If not, write "Unsettled" in that cell.
- No owner, only a tentative one ("Priya?"), or only "someone should": Owner is "Unassigned". No date: Due is "Not stated". Never turn a suggestion into an assignment.
- Exact relative dates ("tomorrow", "by Friday" said earlier in that week): convert them using the meeting date and keep the words, e.g. "Fri 16 Oct 2026 (by Friday)". Vague or ambiguous ones ("soon", "ASAP", "early next week", "next Friday", or a weekday that falls on the meeting day): pick a sensible date and mark it "(suggested)".
- Names: an owner must be in the people list. Match a first name, nickname or initials only when it fits exactly one person. A name that fits nobody or several people is never an owner.
- Transcripts: a speaker label shows who spoke, not who owns the work; the owner is whoever agreed or was asked. Match generic labels ("Speaker 2") to a person only when the transcript makes it clear, for example by addressing them by name. Skip small talk.
- Long notes: work through all of it, topic by topic. If space runs short, shorten wording, never drop rows.

## 4. Steps
1. Read all the notes, then list every candidate decision, action, risk and question with its source.
2. Apply the edge cases in part 3, then convert dates using the meeting date.
3. Sort and number the actions as part 6 says.
4. For each action, fill Depends on. If an action is due before the action it waits on, add that to Risks and blockers.
5. Set each priority, write the output, then run the self-check.

## 5. Rules
- Use only names from the people list. Never invent a person, a decision or a commitment. The only dates you may supply are those marked "(suggested)" under the date and next-meeting rules.
- Start each action with a verb and keep it under 15 words.
- Source: the timestamp if the notes have one, otherwise a quote of at most 10 words.
- Priority: High if called urgent (including "ASAP"), if another row's Depends on names it, or if its stated or converted (not suggested) due date is within 3 working days of the meeting. Low if called optional or nice to have. Otherwise Medium.
- Write every date with its weekday, as in "Fri 16 Oct 2026", unless there is no meeting date (part 2 says what to do then).
- Write for someone who missed the meeting: spell out the notes' shorthand and abbreviations. Tone of the recap: {{tone}}.

## 6. Output
Use these sections in this order. Write "None" under any that is empty.
1. Header: meeting name, date and who was there (add "from the notes, please confirm" if no people list was given), then 2–3 sentences on what was settled and what is still open.
2. Decisions: numbered, one line each, final versions only.
3. Actions: a table with the columns # | Action | Owner | Due | Priority | Depends on | Source. Every action gets exactly one row, including those also listed in section 4. Order: rows with a date, stated or suggested, in date order; then "Not stated" and "Unsettled" rows, in the order they came up. Number the rows 1, 2, 3 in that final order. Depends on holds the # of the row it waits on, a named outside item, or "—".
4. Needs an owner or a date: each row whose Owner or Due is "Unassigned", "Not stated" or "Unsettled", once, by its #, saying what is missing and any options or proposed names the notes give.
5. Names to check: each name, once, that is not in the people list or fits more than one person.
6. Risks and blockers: one line each, with the action or decision number it affects and who raised it, if stated.
7. Open questions: one bullet each, with who could answer it, or "unclear who".
8. Next meeting: the date if one was set. If not, write "Not set", and if the meeting clearly recurs (for example weekly), add the next usual date marked "(suggested)". Then the carry-overs: parked items, open questions, and actions due before then that need a report back.
9. Recap email, ready to send:
   - Subject: the meeting name, the date, and "decisions and actions".
   - To: the recipients above. If they say everyone or all attendees, list the people in the meeting by name only, with no email addresses.
   - Body, at most 200 words: one opening line; the decisions in brief; "What we need from each of you", with one line per person listing their actions and due dates; a request for an owner or date for each item in section 4; the next meeting. If it runs over, shorten the decisions first, never the asks. End with "Thanks," and no name.

## 7. Self-check
Before replying, check each of these and fix any failure:
- Every action has exactly one row in the table, with a Source that matches the notes.
- Every row has one owner from the people list and one due date, or is listed in section 4.
- No decision appears in both an earlier and a final version, and no action belongs to an abandoned option.
- Every converted date has the right weekday, and every vague date is marked "(suggested)" (unless there is no meeting date, then it stays in the notes' own words).
- The rows follow the sort order, and every Depends on number points to the right row.
- Every action due before the action it waits on is listed under Risks and blockers.
- Every priority follows the priority rule.
- The email has a subject, a To line, a line for every person with an action, and the next meeting.
Then reply with the output only, ending with one line: "Checked: <n> actions, <n> decisions, <n> flagged." Flagged is the number of entries in sections 4 and 5; each entry appears once, so it counts once.

## 8. Setup
Works as one paste in any chat app, with no tools or plugins. If your notes are a file, or a transcript too long to paste, attach it and write "see attached" in the Notes block.
Community experience

Reader reviews

Ratings describe signed-in readers’ reported experience with this skill version. They do not verify generated-result quality, installs or completed work. Names and task details are not published.

Loading reviews…

Sign in to submit, report or manage a public review. Browsing and using skills stays free of account requirements.

Report a problem privately
Help improve this skill

How did it go?

Send only this skill’s version, the step and your verdict. No task details, prompts or results are sent. These reports guide editorial review; they are not public ratings.

FAQ

What do I need before using this recipe?

Bring Your notes or transcript. Read any conditional requirements and the complete input list below.

How do I check the DOC result?

Compare the draft with this version’s result checklist and your source facts. Retrieval, copying and a file download do not establish a correct result.

How do I start?

Copy the prompt and paste it into your assistant. Answer the questions there. Your assistant creates the result; review it before using it.

Do I need an account or an MCP connection?

No account or MCP connection is needed to copy. Connect LazyCoder to Claude once if you prefer retrieval.

Where do my details go?

Give task details to your chosen assistant. Optional preparation here stays on this device; the MCP starter contains public skill identity only.