rdfitted/meeting-prep

Meeting Prep Skill

Research a counterpart before a meeting and produce a structured briefing. Always check institutional knowledge first — the wiki and client memory exist precisely so we don't pay for the same research twice. External web research is the last step, not the first.

When to use

• "I have a meeting with <name> from <company>"
• "Can you research <person>?" / "What do we know about <person/company>?"
• "Prep me for my call with <X>"
• A new lead email arrives and the user shares the sender's details
• Post-meeting follow-through: "great call — add them to the wiki"

When NOT to use

• The user just wants current news on a topic (use Metaphor / WebSearch directly)
• A meeting with someone already deeply documented and recently updated — read the wiki page and answer; don't re-research
• The user is asking about a specific past meeting transcript — that's /client-meetings or the granola skill

Arguments

Flexible. Any of:

• /meeting-prep <name> — e.g. /meeting-prep Aaron Warshow
• /meeting-prep <email> — e.g. /meeting-prep [email protected]
• /meeting-prep <name> <company> — combines both signals
• /meeting-prep <name> <email> <company> — fullest signal
• Bare invocation — ask the user for at minimum a name OR email

Always preserve the user's spelling initially, but verify against the email domain and authoritative sources (LinkedIn, ZoomInfo). Surface spelling corrections explicitly (e.g. Warshaw not Warshow).

Process

Phase 1 — Institutional Knowledge Check (DO THIS FIRST)

The wiki and client memory may already have everything the user needs. Hitting external sources before checking is a sin.

1. Wiki — client pages: Grep ~/.ai-docs/wiki/clients/ for the person's name, surname variants, company name, and email domain.

   Grep tool, path: C:\Users\USERNAME\.ai-docs\wiki\clients
   patterns to try (in order): full name → surname → company name → email domain → first name
   

2. Wiki — full sweep: If no client-page match, grep all of ~/.ai-docs/wiki/ (patterns, practices, research, log.md). Sometimes a person shows up in practices/sow-conventions.md or a research page.

3. Client memory: Grep ~/.claude/clients/ (CLIENT.md, context.md, decisions.md, status.md across all client folders). Don't forget the index at ~/.claude/clients/CLIENTS.md.

4. Personal memory: Grep ~/.claude/projects/C--Users-RDuff/memory/ for the name — sometimes people are tagged in feedback_*.md or person_*.md files.

5. Result handling:

   • Match found → load the matched page(s) in full, use them as the spine of the briefing, and ONLY do external research to fill explicit gaps or refresh stale data (>90 days per wiki schema).
   • No match → continue to Phase 2.

Phase 2 — Meeting History (Granola)

Even if the wiki has no entry, prior meetings may exist.

1. Granola local cache — open %APPDATA%\Granola\cache-v6.json via Python and search documents by:

   • Person's name in title
   • Person's name or email in people array
   • Company name in title or notes
   • Email domain in people[].email

2. Granola API — if the user is a known client (slug exists), use the granola skill to list meetings and pull transcripts/panels for any matches. The local cache only retains ~3 transcripts; the API has full history.

3. Extract: meeting dates, attendees, decisions, action items, sentiment, anything noted that needs follow-up.

Phase 3 — External Research (only to fill gaps)

Only after Phases 1–2 leave gaps. Be surgical, not exhaustive.

1. Spelling / disambiguation — if name is uncertain, use the email domain or company name to nail the right spelling before flooding searches with the wrong term. Email domain is ground truth for last name in most cases.

2. Web search — paired queries first:

   • "<Full Name>" <Company>
   • "<Full Name>" <industry> (if industry hinted by domain or user)
   • "<email>" (exact-match in quotes catches contact databases)

3. Company website probe — WebFetch https://<domain> AND https://www.<domain>. If both fail (ECONNREFUSED, timeout):

   • DNS lookup (nslookup via Bash) to confirm the domain resolves
   • If it resolves but doesn't serve HTTP, the site is likely MX-only / in-setup — a strong signal that the company is brand new

4. Authoritative sources (use WebFetch for these, they have structured data):

   • LinkedIn company page: https://www.linkedin.com/company/<slug>
   • ZoomInfo: https://www.zoominfo.com/c/<slug>/<id> (often in search results)
   • RocketReach: https://rocketreach.co/<name>-email_<id>
   • Dun & Bradstreet for company size/revenue

5. Name collision check — search the exact name in quotes alone. Multiple people share names (e.g. Aaron Warshaw the restoration operator vs. Aaron Warshaw the Ogletree Deakins employment lawyer). Flag collisions explicitly so the user doesn't accidentally walk into the wrong context.

6. Adjacent context — if the email is at a new/spin-out domain, search for prior employer connections. A "President of X at Y" who now has a new domain is almost certainly a spin-out — chase the linkage.

Phase 4 — Briefing Output

Compile a structured briefing. Adapt sections to what's actually known — don't pad with empty headers.

