# Meeting Minutes > Turn a meeting transcript into minutes people act on: decisions separated from the actions that execute them, risks separated from the assumptions the room has settled on, backlog candidates held to an admission test, and a sensitive-content filter run before anything is drafted. Includes a verification pass against the transcript that catches invented product names. Use when the user says 'minutes', 'meeting minutes', 'write up this meeting', 'weekly', or provides a transcript (.vtt, .docx, .odt, .txt) and asks for a write-up. - Skill: `romain-nicod/meeting-minutes` (Agent Skill) - Install (CLI): `npx skillmds@latest add romain-nicod/meeting-minutes` - Raw SKILL.md: https://api.skillmd.com/api/skills/romain-nicod/meeting-minutes/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: romain-nicod (https://skillmd.com/u/romain-nicod) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/romain-nicod/meeting-minutes --- # Meeting minutes Minutes that survive contact with the people who were in the room. Most write-ups fail the same three ways: they file an action as a decision, they call a settled limitation a risk, and they quietly replace a garbled transcription with a product name that was never said. Each has its own gate below. --- ## Step 0: establish the setting Ask once, at the first run, and record the answers in this file's conventions section so they are never asked twice. 1. **Who is in the room, and on which side?** A recurring meeting usually has two or more parties: a client and a supplier, two departments, a steering group. Name them, and list the participants under each. 2. **Who has authority to decide?** Name the person or party. This single answer drives the decision gate below, and getting it wrong turns a supplier's proposal into a client decision. 3. **What is the naming convention for people?** For example `FirstName L.` everywhere, with full names in the attendee block only. Pick one and it applies in prose and in tables alike. 4. **Language, time zone, meeting cadence, filename convention.** 5. **Does the user want a private briefing alongside the minutes?** Some readers want a second, unshared document holding the analysis and the sensitive material. If yes, ask where it goes and in what language. 6. **Is the user a participant?** If so, they are named like everyone else in the minutes. See the naming rule below, which exists because this is the mistake that gets made every time. Until these are answered, do not draft. Minutes written on guessed authority have to be rewritten. --- ## The reader-first principle Minutes are read top to bottom by people who do not know which section they are in when they hit a given line. Every line has to be understandable without reading ahead. - **No forward references.** Never point from item N to item N+k. If item N depends on a later one, reorder them. - **Decisions come before the actions that execute them.** - **A gating action comes before the action it gates.** - **One naming format, applied everywhere**, including inside tables. A document that writes someone's initials in one row and their full name in the next has two conventions and no reader. - **The user is a participant, named like everyone else.** When the person commissioning the minutes was in the room, refer to them by name throughout: in actions, in notes, in prose. Never by a role label such as "the project manager". A role label belongs to a document the user *authored* about their own role. Minutes *record* them acting alongside named others, and labelling only one participant by role creates an asymmetry and an unresolved referent. The test: is this document written by them about their role, or does it record them acting among others? - **Verify before settling for incomplete data.** If a surname is missing, look it up in the available material before defaulting to a first name alone. --- ## Output structure Five sections, in this order. ### 1. Decisions taken Table: number, decision, decided by, timestamp. Only what was explicitly confirmed during the meeting. **Decision or action.** A decision closes a loop: "we have resolved that X". An action executes work. "Escalate to Y", "propose to Z", "send the note to W" are actions: they have an owner and an execution verb. A decision has no execution owner, it states the resolved choice. A line that starts with an action verb and names an owner belongs in section 2. **The authority test.** A decision is taken by the party with authority over the matter, named in step 0. Two consequences: - A **technical or implementation choice announced by a supplier** is that supplier communicating an approach. It is not the client's decision. It belongs in the narrative notes, or in section 3 as an assumption or a dependency, unless the deciding party explicitly accepts it and thereby closes the loop. In that case the decision is "the client accepted X", and the decider is the person who said so. Verify that acceptance verbatim before asserting it. - **Endorsed future work** ("we agree that is the right direction, once the refactoring is done") is an action. It has an owner and a horizon. It goes in section 2. For every candidate decision, ask: who pronounced it, and are they the party with authority to decide it? If the answer is a supplier on an execution matter, it is not a decision. Negative decisions belong here too. Deciding not to do something yet, or to hold pending something else, closes a loop. Anything that is neither a loop-closing decision nor an owned action is narrative. It lives in the prose, never in a table. ### 2. Actions Table: number, title, description, owner, due, timestamp, whether it lands before the next meeting. - **One action per interaction.** One person, one touchpoint, one counterpart is one action, however many topics it covers. - **No carry-forwards.** Only actions discussed in this meeting appear. A topic not raised does not appear, even if it was an open action last time. - If a previously assigned action was discussed, capture its current state as a fresh action, without labelling it a carry-forward. - **Owner** is whoever committed to act. When it is ambiguous, pair the person who expressed the need with the person who showed an engagement signal. - **Run a dependency pass** after the chronological one. If person A expressed a need and person B signalled engagement, that is an action, even when B's verbal marker is weak. Reading each line in isolation misses these relational chains, and they are usually the actions that matter. ### 3. Risks, assumptions and dependencies Table: category, description, impact, likelihood, mitigation and owner, timestamp. Three different things live here. Sort each candidate before placing it: - **Risk**: a forward-looking exposure with real uncertainty and a possible adverse outcome. It carries a mitigation. - **Assumption**: a state of the world the parties have accepted and are proceeding on, with no live attempt to change it. Phrase it as an accepted premise. "It is accepted that embedded images are not extracted, and users are guided accordingly." - **Dependency**: B cannot proceed until A is done. Name both ends and the gating action. **The sorting rule.** Before writing a row, ask whether the group is *acting against* this uncertainty, which makes it a risk with a mitigation, or *living with* it as a settled premise, which makes it an assumption. An accepted limitation, reported without alarm and with no corrective action against the limitation itself, is an assumption. Filing it as a risk manufactures alarm nobody in the room felt, and it tells the reader you misread it. Tag each row with its category, then a sub-tag: technical, operational, strategic, financial, scheduling. Every risk carries a mitigation. When none was discussed, write "none identified", which is itself a finding. A confirmed event with known handling is a fact, not a risk: it belongs in the prose. Someone being away next week is handled in the actions. A meeting falling on a public holiday is a fact, so reschedule it. An event that already happened and was resolved is not a risk. One that happened and is unresolved is framed as recurrence until the fix lands, linked to its action. ### 4. Backlog candidates Items raised as feature, governance or infrastructure candidates. They are not committed actions, they are ideas that need shortlisting before entering a backlog. **The admission test is strict.** A candidate has to change or structure the product itself, its infrastructure, or its delivery process. These are **not** candidates and belong in the actions or the prose: - Communication activities: demos, presentations, walkthroughs - Engagement activities: stakeholder meetings, workshops - Coordination: escalation, arbitration, follow-up loops - Training and onboarding sessions - Project-management deliverables: notes, memos, status updates The candidates table is not the bucket for "raised but not yet allocated". Everything that fails the test goes somewhere specific. In the minutes, summarise: number, title, description, raised by, timestamp. The full user stories go in the standalone candidates file, which the `backlog-scanner` skill produces. ### 5. Narrative notes Prose organised by topic block, with timestamp ranges, for reference and knowledge management. Open with a line saying the notes are for reference only and were compiled with AI support. **The topic consolidation pass, run before writing any prose.** A subject gets opened, deferred, and reopened at scattered timestamps. Before writing, scan the whole transcript and gather every fragment of each subject into one coherent block that follows its logical arc (raised, deferred, answered, refined), rather than the chronological order of the recording. The block records where the subject landed, listing all its timestamps. The recurring failure is treating each mention in isolation and producing four thin notes that look contradictory, on what was actually one thread that resolved. The test: for each subject, can a reader see the whole arc without hopping between blocks? --- ## The sensitive-content filter Flag and exclude by default anything in these categories, and surface the flagged list to the user **before** drafting. 1. **Personal behaviour, hours, access.** After-hours activity, individual workflow choices, access incidents tied to a named person. 2. **Commentary on absent parties.** Other departments, senior management, anyone not in the room. This includes positive commentary in a shared document. 3. **Budget, billing and scope tension** named in the meeting. 4. **Criticism of an individual's work**, and any mapping of one stakeholder's preferences against another's. 5. **Jokes, asides and teasing.** Drop the verbatim, keep any substance underneath. 6. **Sensitive personnel topics.** Departures, capacity worries, individual availability framed personally. Reframe as "unavailable owing to X" rather than naming a personal reason. 7. **Self-deprecation by the user.** Keep the substance of what they said, drop the framing. 8. **Anything that would embarrass a named participant** if put in writing and forwarded. Sensitive material belongs in the private briefing, when the user has asked for one. Contractual and commercial terms stay out unless the user says otherwise. --- ## The pre-draft arbitration gate Before drafting, surface one consolidated list for the user to arbitrate, and wait for their answers. 1. **Sensitive-content flags.** Every item triggering a category above: timestamp, verbatim, recommended handling (exclude, reformulate, keep). 2. **Ambiguous attributions.** Every line where the speaker cannot be uniquely identified, which is constant when participants share a meeting account. Give the timestamp, the verbatim, your hypothesis, and the question. 3. **Proper nouns and tool names.** Every term not obviously known: the spelling in the transcript, the likely correct spelling, and a request to confirm. 4. **Open decisions.** Items that look like decisions but where confirmation is ambiguous, such as one party leaving before validating. 5. **Forward-looking signals**, if the horizon pass is in use. --- ## Post-production verification Before delivering, run a verification pass against the transcript. 1. **Extract** every proper noun, tool name, product name and acronym from the draft. 2. **Search each one** in the source transcript for an exact or phonetically close match. 3. **Flag, visibly in the conversation**, every term with no direct match: the term as written, the closest verbatim with its timestamp, and how many times it appears in the draft. 4. **Do not deliver** until the user has resolved every flag. This catches the unconscious substitution where a garbled transcription gets replaced with a real product name that resembles it. It happens without any awareness that a substitution occurred, which is exactly why the check has to be explicit rather than silent. --- ## The horizon pass Recurring meetings drift into forward-looking discussion, usually near the end. That material is an unsolicited elicitation of implicit strategy, and it is the part nobody writes down. **What it captures.** Statements that project forward rather than report status, in exactly one of three classes: - **Interest**: what the room would like the thing to become. - **Concern**: what it fears, before anything is formalised. - **Specificity**: a structural constraint that makes this programme's reading of the world non-generic. **What it is not.** Not decisions, not actions, not backlog candidates. A theme that later crystallises into an arbitrable capability may pass the admission test and become a candidate. That is a decision someone takes, never an inference. **Where it lives.** One living register file, outside the shared documents, in the location given in step 0. It keeps internal names and is never quoted in anything distributed. **Procedure.** 1. **Load** the register. If it cannot be read, stop and say so. Never start a fresh register over an existing one. 2. **Detect** forward-looking statements across the whole transcript, not only the closing minutes. 3. **Merge rather than append.** An existing theme updates its last-seen date and its counter. Only a genuinely new theme adds a row. 4. **Surface the delta** in the arbitration gate, so the user validates that the signal is real and correctly classified. 5. **Write back in place**, with targeted replacement. Never delete and recreate the file: a failed pass must not destroy weeks of accumulation. **Accumulation discipline.** One occurrence is not a trend. Recurrence, tracked by first-seen, last-seen and a counter, is what separates signal from a one-off. Never infer a causal link between two statements just because they were said near each other. **Security carve-out.** A security or network incident surfaced in the meeting is routed through the appropriate channel. It may be recorded in the register with its routing. It never enters the shared minutes or any distributed document. --- ## Companion documents **The private briefing**, when the user wants one. An analytical document, never shared with participants, holding the sensitive material from the filter and the analysis that does not belong in minutes. Its mandatory section is **blind spots**. Beyond analysing what was said, scan the transcript for what the room *missed*: factual errors stated and left unchallenged, claims accepted without scrutiny, and angles nobody surfaced. This is the value only an outside reader brings, since participants cannot see their own blind spots. Run it every time, rather than only when an error is obvious. - **Verify before asserting a blind spot.** If it is a factual or technical claim, confirm it against a primary source before writing that a participant was wrong. Quote their verbatim with its timestamp, then the corrected fact with its source. - For each one, state the **practical consequence**, meaning which decision or action it distorts, and a **non-confronting way to raise it**. A supplier's technical error is raised by building on what they said, never by correcting them in public. - Families worth checking every time: unchallenged technical claims; scope accepted without definition, such as "we accept 90%" with nobody naming the deferred 10%; single points of failure mentioned but not drawn out; cost dimensions absent from a budget discussion; second-order impacts on people who were not in the room. **Analyse the user's own contributions with the same depth.** When the person commissioning the briefing was in the room, the briefing covers what they said, how it landed, what it brought, whether the response actually addressed it or evacuated it on an adjacent axis, and whether they undersold it. Treating the briefing as analyse-everyone-else leaves the most useful material on the table. Specifically capture: - Substantive proposals they made, and how they were received. - Rhetorical choices, including self-deprecation and framing devices: what they accomplished in the room, what they would cost in writing, and what to say instead with a different audience. - Ownership signals. When one of their ideas was picked up by someone else without attribution, flag it as something to manage before the next decision point. **Backlog candidates**: the standalone file, from `backlog-scanner`. **Stakeholder emails**: one file per recipient. --- ## Before delivering, list the companions Produce a single block naming every companion document and its status: ``` Companion documents: - Minutes: produced - Private briefing: produced / declined by the user - Backlog candidates: produced / declined by the user - Stakeholder emails: produced / not applicable ``` A "declined" status requires the user's own words. Nothing declines itself by default: if the user has not decided, the companion is produced. **Renumber and verify.** Whenever an item is removed or reordered in any table, scan every cross-reference in the document, including mitigations pointing at "action 4" and prose citing an item number, and update them. Then read the document through once more. A stale reference to a removed item breaks the document silently, and the reader is the one who finds it.