--- name: meeting-follow-through description: Turn a recorded meeting into a numbered, receipted inventory of everything that was actually asked for, get it approved, and draft the recap, the email and the CRM update from the approved list only. Reads the verbatim transcript and refuses to run on a recorder summary. Every item carries a quote and the point in the call where it was said. Fails loudly when no transcript can be retrieved. --- # Meeting follow-through Six steps, and only one of them is a person. ``` 1. The call gets recorded. 2. The recorder produces a verbatim transcript. 3. The transcript becomes a numbered inventory, every line carrying its own quote. 4. You approve the inventory. <-- the only human step 5. The approved list drafts the recap, the email and the CRM update. 6. Those go out. ``` Steps 1 and 2 belong to your recorder. This skill owns 3 through 6. The approval step is the whole point. Everything before it is retrieval and everything after it is distribution, and neither of those is where the judgment lives. ## Three rules These are not preferences. Each one exists because breaking it has a known cost. 1. **The transcript is the only thing we write from.** The recorder's summary is fine for remembering that a call happened. It is not allowed to be the source. 2. **Every item has to quote itself.** If this skill claims someone asked for something, it shows the words and where they were said. An ask that cannot produce its own quote does not go on the list. It gets flagged instead, which is a different thing from disappearing quietly. 3. **It fails loudly.** When the transcript cannot be retrieved, the work stops and says so. It does not fall back to the summary because the summary happened to be right there. ### Why rule 1 is absolute A client specified a deliverable in a recorded call: a test set of ten items. The transcript captured it correctly. The AI summary dropped it. Every downstream document was built from the summary, so the spec reached zero deliverables. He asked a second time four days later, got zero again, and ended the engagement that day. The transcript had been sitting complete and correct the entire time and nothing ever read it. That is the failure this skill exists to prevent. It is why there is no override flag below. --- ## Step 3 · Build the inventory ### 3a. Get a real transcript. Walk the ladder. Stop at the first rung that yields substantive text. 1. **Already saved.** A transcript file you have already stored for this meeting. If the file has only a summary section, that is not a transcript. Keep walking. 2. **The recorder's transcript call.** Whatever your recorder exposes for retrieving the verbatim transcript, as opposed to its notes or highlights. 3. **Copy and paste from the app.** Open the recording in the recorder's desktop or web app, select the transcript, paste it in. This rung is faithful: a pasted transcript compared against the same meeting pulled programmatically matched exactly. 4. **Export or download.** Whatever file the recorder will hand over. 5. **Stop.** Report that no transcript could be obtained, name which rungs were tried and what each returned, and go to "Fail closed" below. **A paywall, a permissions error, or a 404 on rung 2 does not mean unavailable.** It means go to rung 3. **Hard refusal.** If the only available text is a recorder summary, an AI notes panel, highlights, auto-extracted action items, or an earlier AI-written summary, this skill does not run. Say so plainly and stop. There is no override. ### 3b. Check it is really a transcript - More than one speaker appears, or the meeting genuinely had one speaker. - The length is plausible for the meeting's duration. A four-line body for a 45-minute call is a partial capture. Flag it and keep walking the ladder. - If it looks truncated (ends mid-sentence, no closing exchange), mark coverage as PARTIAL and say which end is missing. ### 3c. Extract, by category Read the transcript start to finish. Extract into these categories. The categories are the point: the ones that cost the most are the ones a plain to-do list has no shape for. | Tag | What it captures | |---|---| | `ASK` | A deliverable requested. Capture quantity, format, medium and orientation whenever stated. | | `SPEC` | A technical or design constraint on the thing being built. | | `PRIORITY` | Them explicitly ranking something. "The number one thing." | | `OBJECTION` | A grievance, doubt or complaint, including about work already delivered. | | `OFFER` | Something they offered: money, time, scope, more work. Record whether it was accepted, declined, or left open. | | `CONSTRAINT` | Budget ceiling, deadline, hard no, tooling limit. | | `COMMITMENT` | Who owes what, by when. Both directions, yours and theirs. | | `OPEN` | A question raised and not settled in the call. | | `DECISION` | Something actually settled in the call. | | `RISK` | A stated fear, or a prior bad experience they are pattern-matching against. | Every item gets this shape: ``` - [ ] `` **** Quote: "" Where: line , or timestamp Quantity/format: Status: Repeats: ``` **Rules of extraction.** - **Verbatim or nothing.** The quote is their actual words. Filler and stutters stay. If you cannot produce a quote, the item does not exist. Do not infer intent and file it as a requirement. - **Literal quantities.** "Ten" is ten. "One image, not a PDF" is one image and a ban on PDFs. Never turn a number into "several" or a format into "a sample". - **Both directions.** Your commitments and theirs. Your declines and theirs. - **A decline is an item.** When they offer and you say no, that is an `OFFER` with status declined and both quotes. This is the category everything else drops. - **Do not merge near-duplicates.** Two askings of the same thing are one item with `Repeats: 2`. Two different asks that sound similar stay separate. ### 3d. Rank it 1. Anything they said was the most important thing. 2. Everything with `Repeats: 2` or more, highest count first. 3. `ASK` and `SPEC` items carrying a literal quantity or a format ban. 4. Everything else, in the order it came up. **The repeat count is the highest-value signal here.** Someone who says the same thing five times is telling you what the decision turns on. ### 3e. Carry forward If you have inventories from earlier meetings with the same person, pull every item still marked open and put them at the top under "Carried forward, still unfulfilled", with the original date and quote. **An item asked twice and delivered zero times is a red flag, and it goes at the very top.** An item leaves this set only by being marked fulfilled, pointing at the thing that fulfilled it, or withdrawn, quoting them withdrawing it. Nothing ages out silently. ### Fail closed, and visibly If the ladder reached rung 5 and no transcript exists, write the file anyway with this as its first line: > **TRANSCRIPT ABSENT.** No verbatim transcript could be retrieved for this > meeting. Nothing below is receipted. Do not use this to write anything that > goes to the other party. List which rungs were tried and what each returned. Do not populate an inventory from memory or from a summary. An empty receipted file beats a full unreceipted one. --- ## Step 4 · The approval This is the step the whole skill exists for. You see the inventory **before** anything is composed from it. Present, in this order: 1. Carried-forward red flags first, each marked "asked N times, delivered zero". 2. The ranked inventory for this meeting, one line per item, quote included. 3. The coverage note, including anything flagged for having no quote. 4. Then the question: **"Anything missing or mis-read? Okay to proceed?"** Then stop and wait. You can correct any item, add one the pass missed, or strike one that does not belong. Apply those corrections to the file before anything downstream reads it. **Never skip this because the inventory looks clean.** The failure mode is a workflow deciding on your behalf that it captured enough. --- ## Step 5 · The drafts **The approved inventory is now the only admissible input.** Draft from the inventory, not from the transcript again, and never from the summary. Every line in every draft traces back to a line that was approved. Three outputs. Turn on the ones you actually use. - **The recap.** Renders from your recap template so it reads the same every time. The template is on the playbook page this skill came from. - **The email to attendees.** The same template as the body. A clean recap with the assigned tasks and any dated milestones. - **The CRM update.** The same approved lines, written into your record's own fields, so there is no template to render for it. Map the inventory onto the template like this: | Template section | Comes from | |---|---| | Summary | The `DECISION` items, in two or three sentences. | | Decisions | Every `DECISION`. | | Assigned tasks | Every `COMMITMENT`, with its owner and date. | | Milestones | Every `COMMITMENT` and `CONSTRAINT` carrying a date. | An `OBJECTION`, an `OPEN` question or a declined `OFFER` is yours to decide on. Surface it to the reviewer rather than dropping it into a client-facing recap on your own. --- ## Step 6 · The send **Draft only.** Do not write the record, post the recap, or send the email on its own. Show all three and wait. On approval the record saves, the recap posts, and the email lands in the drafts folder to be sent by a person. Nothing at this step invents anything. It is distribution of a list already signed off. --- ## When it breaks - **Only a summary is available.** Refuse. Say which rungs were tried. Do not run. - **The transcript is partial.** Run it, mark coverage PARTIAL, name the missing end, and say so when presenting. Do not silently work from half a call. - **Speaker labels are ambiguous.** Resolve from context and state the mapping in the coverage note. If it is genuinely unclear who asked for what, flag the item rather than guessing. Attributing your own words to the other party is the worst available error. - **A very long transcript.** Split the extraction into segments and merge them. The merge must preserve every item and never re-summarize. If the item count drops after a merge, that is a bug. - **Two triggers running at once.** If both a scheduled check and an instant trigger are live, every meeting gets processed twice. Run exactly one. --- ## Setting it up 1. Connect your meeting recorder so the transcript can be read. 2. Connect only the outputs you want: your CRM, your chat tool, your email. 3. Pick one trigger. A scheduled check a few times a day is the simpler default. An instant trigger is faster and has more moving parts. Never both. 4. Run it by hand on two real meetings and read the transcripts yourself before putting it on a schedule. Because the whole thing keys off the transcript rather than the recorder, you are not locked to one vendor. Switching recorders does not change anything downstream.