SKILL: Turn messy meeting notes into a RAG status report
Guided-build reference. This is the worked example everyone follows live in Block 2. If you build only one Skill today, build this one. It shows all three habits at once: describe the output first (Way #1), strip the data before you paste (Way #3), and catch the one thing the AI got wrong (Way #2).
1. Goal - what this Skill does, and when to use it
Turn raw, half-typed sync notes into a consistent Red/Amber/Green status report a stakeholder can read in 30 seconds. Use it every week, the moment the call ends, before the programme report is due.
It replaces 20 minutes of re-reading scrappy notes and trying to remember who agreed to what.
2. Inputs - what you paste in for it to work
- Input 1: the raw meeting notes (typos and all - the AI copes).
- Input 2: the project name you want at the top (a safe codename, not the real one).
PRIVACY CHECK (Way #3): before you paste, do these swaps. Treat the prompt like a postcard.
In the notes Replace with Why ”Maria Gonzalez” Person A Real name - no PII in the chatbot ”Brightwave Ltd” Vendor 1 Names a real supplier relationship ”480k (confidential)“ remove the whole line Marked confidential - leave it out ”dave” Person B (only if you genuinely know it’s a colleague) Real name Rule of thumb: real names → Person A/B, suppliers → Vendor 1, anything tagged confidential → delete it. When in doubt, leave it out.
3. Output - what “good” looks like (write this BEFORE the prompt)
A four-section status report:
| Section | Shape |
|---|---|
| Summary | 2–3 plain sentences a director can skim |
| Key decisions | bullet list, decisions only (not discussion) |
| Risks (RAG) | table: Risk | Rating (🔴 Red / 🟠 Amber / 🟢 Green) |
| Actions | table: Action | Owner | Due |
Max one page. Neutral, factual tone. Where the notes don’t say who owns something, the Owner must read TBC - never a guessed name.
4. Instructions / Prompt - the exact text to paste
You are helping me turn raw weekly meeting notes into a status report
for [PROJECT CODENAME].
Produce exactly four sections:
1. Summary - 2 to 3 sentences, plain English.
2. Key decisions - bullets, decisions only.
3. Risks - a table with columns: Risk | Rating. Rate each Red, Amber,
or Green. Red = blocked or slipping; Amber = at risk; Green = on track.
4. Actions - a table with columns: Action | Owner | Due.
Rules:
- If the notes do not clearly state an owner or a due date, write "TBC".
Do NOT guess, infer, or assign anyone you are not told about.
- If the notes mention an unresolved or "parked" question, list it as a
risk or open action - do not silently drop it.
- Keep it to one page. Neutral, factual tone. No filler.
Notes:
[PASTE ANONYMISED NOTES HERE]The anti-guessing line in Rules is the whole point - it’s what makes the AI write TBC instead of confidently inventing an owner.
5. Worked Example - one real run, anonymised
Input (anonymised - note Maria → Person A, Brightwave → Vendor 1, budget line deleted):
Project Helix weekly sync. Launch pencilled end of month, looking shaky - Person A flagged Vendor 1 integration slipping, second week running, thinks we push. Agreed: push launch one week, confirm with stakeholders. QA sign-off NOT done - blocker, someone to chase QA lead this week. Data migration over weekend went ok, no rollback. Open question: legal review for new terms copy - nobody sure, parked. Person A to send revised plan. dave picking up vendor chase i think? not 100% sure who owns that. Marketing wants assets Thurs, haven’t told them about the slip. Someone said analytics dashboard showing wrong numbers again, ran out of time.
Output it produced:
Status report - Project Helix
Summary Launch is slipping and the team has agreed to push it by one week, pending stakeholder confirmation. QA sign-off is the live blocker. Data migration completed successfully over the weekend.
Key decisions
- Push launch by one week (to be confirmed with stakeholders).
- No rollback needed after the weekend data migration.
Risks
Risk Rating Vendor 1 integration slipping - second week running 🔴 Red QA sign-off not done - blocker 🔴 Red Marketing not yet told about the slip; assets expected Thursday 🟠 Amber Legal review for new terms copy - unresolved, parked 🟠 Amber Analytics dashboard reporting wrong numbers - unverified 🟠 Amber Actions
Action Owner Due Confirm one-week slip with stakeholders TBC This week Chase QA lead for sign-off TBC This week Send revised plan Person A TBC Chase Vendor 1 integration TBC TBC Tell Marketing about the slip TBC Before Thursday The catch (Way #2): the vendor-chase owner came back as TBC - exactly right, because the notes only said “dave picking up the vendor chase i think? not 100% sure.” A lazier prompt drops the anti-guessing rule and the AI writes “Dave” with full confidence. That fake certainty is the trap. Also notice the analytics dashboard issue survived into the risk list - a quick “summarise this” prompt usually loses it because it was the throwaway last line. Two things to verify by eye every week: owners and anything that nearly got dropped.
6. Guardrails - how to stay safe and sane
- Privacy (Way #3): never paste real names, supplier names, or any figure marked confidential (the 480k line). Anonymise first, every time.
- Human check (Way #2): before you send it on, read the Owner column and the Risks list. AI invents owners and quietly loses the last bullet of messy notes. You sign it - so you own those two checks.
- Limits: this summarises what’s in the notes. It can’t tell you whether a Red should actually be a different colour, or fill gaps the meeting never resolved. Garbage in, confident garbage out.
7. Reuse notes - so it isn’t lost
- Owner: (your name)
- Last updated: (date)
- Lives in: team SharePoint → “Programme reporting” → Skills (so the next PM reuses it instead of rebuilding it - Way #5).
Built at Innovation Day. The five ways of working: ways-of-working.md.
Downloads for this session
Grab the templates and sample files used here.