Turn a category into a real ICP definition.
Names your tiers with explicit criteria, the fit signals, the anti-ICP you exclude on purpose, and a qualification framework, plus an evolution log. A category is not a definition.
In plain English: “Who exactly are we for?”
Inside: The tier criteria, the anti-ICP, the must-have vs red-flag framework, and the evolution log.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
Everything the skill does, in full.
Turns a fuzzy "we sell to Series B SaaS" into a real ICP definition: named tiers with explicit criteria, the signals that indicate fit, the anti-ICP you exclude on purpose, and a qualification framework. This is the substance the rest of your context repo runs on. A category is not a definition, and bad context in is bad output out.
- 11. Separate category from definition. "Series B SaaS" is a category. A definition adds the employee range and why, the technographic signals, the organizational signals (does this function even exist there?), and the exclusions.
- Name the tiers. Tier 1 buys fast, expands, and references. Tier 2 fits but is slower or smaller. Tier 3 works but is not the focus. Give each explicit, checkable criteria.
- Write the anti-ICP. The segments you exclude on purpose, and why. This saves more rep time than the ICP itself.
- Build the qualification framework. Must-haves (no deal without them) kept separate from red flags (proceed with caution). Not one blended list.
- Start the evolution log. Date the definition. Every time a filter tightens or a segment gets cut, record what changed and why. Six months of that log is worth more than the current definition.
- Naming a category and calling it a definition.
- One blended qualification list instead of must-haves vs red flags.
- No anti-ICP, so reps chase everything.
- No evolution log, so you never learn why the ICP changed.
[your tier definitions with explicit criteria, the anti-ICP, the must-have vs red-flag framework, and the first evolution-log entry. This becomes context/icp-definition.md]
Example (illustrative):
- Tier 1: Series B to D B2B SaaS, 50 to 500 reps, a RevOps leader in seat, on Salesforce plus an outreach tool. Trigger: a new VP of Sales in the last 90 days.
- Anti-ICP: seed stage, no RevOps function, founder-led sales only.
- Must-have: a dedicated RevOps owner. Red flag: no CRM of record.
- Evolution log, 2026-07-26: tightened Tier 1 from over 25 reps to over 50 after three sub-50 deals stalled on no owner.
Hand the ICP to Positioning so your message speaks to exactly who you just defined. The Sales Operator. Receipts only.
Where an operator takes this next.
The read is step one. Here is where an operator takes it once the manual version proves out.
Hand the ICP to Positioning so your message speaks to exactly who you just defined. The Sales Operator. Receipts only.
Feed the tier definitions into a composite-scoring workflow that runs against Salesforce nightly, so fit is not a one-time judgment call.
Schedule a Claude task quarterly to compare closed-won and churned accounts against the current tiers and flag when the anti-ICP needs updating.
Wire the ICP definition into Clay or an enrichment tool so new leads get scored against your real tiers the moment they hit the CRM.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.