meeting-prep

Meeting Prep

One job: the calls and leads in front of you today. A rep opens this between meetings, so every deliverable is one screen, every claim carries a date, and nothing is invented to fill a section.

Three modes:

1. Inbound triage — someone filled a form or emailed in. Is this worth your time?
2. Pre-call brief — the daily driver. One screen you can read in the two minutes before a call.
3. Call plan — a discovery question plan, or a demo flow built only from stated pains.

Ask which one if it isn't obvious from the ask. "Prep my 2pm" is mode 2. "Score this lead" is mode 1. "Build me a discovery plan" is mode 3.

---

Step 0 — context (never blocks)

• If config/gtm-config.md or config/persona-profile.md exist in the working directory, read them: ICP, what you sell, buyer titles, customer list, competitor list, voice. These drive the scoring rubric and the opener's voice.
• If they don't exist, ask 1-2 questions inline ("Who do you sell to — industry, size, geo? Which titles buy?") or point at the icp-builder skill to build the config properly. A missing config never blocks a run.
• Optional read-only enrichment: if a CRM, call recorder, or email is connected, a read-only sweep for prior threads, notes, and calls with the same domain sharpens any brief — past objections, who already talked to them, why the last deal stalled. Read only, never write, and never build the deliverable around it: the brief has to stand up on public data alone.
• For "prep my 2pm" with no calendar connected, just ask which meeting: company, and who you're meeting.

---

Code Mode ground rules (read once, apply everywhere)

All Crustdata calls run inside the execute tool of the Crustdata MCP server (install.crustdata.com/mcp) as a plain-JavaScript script.

• Plain JavaScript only. Author against the typed surface from get_schema, but the script body carries zero type annotations — a : Type, as, or generic is a parse error that fails the whole run before any spend.
• Every script opens with a source-labeled comment: // user query: ... for the literal ask, // model query: ... for a derived step. Scripts without one are rejected before running.
• One I/O primitive: const r = await callTool(name, params) → { ok: true, data } or { ok: false, status, errorType, message }. Always branch on r.ok — a failed call does not abort the script, so an unchecked failure silently proceeds on empty data and looks like "no signal".
• fields is a response whitelist. The result carries only the groups you list; an omitted group reads as undefined later and looks like missing data. List every group you read.
• Return the smallest projection. Only what the script returns reaches the model — map to compact rows, never raw profiles.
• Fan out independent calls with await parallelMap(items, fn); batch first with chunk(list, 25). Never parallelize cursor pagination or dependent stages — identify → enrich stays sequential, and you parallelize within a stage.
• company_identify is free but fuzzy. One domain or name can match several companies. Take the top confidence_score match. Do not project social_profiles on identify — it is plan-gated and 403s the whole call.
• Plan-gated projections fail the whole call with a 403 naming the field. Never project professional_network.followers or metadata on person_search, or certifications / honors / updated_at on person_enrich.
• Filter paths ≠ response paths. You filter experience.employment_details.current.company_name; the response key is ...current[].name. The LinkedIn URL returns at social_handles.professional_network_identifier.profile_url — use the profileUrl(p) accessor.
• Categorical values are closed sets. A plausible-but-wrong value silently returns zero rows. Resolve with company_autocomplete / person_autocomplete (free) before filtering on industries, funding round types, or seniority.
• Zero results ≠ no signal. Read the trajectory in the execute response before telling a rep an account is quiet.