Meeting Prep and Debrief

Runs on: reasoning - reads your files and reasons; any capable agent can run this.

Two modes: prep (before) and debrief (after).

Before You Write

First, run: python scripts/check-identity-ready.py

If exit code is 1, read the output line and surface it to the user verbatim. Do not build the brief. Stop.

Then read three files so the brief is specific, not generic.

1. stack.json at the Founder OS root. Look at calendar (gcal vs outlook), meeting_notes (granola vs otter vs notion), and email_platform. Reference the user's actual MCP, not a hardcoded one. If calendar: outlook_calendar, do not call out a Gmail integration.
2. context/clients.md for any prior interaction history with this person or company. Pull the last touch, current status, and any open commitments.
3. core/identity.md for the founder's relationship framing - first name, business name, role.

If stack.json is null for a field, do not invent. Note "no calendar integration configured" and proceed.

Brain context (default)

Before producing output, read brain/.snapshot.md. If it is missing, or its date: line is more than 3 days old, run python scripts/brain-snapshot.py --write first and read the fresh one - a stale snapshot read as current presents last week's flags and must-dos as today's, which is worse than no memory at all. If Python is unavailable, proceed without it and say so.

If the snapshot is missing, run:

python scripts/brain-snapshot.py --write

Then read it. If the snapshot script is also missing (older install), proceed using only the profile files. Do not block.

The snapshot tells you what flags are open, what the user is working on this week, and what the latest staleness state is. Apply this context to your output where it is relevant. Do not surface every snapshot field in every output - use judgment. For meeting prep, open flags often surface unresolved threads with the same person, and recent decisions tell you what is locked in already so the brief does not re-open settled questions.

Brain pass (auto)

Before writing the meeting brief, invoke the brain-pass skill (skills/brain-pass/SKILL.md) with this question, substituting <subject> for the meeting subject (the person, company, or topic):

What do we know about <subject>? Past interactions, open commitments, unresolved threads, sensitivities.

Read the structured Answer / Evidence / Confidence / Gaps block the pass returns. Use it to shape the brief:

• Past commitments become explicit talking points or "watch for" items.
• Unresolved tension becomes a sensitivity flag in PREP ITEMS.
• A first-interaction answer routes to the New Prospect Detection block below.
• Cite the entry IDs from Evidence in the brief so the founder can open the source if needed.

If skills/brain-pass/SKILL.md is missing (older install), fall back to python scripts/query.py --mode timeline --anchor <subject-slug> and then, if no anchor matches, python scripts/query.py with the subject passed through the quoted block in skills/query/SKILL.md, never inside quotes on the command line (a name with an apostrophe breaks single quotes, and $(...) runs inside double quotes). Do not block.

New Prospect Detection

If the meeting is with a new prospect (someone the founder hasn't worked with before):

1. Check what context exists. If the founder has already done research on this company, use that as the foundation for the meeting brief.
2. If no context exists, offer to research the company before building the brief: "Want me to look up [company] before building the meeting brief? It'll give us context, likely pain points, and questions to bring."
3. If the founder wants to skip research, proceed with meeting-prep using whatever context is available, but note what's missing.

Researched claims about people (mandatory when any web research runs)

A wrong fact about the human across the table is the most expensive research error this skill can make - the founder repeats it to their face. rules/research-integrity.md governs researched facts here, with two rules specific to people:

• Every externally researched fact in the brief carries its source inline - (source: <url>, <date>) on the line it supports, in CONTEXT and THEIR LIKELY PRIORITIES alike. A fact you could not source is written as what it is: "unverified - confirm on the call", which turns a landmine into a discovery question. Never let an unsourced claim about a person read as settled fact.
• Run the same-name check before attributing anything. Names collide constantly. Before attaching a role, an article, or a track record to the person, confirm the source is about THIS person (company, location, or a second corroborating detail must line up). If it does not clearly line up, leave it out - a blank line costs nothing, a mixed-up person costs the meeting.

Facts from the founder's own files (clients.md, the brain pass) cite their entry IDs as usual and need no web source - the brain is the founder's own record.

Pre-Meeting Brief

When the founder says they have a meeting coming up, build a brief. Ask for what you don't know, but don't over-ask if context is already clear.

What You Need (ask if not provided)

1. Who - Name, role, company, relationship history
2. What - Type of meeting (sales, client check-in, partner, investor, team)
3. Goal - What does the founder want to walk away with?
4. Context - Any background, previous conversations, current situation

Brief Structure

MEETING BRIEF
---
Who: [Name, Role, Company]
When: [Date/Time if known]
Goal: [One sentence - what success looks like]
---

CONTEXT
[2-3 sentences of relevant background.]

THEIR LIKELY PRIORITIES
[What does the other person care about? Top 2-3 priorities or pain points.]

QUESTIONS TO ASK
[3-5 strategic questions specific to this meeting's goal.]

WATCH FOR
[1-2 things to pay attention to. Signals, red flags, opportunities.]

PREP ITEMS
[Anything the founder should review, bring, or have ready.]

Question Strategy

Questions should follow this priority:

1. Discovery questions - What don't you know yet that matters?
2. Validation questions - What assumptions need testing?
3. Decision questions - What do you need answered to move forward?
4. Relationship questions - What builds trust and shows you've done your homework?

Good questions are specific. Not "How's business?" but "You mentioned last time you were hiring for ops - did you fill that role?"

No money ask before permission. If the goal is money from them (a paid engagement, a price, a deposit, a pre-order, an order, an agreement to pay later, or a date, a slot, an appointment or a box held for them, with or without a price), check the founder may take money for this activity where they sell. If their files and this conversation do not show it (a licence or permit that covers the activity, or a business already licensed to sell it), say so in one line and build the brief around an interest ask instead (a problem conversation, an intro, their details to hear when it is ready). Earlier sales to friends are not that permission. This repeats the founder safety rule in CLAUDE.md for surfaces where that file is not loaded.

Post-Meeting Debrief

When the founder describes what happened in a meeting, capture it structured.

Debrief Structure

MEETING DEBRIEF
---
With: [Name, Company]
Date: [Date]
---

KEY TAKEAWAYS
[What did you learn? What surprised you?]

DECISIONS MADE
[Any commitments, agreements, or choices locked in.]

ACTION ITEMS
-> [Founder]: [task] by [date]
-> [Other person]: [task] by [date]

FOLLOW-UP
[What happens next? When is the next touchpoint?]

NEXT STEP
[What skill or task comes next - proposal, playbook, follow-up email?]

NOTES
[Anything else worth remembering.]

Formatting Rules

• Arrows (->) for action items
• Keep it scannable - this is a reference document, not prose
• Bold only for section headers and critical items
• No filler. Just what happened and what's next.

If Context Is Thin

If the founder gives you minimal info (just a name and "I have a call"), do a quick web search if tools are available. Look for their LinkedIn, company info, and any mutual context. Build the brief from what you find, under the researched-claims rules above: sources inline, the same-name check before any attribution, and "unverified - confirm on the call" for anything that did not clear it.