# Operations Meeting Decision Capture > Converts a meeting transcript or set of notes into three separated lists — decisions made (with who decided and on what basis), actions with a named owner and a date, and open questions — applying one hard rule: an item with no named owner or no date is recorded as an unresolved discussion, never promoted into a decision or an action with an invented owner. Use after a meeting, a workshop, a steering committee or a stand-up when the notes need turning into something trackable, when 'what did we actually agree' is being asked, or when last meeting's actions need checking before the next one. Trigger on 'capture the decisions', 'turn these notes into actions', 'what did we agree', 'meeting minutes', 'action items from this call', 'who owns what after that meeting'. Not for writing the recurring project status report that these actions feed (use operations-project-status-report if present, otherwise the project owner) and not for recording an architectural or technical choice with its options and consequences (u - Skill: `alihusains/operations-meeting-decision-capture` (Agent Skill) - Install (CLI): `npx skillmds@latest add alihusains/operations-meeting-decision-capture` - Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/operations-meeting-decision-capture/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: alihusains (https://skillmd.com/u/alihusains) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alihusains/operations-meeting-decision-capture --- # Meeting decision capture ## Purpose The failure is not that meetings go unrecorded — it is that summaries are generous. A discussion where three people nodded becomes "agreed: migrate in Q3". An action nobody accepted gets attributed to whoever spoke last. Six weeks later the owner has never heard of it and the decision is relitigated from scratch. This skill separates what was actually decided from what was merely discussed, and refuses to manufacture the owner or the date that would make an item look finished. ## The rule that does the work **A decision without a named decider is a discussion. An action without a named owner and a date is a discussion.** When either is missing, the item goes in the open-questions list with the specific gap stated — `no owner named`, `no date agreed`, `no decision reached` — and, where useful, the sentence that would close it. Do not infer the owner from who raised the topic, who is most senior, who owns the adjacent system, or who has done it before. Every one of those inferences is reasonable and every one of them produces an action that never happens. The value here is entirely in the refusal. A model asked to summarise a meeting will produce a confident action list unprompted; producing the list is not the skill, declining to invent the missing half of it is. ## Prerequisites - **Inputs:** the transcript, recording notes, or written notes. Speaker attribution materially improves the output — without it, decisions can be captured but deciders and owners usually cannot, and most items will correctly land in open questions. - **Inputs:** the meeting's date, its purpose, and who attended. A date is needed because "by end of week" is meaningless without it. - **Inputs (if checking follow-through):** the previous meeting's action list. - **Inputs (useful):** the decision rights in play — who is entitled to decide what. Without it, note who stated the decision rather than asserting authority. If notes were not supplied, stop. Do not reconstruct a meeting from a calendar invite, an agenda or a topic. An agenda records what was intended to be discussed, which is not evidence of anything that was said. ## Data handling Classification: **Internal** by default, and higher where the subject is. Meetings covering individuals' performance, pay, disciplinary matters, redundancies, customer or client specifics, unpublished financials, legal advice or an investigation take the classification of their subject and a restricted distribution list. If personal data, client positions or account identifiers appear in a transcript, flag it and exclude those specifics from the circulated record — the decision can be recorded without the underlying record. Two further constraints. Do not attribute a view or a quote to a named person unless the notes support it. And if a meeting was recorded, check that the participants knew. ## Procedure ### 1. Sort every item into one of four buckets before writing anything | Bucket | Test | If the test fails | | --- | --- | --- | | Decision | A choice was stated as settled, by someone identifiable, and nobody reopened it | Open question, marked `discussed, not decided` | | Action | A specific piece of work, accepted by a named person, with a date | Open question, marked with the missing element | | Open question | Raised and unresolved, or an item that failed one of the tests above | — | | Context | Information shared, no choice and no work arising | Keep brief; this is where summaries bloat | An item may fail on one element only. "Priya will draft the proposal" with no date is an open question with the owner already known — record it as `owner: Priya · NO DATE AGREED`, so the gap is one message away from closing, not a re-run of the meeting. ### 2. Record each decision with what it needs to survive **What was decided · who decided it · the date · what it supersedes, if anything · the basis or the one or two alternatives rejected · what it commits (money, scope, timeline, headcount) · who must be told.** The rejected alternative is what stops the decision being reopened by someone who was not in the room, and it is the field most often dropped. If no alternative was discussed, say so — a decision with no considered alternative is a real signal. Where a decision was stated by someone who may not hold the decision right, record it as `stated by X · confirmation required from the decision owner`. Do not silently upgrade it, and do not quietly discard it either. ### 3. Record each action in the fixed shape **Owner (a named person, never a team or a function) · the deliverable, stated as something a third party could verify was done · the date, as an actual date · what it depends on · where it is tracked.** "The team will look into it" is not an action. Neither is "improve reporting". If the deliverable cannot be verified as done by someone who was not in the meeting, sharpen it or move it to open questions. A team name in the owner field is the single most common way an action dies. If only a team was named, record `team: X · INDIVIDUAL OWNER NOT NAMED` and put it in open questions. ### 4. Record open questions so they are answerable, not just listed Each one: the question · why it is open (no owner, no date, no authority present, missing information, disagreement) · who could resolve it · by when it needs resolving. An open-questions list with no route to closure is a list of the meeting's failures, and it will be identical after the next one. ### 5. Check the previous action list, if supplied Mark each prior action done, in progress with a revised date, blocked with the blocker named, or not started. An action carried forward three times without a changed date is a signal about capacity or ownership — surface it rather than rolling it silently a fourth time. ### 6. Assemble and circulate in this order 1. Decisions. 2. Actions — owner, deliverable, date. 3. Open questions, each with the specific gap. 4. Previous actions, with status. 5. Context, kept short. Circulate to attendees **and** to everyone named as an owner or affected by a decision, whether or not they were in the room — an owner discovering their action in a status report a month later is a process failure, not an individual one. ### 7. Self-check before sending Does every decision have a named decider? Does every action have a named individual and a real date? Has anything been promoted from discussion to decision by the way it is worded — "agreed", "confirmed", "it was decided" — where the notes do not actually support it? Is any owner an inference? If yes to the last two, move it back. ## Boundaries - **Not for** the recurring project or programme status report these actions feed into; that belongs with the project owner and its own reporting cycle. - **Not for** recording a technical or architectural choice with its options, trade-offs and consequences — that is `engineering-decision-record`, which this routes to when a meeting settles one. - **Not for** documenting a repeatable process the meeting described — that is `operations-sop-authoring`; map it first with `operations-process-mapping` if the process is not yet understood. - **Not for** an incident review, which needs a timeline and contributing factors rather than a decision list — that is `engineering-incident-postmortem`. - **Not for** performance conversations, which are `hr-performance-review-coaching` and must not be circulated as minutes. - **Not for** producing a full narrative transcript summary. Decisions, actions and open questions are the deliverable; everything else is context and should be short. ## Hand-offs - **Receives from:** the transcript or notes, and the previous meeting's action list. - **Routes to:** `engineering-decision-record` when a technical decision was made and needs its options and consequences documented properly. - **Routes to:** `operations-sop-authoring` when an action is "write down how we do this". - **Routes to:** `product-roadmap-communication` when a decision changes scope, sequence or dates that others are planning against. - **Routes to:** `legal-compliance-obligation-extraction` when a decision commits the organisation under an agreement whose duties are not yet registered. - **Escalates to:** the meeting chair when a decision was recorded by someone without the decision right, or when the same open question survives three consecutive meetings.