1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
#+TITLE: Meeting-Prep Workflow
#+AUTHOR: Craig Jennings & Claude
#+DATE: 2026-06-10
* Overview
Build a focused prep doc for a specific upcoming meeting so Craig walks in knowing what the meeting is, what the other side wants, what he wants to settle, the positions he can state without relitigating, and the data he might be asked about. The doc lives in =working/<slug>-call-prep/= during the lead-up and stays as the meeting's record afterward (notes + the action items it produced).
This is the per-meeting companion to =daily-prep.org=. Daily-prep is morning rounds across the whole day; meeting-prep is the deep prep for one meeting that warrants it. The two are wired: daily-prep links to an existing call-prep doc when the prep day has one, and meeting-prep links forward into the day's daily-prep when the meeting falls on a prepped day.
* Problem We're Solving
High-stakes or substance-heavy meetings go better with preparation, and Craig prefers detailed prep before them. Without a formal workflow the prep is ad hoc: it gets done from memory, the relevant prior context (past calls, the data under discussion, decisions already locked) isn't pulled together, and the same questions get re-derived live. Worse, the action items a meeting produces often never get captured — the gap that appears when a filed transcript carries committed deliverables that never become tasks.
A repeatable workflow makes the prep thorough and consistent, keeps every prep artifact in one discoverable place, and closes the loop by folding the meeting's action items back into =todo.org=.
* Exit Criteria
The prep is done when:
1. A prep doc exists at =working/<slug>-call-prep/<YYYY-MM-DD>-<slug>.org= with the section set below filled to the extent the available context allows.
2. Every section that can be grounded in real context (calendar, prior transcripts, =todo.org=, the project's issue tracker, the project's notes) is grounded — not invented. Gaps Craig must fill are named explicitly rather than guessed.
3. Craig has reviewed it and confirmed nothing's missing (his read of the other side's asks, his hold positions, the data he expects to be pressed on).
4. If the meeting falls on a day with a daily-prep doc, the prep doc is linked from that day's prep.
Post-meeting, the loop is closed when the meeting's action items have been extracted into =todo.org= (see Phase 6).
* When to Use This Workflow
Trigger when a specific meeting warrants more than a glance:
- Craig says "let's prep for the <X> meeting", "prep me for the call with <Y>", "build a prep doc for <meeting>", "let's run the meeting-prep workflow".
- Daily-prep surfaces a prep-day meeting that has real substance (an external partner, a negotiation, a review of specific data/work, a first call with someone) and no prep doc yet — offer to run this.
Don't use it for routine recurring ceremonies (standup, iteration review) unless Craig is presenting something specific. Those are covered by the daily-prep standup brief and the retro-prep step.
Distinct from:
- =daily-prep.org= — the whole-day brief; meeting-prep is one meeting deep.
- =process-meeting-transcript.org= — the *post*-meeting record (recording → transcript → archive). Meeting-prep's Phase 6 hands off to it / consumes its output for action-item extraction.
* Approach: How We Work Together
** Phase 0 — Identify the meeting and confirm it warrants prep
Establish which meeting and pull its calendar event:
#+begin_src text
mcp__google-calendar__list-events account="work" (and/or "personal"), the day in question
#+end_src
From the event capture: title, date/time (render in PT/CT/ET per Craig's three-timezone convention when sharing times), duration, organizer, attendee list with response status, location/medium (conferenceData), and any agenda link in the description. If the meeting clearly doesn't warrant a full prep doc (a routine ceremony, a quick sync), say so and offer the lighter touch instead.
*Read the meeting, and gate it.* For most of Craig's meetings the title and agenda are already known, so the heavy "decode an ambiguous invite" pass isn't needed here — the four-question diagnostic below lives better in the *daily-prep* calendar scan, as a quick read of each upcoming meeting. What this phase always applies is the gate: *is there a purpose here for Craig?* "He was invited" is not, by itself, a reason to attend — if there's no objective for him and no contribution to make, the right output is "decline / send regrets," not a prep doc.
For a genuinely ambiguous invite (vague title, no agenda, not a standing meeting), run the full four-question decode (Manager Tools, "Meeting Preparation Questions"):
1. *Who is invited, and who accepted?* Tells you the importance, the atmosphere, and how to behave. More people — or more senior people — means more serious / higher-impact. Counter-signal: the more benign or vague the title, the more likely the meeting is contentious, because vagueness is message-control and good news rarely gets controlled.
2. *Why is it being held?* The synchronous need an email couldn't carry — explanation, cooperation, coordination, orientation, contention, or celebration.
3. *What's the timing?* Less notice skews negative/urgent: under 24h is big and usually bad; more than a week out is usually benign; 24h–1 week is the hardest to read, so go by the org's norms.
4. *What's the objective?* Three layers — the *spoken* objective (what's broadcast), the *unspoken* objective (the real reason, inferred from who/why/timing), and *your* objective (what you'll get out of it).
** Phase 1 — Gather context (don't re-derive what's already written)
Manager Tools' first recommendation is "get all the available information" — agenda, the full invitee/attendee list (and who accepted), and the supporting materials. Pull together everything that bears on the meeting, in parallel where possible:
- *Agenda + attendee list + supporting docs* — if they weren't circulated, that's a gap to note (and, for a real meeting, a thing Craig could politely ask the convener for). The who-accepted list feeds the "who" question above.
- *Prior related meetings* — search the project's transcript home (wherever recordings/transcripts are filed, e.g. an =assets/= dir) for earlier calls with the same people or on the same topic. Read the relevant ones; cite them in the prep as "background, don't re-derive."
- *Related =todo.org= tasks* — the open tasks that touch this meeting's topic (the data under review, the relationship, the deliverable). These carry the decisions already made and the open questions.
- *Issue-tracker tickets* — any ticket in the project's tracker that the meeting is about (status, body, recent comments).
- *Prior prep docs* — an earlier =working/<slug>-call-prep/= for the same thread (e.g. a recurring partner).
- *Project knowledge* — the project's notes / knowledge files (=notes.org=, or a project =knowledge.org=) sections that frame the relationship or strategy.
The goal of this phase is that the prep doc *summarizes and points at* existing context rather than rebuilding it. Link to the source; don't paste it.
** Phase 2 — Set up the working dir
Per the working-files convention, create =working/<slug>-call-prep/= and write the prep doc as =<YYYY-MM-DD>-<slug>.org= inside it. The slug names the meeting/thread (=vendor-review=, =partner-intro=, =board-update=), not a snapshot date. Supporting artifacts (a data summary, a draft Craig will bring, a diagram) live in the same dir. Add or update the inbound link in the relevant =todo.org= task so future sessions find it.
** Phase 3 — Draft the prep doc
Use this section set:
1. *Header* — one block: meeting name, date + time, medium/location, organizer, attendees (who's actually in the room), tracker/doc links, and a "background — don't re-derive" line pointing at the prior transcripts and the source task.
2. *What this meeting is* — one short paragraph framing it: who called it, why, and the natural shape (who walks whom through what).
3. *What they want out of it (the objective read)* — the other side's goals, in three layers: the *spoken* objective (what the invite/agenda broadcasts), the *unspoken* objective (the real reason, inferred from who/why/timing), and ordered by what they'll lead with. Grounded in who they are and prior context, not guessed.
4. *Questions they'll probably ask (and your one-line answers)* — anticipate the questions and pre-write Craig's crisp answer to each. This is the highest-value section: it's the rehearsal.
5. *Craig's objective and contribution* — the heart of the prep, and the Manager Tools reframe: not "attend" but "contribute." What does Craig want to *achieve*, and what's the active role he'll play — the decisions to land, the asks to make, the positions to state, the proposal to make, or (for a listen-heavy meeting) the specific value he'll add. Name anything worth *pre-wiring* (socializing with an attendee beforehand so it lands and gets supported).
6. *Positions already locked* — decisions made in prior sessions so Craig can *state* them, not relitigate. Pull these from the related tasks and transcripts.
7. *Relevant data at a glance* — the tables/figures Craig might be pressed on (e.g. the dataset breakdown), summarized to render width per the org-table standard (and no more than 200 columns, with cells becoming multi-line cells), with a link to the full detail.
8. *Notes & next steps (fill during / after)* — left open for the meeting itself.
Not every meeting needs all eight. A first intro call may have no "positions locked" or "data" section; a data review leans heavily on them. Include the sections the meeting actually has; don't pad.
** Phase 3.5 — Pre-wire and schedule the prep block
Two Manager Tools habits that sit between drafting and the meeting:
- *Pre-wire* — when Craig has a proposal, a decision to land, or even a pointed question, the prep should surface who to socialize it with beforehand. Pre-wiring turns the meeting from a debate into a confirmation; the goal is *no surprises + agreement*, manufactured in advance. The moves, scaled to the meeting: nail the *key ask* (the decision you actually want — "just an update" rarely is); brief the most pivotal person first (they flag problems and tip you to the others' hot buttons); for a real briefing, request the attendees' time a week or two ahead; and handle every likely objection before it surfaces (name a known disagreement yourself so it isn't a surprise in the room). At peer level it's lighter — the *casual mention*: float it into an existing relaxed conversation with a friendly peer ("not floating this formally yet, but what do you think?"), and decide up front how much you'll change to win their support. The full method — the four framing points and eight steps — is in the [[file:meeting-prep.pre-wire.org][pre-wire reference]] beside this workflow.
- *Schedule the prep* — add a 15 minutes of pre-work as an actual calendar block, not just an intention. If it isn't scheduled, the urgent eats it.
** Phase 4 — Review with Craig
Present the draft and walk the judgment-dependent sections with him: does the "what they want" read match his sense of the other side; are the hold positions right; is there data he expects to be pressed on that's missing; anything about the relationship or politics the written context doesn't capture. Capture his spoken context back into the doc (a dated note or an inline edit) so the rationale survives. Iterate until he's confident walking in.
** Phase 5 — Wire into the day's prep
If the meeting falls on a day that has (or will have) a daily-prep doc, link the prep doc from that day's prep — under the meeting's entry in Day's Priorities or the Meetings/Work-Blocks block. (The daily-prep workflow does the reverse-direction catch: when daily-prep is built later and finds an existing =working/<slug>-call-prep/=, it links it. This phase is the forward direction, for when the prep doc is built first.)
** Phase 6 — Post-meeting: close the loop
After the meeting:
1. *Capture notes/transcript summary* into the doc's "Notes & next steps" section (or hand off to =process-meeting-transcript.org= if it was recorded). If a transcript was taken, link it.
2. *Extract action items* — read the notes/transcript and file every commitment, deliverable, and decision as a =todo.org= task (or a dated update to an existing one). This step is not optional: a meeting that produces commitments and no tasks is a half-done workflow. Cross-check against existing tasks so you update rather than duplicate.
3. *File the artifacts* — when the thread is done, the working-files convention takes over: rename the prep doc + artifacts flat into the project's assets home and delete the working dir. A recurring thread (a partner Craig meets repeatedly) can keep its =working/<slug>-call-prep/= alive across meetings instead.
* Principles to Follow
- *Ground, don't invent.* Every claim about what the other side wants, what's been decided, or what the data shows traces to a source — a prior transcript, a task, a ticket. Where there's no ground, name the gap for Craig to fill rather than guessing.
- *Summarize and link; don't rebuild.* The prep doc points at the detailed context (transcripts, the data-characterization task) and distills the decision-useful version. It is not a second copy of the analysis.
- *The "their questions + your answers" section is the rehearsal.* Spend the most effort there. Walking in with pre-written one-line answers to the likely questions is what the prep buys.
- *Attending → contributing.* The Manager Tools reframe at the center of meeting prep: don't fill a seat, decide the contribution and make it. Every prep doc should answer "what's Craig's active role here?"
- *Read the invite before you prep.* Who / why / timing / objective tells you what the meeting really is and how hard to prep; a vague title often hides a contentious meeting. "He was invited" isn't a reason to attend.
- *Pre-wire what matters.* Socialize a proposal or position with attendees before the meeting; a confirmation beats a debate.
- *State locked decisions, don't relitigate them.* Pulling the already-made decisions into their own section keeps the meeting from reopening settled questions.
- *Close the loop every time.* A meeting that produces commitments and no =todo.org= tasks is a half-done workflow. Phase 6's action-item extraction is the back half, not an afterthought.
- *One discoverable place.* All of a meeting's prep + record lives in its =working/<slug>-call-prep/= dir until filed, then flat in assets. No scattering.
* Living Document
Update this workflow as the prep practice sharpens. The Manager Tools research is folded in (the gate in Phase 0, the get-all-information framing in Phase 1, the objective + attending-to-contributing reframe in Phase 3, the full pre-wire method + schedule-the-block in Phase 3.5, and the principles). The prewire, staff-meeting, and Sunday-Evening-Planning casts are mined. Two candidates this surfaced, neither built yet: a *staff-meeting prep variant* for a recurring engineering weekly (prep-to-run, from the "How to Run Your Staff Meeting" methodology), and a *weekly-planning routine* (Sunday Evening Planning), distinct from this workflow.
** Updates and Learnings
*** 2026-06-10: Promoted to a general template
Promoted from a project-only workflow into a rulesets template. The project-specific references (transcript-home path, issue tracker, knowledge file, the worked-example doc) were generalized to project-neutral terms so any project's =.ai/= picks it up. Phase 6 (post-meeting action-item extraction) is the load-bearing back half — it exists because the absence of exactly that step is what leaves a meeting's committed deliverables unfiled.
|