## TL;DR
2-3 lines: who they are, what they do, why this meeting matters.

## Person
- Role, employer, location
- Background (education, prior roles) — only if non-obvious
- Family / personal context (only if surfaced and relevant to the conversation)
- Side ventures / other businesses

## Company
- What they do, who they serve
- Size (headcount, revenue) with source
- Geography
- Leadership team
- Tagline / positioning
- Distinctive operating model

## Existing Relationship (if any)
- Past meetings (dates, summaries)
- Decisions on record
- Sentiment signals
- Active commitments

## Linked Entities
- Prior employer / spin-out parent
- Mutual contacts (esp. the introducer)
- Companies in the same orbit

## Sensitive Context (flagged INTERNAL ONLY)
- Legal disputes, NDAs, departure messiness
- Adversarial relationships
- Anything that should NOT be referenced externally

## Spelling / Identity Confirmation
- Confirmed spelling
- Name collisions to disregard

## Suggested Angle for the Meeting
- Opening questions that pay off
- Frames likely to land
- Things to avoid

## Sources
- Markdown hyperlinks to everything cited

Keep it tight. The user is heading into a meeting — they need a brief, not a dossier.

Phase 5 — Post-Meeting Wiki Update (offer, don't auto-execute)

After the meeting, the user will often say "add them to the wiki" or "that went well, save it." When they do — or proactively when the user signals the call happened — follow the full institutional-update routine:

1. Wiki page — create ~/.ai-docs/wiki/clients/<slug>.md (or update existing) using the frontmatter format from ~/.ai-docs/schema.md:

   ---
   title: <Company Name> (<Primary Contact>)
   category: clients
   last_updated: YYYY-MM-DD
   cross_refs: []
   learned_from:
     - <Granola meeting source>
     - Web research <date>
   ---
   

   Sections to consider: Primary Stakeholder, Departure Context (if sensitive), Industry/Operating Model, Pain Points, Pitch Framing That Landed, IP terms discussed, Linked Entities, Status, Sources.

2. Register in index — add a one-liner to ~/.ai-docs/wiki/index.md under ## Clients.

3. Log the operation — append to ~/.ai-docs/wiki/log.md:

   ## YYYY-MM-DD | add | New client page clients/<slug>.md — <one-line description>. <Granola doc id if applicable>. <key flags>.
   

4. Client memory — if the user wants the full ops folder (decisions log, status board, structured contact list), also create ~/.claude/clients/<slug>/ with:

   • CLIENT.md (profile, contacts, departure context flagged)
   • context.md (domain knowledge, pain points, tech stack assumptions, productization fit)
   • decisions.md (append-only, with date + rationale + source)
   • status.md (current stage, next steps, watch items, meeting cadence)

   Add to ~/.claude/clients/CLIENTS.md index. Match the format of existing clients (ubs, gvb, tog) for consistency.

5. Slug choice — short and consistent with existing clients (gvb, ubs, tog, totum, scattered-ashes-maui, summit-rb). Initials work when the company name is long.

Hard Rules

• Windows environment — no Unix-specific commands. Use PowerShell or Python via Bash; avoid find -delete, heredocs that break in pwsh, Unix paths.
• Spelling integrity — if the user gives the wrong spelling, surface the correction explicitly. Don't silently use the right one without telling them.
• Sensitive flags — legal disputes, defamation, lawsuits, NDAs, adversarial departures all get flagged as INTERNAL-ONLY in the briefing AND in any wiki/client-memory files written. Add "do NOT engage <X>" warnings where adversarial relationships exist.
• Client context isolation — per ~/CLAUDE.md: never bleed knowledge across client boundaries unless an explicit cross-ref or shared integration justifies it. The Phase 1 sweep should be read-only across all clients, but the briefing focuses on the target only.
• No fabrication — if a fact isn't sourced, say so. "Greenfield, no public footprint" beats inventing a plausible-sounding stack.

Example invocations

/meeting-prep Aaron Warshow [email protected]
/meeting-prep Tom Tinervin
/meeting-prep [email protected] Cloud Capital Funding
/meeting-prep "what do we know about Sam Lamphere"

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
• Personal memory: C:\Users\USERNAME\.claude\projects\C--Users-RDuff\memory\
• Granola cache: %APPDATA%\Granola\cache-v6.json
• Granola skill: C:\Users\USERNAME\.claude\skills\granola\SKILL.md
• Client-meetings command: C:\Users\USERNAME\.claude\commands\client-meetings.md
• Sync-client command: C:\Users\USERNAME\.claude\commands\sync-client.md

Related skills/commands

• /client-meetings <slug> — pull cached Granola meetings for a known client
• granola skill — full Granola API access beyond the 3-meeting local cache (sentiment mining, full transcripts)
• /sync-client <slug> — refresh a client memory folder from authoritative sources
• /curate-learnings — flow project-specific learnings upward into the global wiki (run at session end if meeting yielded patterns worth generalizing)