rdfitted/meeting-debrief

Meeting Debrief Skill

Post-meeting flip side of meeting-prep. Meeting-prep reads institutional knowledge to build a briefing; meeting-debrief harvests fresh meeting content and writes it back to that institutional knowledge. Always diff against what's already there — never clobber hand-edits, never duplicate decisions, never re-state contacts already in the table.

When to use

• "Debrief that call" / "log the meeting" / "capture this"
• "Add Aaron / Tom / Brenda to the wiki" after a fresh meeting
• "I just got off the phone with <X> — get it in"
• "Backfill the last 3 calls with <X>"
• Periodic catch-up: "I haven't logged the last week of meetings"
• Post-meeting-prep natural follow-through when the meeting happens

When NOT to use

• The user wants to read past meetings (use /client-meetings or the granola skill)
• The user wants a full client-memory refresh from all sources (/sync-client <slug>)
• The user wants to flow project-DNA learnings up to the global wiki (/curate-learnings)
• Pre-meeting research (/meeting-prep)

Arguments

Flexible. Any of:

• /meeting-debrief <slug> — e.g. /meeting-debrief summit-rb (debrief the latest meeting for a known client)
• /meeting-debrief <name> — e.g. /meeting-debrief Aaron Warshaw
• /meeting-debrief <email> — e.g. /meeting-debrief [email protected]
• /meeting-debrief <slug-or-name> last N — debrief the most recent N meetings
• /meeting-debrief <slug-or-name> since YYYY-MM-DD — debrief everything since a date
• /meeting-debrief <doc-id> — debrief a specific Granola document
• Bare invocation — ask: who, and is it the latest meeting or a backfill?

Default behavior with just a target and no range: debrief the single most recent meeting with that target. Backfills require explicit last N or since arguments — keeps single-meeting debriefs from accidentally rewriting the world.

Process

Phase 1 — Identify the target & resolve the meeting(s)

