prima-committee

What it does when it runs

Identifies the buying committee — real, named contacts per account — for accounts already classified `4B`/`4C` (via `sub_segment`) or `Cat1`/`Cat2`/`Cat3` (via `company_category`) by `prima-icp-check` (`4A`/`4D` sub-segments not supported yet). `Cat1` (AI Infrastructure Operators) and `Cat2` (Crypto Miners Pivoting to AI) share a single target-title dictionary — Notion documents the same direct-equipment-buyer profile for both — with one PRINCIPAL tier (VP Infrastructure, Head of Deployment, Director of Supply Chain, VP Operations, Head of HPC, Procurement Director) and a COO FALLBACK gated by the same founder/C-suite-always-FALLBACK rule as `4C`. Sources widely (3-4 verifiable names per account — the "banca") but writes narrowly: the outreach guardrail still caps actual contact at 2 people per account regardless of segment, with the rest held on the bench for later promotion if a contact doesn't respond. Cat3 also enforces a stricter manufacturing-division-only rule and, since its targeting logic is an unvalidated v1 hypothesis (Aldahir, 2026-08-03), sourcing runs on every Cat3 priority but `P1` contacts always come back as `NEEDS_HUMAN_REVIEW` (never auto-cleared `CONTACT_FOUND`) until the hypothesis is validated on `P2` data. Writes/updates an accumulative `output/account_roster.csv` (never regenerated) tracking every sourced name — skill-owned columns vs. operator-owned lifecycle columns (`contact_status`, touches, outcome) — and only hands a contact to `prima-email-waterfall` when it's both `contact_status = active` AND `status = CONTACT_FOUND` — bench contacts and unconfirmed `NEEDS_HUMAN_REVIEW` contacts (e.g. any Cat3 `P1` row, active or not) stay `email_status = NOT_ATTEMPTED` so Deepline credits are never spent on an unpromoted or unconfirmed name. Sources names via free WebSearch (company site + public LinkedIn snippets) first; only falls back to paid Deepline providers (ContactOut, Lusha, RocketReach, etc.) after stopping to show how many accounts need paid lookup and the estimated cost, and getting explicit approval — same gate as the Clay-vs-Terminal pilot. Never fabricates a name — if no verifiable contact is found for a role, outputs the target role/title only. Use this after `prima-icp-check` (and ideally after `prima-signal-scan` has confirmed the target-title door exists) and before `prima-email-waterfall` needs a named person to find an email for.

Automated analysis of the skill and the 1 file bundled beside it. A skill’s own description is written to be selected by an agent, so it describes the job and not the dependencies.

Keys and connectors you must supply

None found.

Hosts it reaches

No third-party host appears in the skill or its bundled files.

Tool permissions it declares

No allowed-tools in the frontmatter. It does act, so it runs under whatever permissions your session already grants.

Actions present in the files

network