1. Resolve the target to a client slug if one exists:

   • Check ~/.claude/clients/CLIENTS.md for a matching slug
   • Check ~/.ai-docs/wiki/clients/ for a matching page
   • Grep ~/.claude/clients/*/CLIENT.md and ~/.ai-docs/wiki/clients/*.md for the name/email/company

2. If slug found → known client, will update existing files If no slug found → cold/new contact, will create the full institutional record (mirror meeting-prep Phase 5)

3. Find the meeting(s):

   • For a known slug: use the Granola folder ID via the granola skill (granola_api.py list-meetings <slug>), or fall back to the local cache via the /client-meetings pattern
   • For an arbitrary name/email: search %APPDATA%\Granola\cache-v6.json for matches in title, notes_plain, notes_markdown, and people[].email/name
   • Apply the last N / since YYYY-MM-DD filter if provided; otherwise pick the single most recent

4. Fetch the content:

   • Always pull the AI summary panel via granola_api.py panels <doc-id> (richer than raw notes)
   • For the target meeting(s), pull the full transcript via granola_api.py transcript <doc-id> — microphone = Ryan, system = other participants
   • If transcripts aren't available via API, fall back to local cache state["transcripts"][doc_id]

Phase 2 — Load existing institutional knowledge

Read everything that exists, in full, so the diff is honest:

1. ~/.ai-docs/wiki/clients/<slug>.md (if exists)
2. ~/.claude/clients/<slug>/CLIENT.md (if exists)
3. ~/.claude/clients/<slug>/context.md (if exists)
4. ~/.claude/clients/<slug>/decisions.md (if exists)
5. ~/.claude/clients/<slug>/status.md (if exists)
6. ~/.claude/clients/CLIENTS.md
7. ~/.ai-docs/wiki/index.md and log.md (so we know what's already registered)

Phase 3 — Extract structured deltas from the meeting(s)

Comb the panel + transcript for the following categories. Tag each item as NEW or ALREADY KNOWN after diffing against Phase 2.

• Attendees — full list with role and email if available. Net-new people get added to the Contacts table.
• Decisions made — anything the user (or counterpart) committed to, scoped, or ruled out. Each gets an entry in decisions.md with date + rationale + source (granola doc id).
• Action items — Ryan-owned, them-owned, joint. Add to status.md Next Steps with owner and deadline.
• Pain points surfaced — append to context.md Pain Points table with notes and quick-win-candidate flag.
• Sentiment / quotes that landed — speaker, exact quote (~250 chars), the preceding context (~150 chars). Goes under a "Client Sentiment — Positive Signals" section in the wiki page (see UBS / GVB / TOG patterns).
• Status changes — stage moved (cold-lead → active, prospect → signed)? Engagement model evolved? Update status.md Stage and CLIENTS.md one-liner if material.
• New facts about person/company — family, side ventures, prior employer, geography, education, personal preferences (meeting cadence, communication style). Append to CLIENT.md Key Contacts notes or context.md.
• Sensitive context — legal disputes, departure messiness, NDAs, family medical, anything explicitly internal-only. Flag with INTERNAL ONLY markers AND a "do NOT engage <X>" warning where adversarial parties exist. Mirror the Summit RB / ARS pattern.
• Pitch framing that landed (or didn't) — what messaging resonated? What fell flat? Useful for productization. Append to context.md Pitch Framing section.
• Tech/operational signals — current systems, integration points, cash-flow reality, headcount, vendor relationships. Append to context.md.
• Linked entities — newly mentioned companies, prior employers, mutual contacts. Cross-reference; add to CLIENT.md Adjacent / Partner Contacts or Linked Entity sections.

Phase 4 — Preserve hand-edits (CRITICAL)

The user routinely hand-edits these files between sessions (e.g. Billy's St. Peter's Prep / Maui Mikes background was hand-added). Never overwrite. Always append or surgically insert.

Rules:

• Read each file fully before any write
• Use Edit (string replacement) rather than Write (full overwrite) wherever practical
• When inserting into a table, insert a new row — don't regenerate the whole table
• When updating a contact's notes, append " | <new note>" rather than replacing the cell
• When adding a section that doesn't exist yet, insert above the next existing section (preserve heading order)
• If a section's structure has clearly been customized by hand, write the new content into a subsection rather than restructuring

Exception: if a file genuinely doesn't exist yet (brand-new client), Write is fine for the initial scaffold.

Phase 5 — Propose changes before writing

Show the user:

1. Summary of meetings processed — date(s), title(s), attendees, doc ID(s)
2. Per file, the deltas to be applied — sectioned, with NEW items clearly marked
3. Any conflict notes — e.g. "status.md currently says 'cold lead' — promote to 'active prospect'?"
4. Curate-learnings candidates — patterns from this meeting that might belong in the global wiki (patterns/, practices/, research/). Don't auto-flow upward — surface for the user to decide.

Wait for confirmation (or proceed automatically if the user's invocation was clearly "just do it, I trust you" — read the room).

Phase 6 — Write back

Apply changes in this order:

1. Wiki client page (~/.ai-docs/wiki/clients/<slug>.md):

   • Bump last_updated: in frontmatter to today's date
   • Append/insert deltas into appropriate sections
   • Add the new Granola doc id(s) to the learned_from: frontmatter list
   • Add any new cross-refs

2. Client memory files (~/.claude/clients/<slug>/):

   • CLIENT.md — new contacts, new background facts on existing contacts
   • context.md — pain points, pitch framing, tech signals, operating-profile updates
   • decisions.md — append new decisions with ## YYYY-MM-DD — <title> blocks
   • status.md — update Stage if changed, refresh Next Steps, add to Watch Items if warranted, update Last Touchpoint

3. Indices:

   • ~/.ai-docs/wiki/index.md — only if it's a brand-new client page
   • ~/.claude/clients/CLIENTS.md — update the one-liner if stage or material facts changed

4. Wiki log (~/.ai-docs/wiki/log.md) — append:

   ## YYYY-MM-DD | update | <slug> debrief — <N> meeting(s) processed (granola <doc-id>). <one-line summary of biggest deltas>.
   

   Or for a brand-new client: use the add operation as in the Summit RB precedent.

Phase 7 — Offer upward flow (optional)

If Phase 5 surfaced generalizable patterns, ask whether the user wants to run /curate-learnings to flow them up to the global wiki (patterns/practices/research). Don't do it automatically — that's a separate decision per the wiki schema.

Hard Rules

• Windows environment — Python via Bash, PowerShell where appropriate; avoid Unix-only constructs.
• No clobbering hand-edits — Phase 4 is non-negotiable. Read fully, edit surgically, append rather than overwrite.
• Diff before write — surface what's NEW vs ALREADY KNOWN. Don't duplicate decisions, contacts, or action items.
• Sensitive flags — legal/family/NDA content gets INTERNAL ONLY markers and goes into client memory (~/.claude/clients/<slug>/) NOT the wiki page if it's deeply personal. The wiki page is more searchable and more likely to be referenced cross-context; the clients/ folder is the operational vault.
• Source citations — every decision and quote logged needs the Granola doc id as provenance, per wiki schema's "Cite the source" rule.
• Spelling integrity — if the meeting reveals a previously-misspelled name (Warshaw vs Warshow), surface the correction explicitly and fix all occurrences across wiki + memory.
• Client context isolation — only update the target client's files. Don't bleed insights into adjacent clients' folders even if the same name (e.g. Billy) appears.

Example invocations

/meeting-debrief summit-rb
/meeting-debrief Aaron Warshaw
/meeting-debrief [email protected]
/meeting-debrief ubs last 3
/meeting-debrief tog since 2026-05-01
/meeting-debrief 1197d26d-28e0-4585-8a65-080ce1ebd617

Reference paths

• Wiki: C:\Users\USERNAME\.ai-docs\wiki\
• Wiki schema: C:\Users\USERNAME\.ai-docs\schema.md
• Wiki log: C:\Users\USERNAME\.ai-docs\wiki\log.md
• Wiki index: C:\Users\USERNAME\.ai-docs\wiki\index.md
• Client memory: C:\Users\USERNAME\.claude\clients\
• Client index: C:\Users\USERNAME\.claude\clients\CLIENTS.md
• Granola cache: %APPDATA%\Granola\cache-v6.json
• Granola skill: C:\Users\USERNAME\.claude\skills\granola\SKILL.md
• Granola API: python ~/.claude/skills/granola/scripts/granola_api.py {list-meetings|panels|transcript|mine-sentiment} ...

Related skills/commands

• /meeting-prep <name|email> — pre-meeting research briefing (companion skill — this skill is the post-meeting counterpart)
• /client-meetings <slug> — view cached meetings without writing anything back
• granola skill — full Granola API access (used internally by this skill)
• /sync-client <slug> — full refresh of a client memory folder from all sources (broader scope than this)
• /curate-learnings — flow project-DNA learnings up to the global wiki (separate, more deliberate decision)
• /wiki add|update|lint|search — direct wiki management

Output convention

End every debrief with:

**Debrief written.** <N> meeting(s) processed.
- Wiki: <path> (<sections updated>)
- Client memory: <files updated>
- Log: <log entry>
- Curate-learnings candidates: <count or "none">

Keep the closing summary tight so the user can verify at a glance.