Generate a smart, minimal ICP (Ideal Customer Profile) from any input — messy notes, product descriptions, founder hypotheses, or existing context. Produces a dual-render artifact (human-readable + machine-structured YAML) with observable signals for agentic scraping. Use when the user mentions ICP, ideal customer, target customer, who to sell to, customer profile, buyer persona, target market, or needs to define who they're going after commercially — even if they don't use the term "ICP" explicitly.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Generate a smart, minimal ICP (Ideal Customer Profile) from any input — messy notes, product descriptions, founder hypotheses, or existing context. Produces a dual-render artifact (human-readable + machine-structured YAML) with observable signals for agentic scraping. Use when the user mentions ICP, ideal customer, target customer, who to sell to, customer profile, buyer persona, target market, or needs to define who they're going after commercially — even if they don't use the term "ICP" explicitly.
Goal
Transform fuzzy strategic input into a compact, actionable ICP artifact consumable by both humans and downstream agents (scraping, offer design, outbound, CRM).
Inputs
00_inbox/ — raw materials
02_context/ — distilled context if available
Direct user input (free text, notes, hypotheses)
Any combination of the above
Output
04_outputs/icp-[segment-name].md — ICP artifact in markdown with embedded YAML block
If multiple segments: one file per segment + 04_outputs/icp-index.md with ranking
Core Principles
Three rules that govern the entire execution:
Extract-first. Parse all available input before asking a single question. Infer aggressively. Only ask what cannot be deduced and is critical to continue. Maximum 3 questions per iteration. Prefer multiple-choice over open-ended.
Signals over descriptions. Every strategic attribute must translate to at least one observable signal. If you cannot derive a signal, the attribute is decorative — mark it as such or remove it.
Confidence, not certainty. Every field carries a tag: stated (user said it), inferred (you deduced it), (plausible but unconfirmed). Downstream agents use this to weigh decisions.
hypothesis
Procedure
Phase 1 — Absorption
Read all available input (inbox, context, direct text).
Extract: what is being sold, who it seems aimed at, what pains are mentioned, what market context is implied.
Identify critical gaps vs gaps you can reasonably infer.
If critical gaps block progress (you cannot even infer what is being sold), ask — maximum 3 questions, multiple-choice format when possible.
Phase 2 — Segment Hypotheses
Generate 1-3 candidate segments. Each segment is an ICP hypothesis, not a certainty.
For each segment, articulate in one sentence: who + what pain + why now.
If more than one segment, rank by: accessibility x pain intensity x ability to pay.
Present to user for selection/confirmation of beachhead. If only one clear segment exists, skip selection.
Phase 3 — ICP Construction
For the selected segment (or the only one), build the 6 blocks of the artifact (see Output Format below).
For each attribute in blocks 1-3, derive at least one observable signal and populate block 4. Consult references/signal-patterns.md for patterns by org type and data source.
Build the anti-ICP (block 5) from logical inversions + explicit exclusions from input.
Build the scoring heuristic (block 6) combining signals from block 4 with weights.
Phase 4 — Validation
Apply the concreteness test: could you name 10 real companies that fit? If not, the ICP is too vague — tighten it.
Apply the scrapeability test: can each signal in block 4 be looked up in a real data source? If not, reformulate the signal or mark it as manual_check.
Mark the overall ICP status: [draft], [refined], or [validated].
Output Format
The artifact has two renders of the same content in a single file.
Human render (markdown) — top of file
# ICP: [Segment Name]> Status: draft | refined | validated> Generated: YYYY-MM-DD> Beachhead: yes | no> Confidence: low | medium | high## 1. Target Org
| Attribute | Value | Confidence |
|-----------|-------|------------|
| ... | ... | stated/inferred/hypothesis |
## 2. Trigger Events
| Event | Time Window | Confidence |
|-------|-------------|------------|
| ... | ... | ... |
## 3. Decision Unit**Buyer** — [Role]: [pain] / [motivator]
**User** — [Role]: [pain]
**Blocker** — [Role]: [objection]
(Omit blocker if it cannot be inferred — do not invent.)
## 4. Observable Signals### LinkedIn / Sales Navigator
| Signal | Query Hint | Confidence | Check Type |
|--------|-----------|------------|------------|
| ... | ... | ... | automated/manual_check |
### Web / Tech Stack
| Signal | Query Hint | Confidence | Check Type |
|--------|-----------|------------|------------|
### Job Boards
| Signal | Query Hint | Confidence | Check Type |
|--------|-----------|------------|------------|
### Databases / Registries
| Signal | Query Hint | Confidence | Check Type |
|--------|-----------|------------|------------|
(Only include source categories with actual signals. Do not add empty sections.)
## 5. Anti-ICP
| Exclusion | Reason |
|-----------|--------|
| ... | ... |
## 6. Scoring Heuristic
| Signal (or combination) | Weight (1-5) | Source |
|------------------------|--------------|--------|
| ... | ... | ... |
## Changelog
| Date | Change | Reason |
|------|--------|--------|
| YYYY-MM-DD | Initial generation | — |
Machine render (YAML) — bottom of file, fenced
Append this block at the very end of the file. Downstream agents parse this block directly without reading the markdown above.
---# machine-readable ICP — do not edit manually, generated from content aboveicp:segment:""status:draft|refined|validatedconfidence:low|medium|highbeachhead:true|falsegenerated:"YYYY-MM-DD"target_org:-attribute:""value:""confidence:stated|inferred|hypothesistriggers:-event:""window:""confidence:stated|inferred|hypothesisdecision_unit:buyer:role:""pain:""motivator:""user:role:""pain:""blocker:role:""objection:""signals:-signal:""source:""query_hint:""confidence:stated|inferred|hypothesischeck_type:automated|manual_checkanti_icp:-exclusion:""reason:""scoring:-signal_ref:""weight:1-5source:""---
About the 6 Blocks
Block 1 — Target Org
Maximum 5 attributes. Prioritize the ones that discriminate most. Use ranges, not point values (e.g. "50-200 employees", not "100 employees"). Typical attributes: vertical sector, size (employees/revenue), stage (startup/scaleup/enterprise), geography, business model, tech stack.
Block 2 — Trigger Events
What is happening now in the organization that creates urgency. Without triggers, there is no buying timing. Examples: recent funding round, aggressive hiring in a specific area, regulatory change, tool migration, loss of a key competitor, new C-level hire. Each trigger has an estimated relevance time window.
Block 3 — Decision Unit
Not an extensive buyer persona. Three roles maximum:
Buyer: who signs. Their pain and their motivator.
User: who uses it daily. Their operational pain.
Blocker: who can veto. Their typical objection.
If a blocker cannot be inferred, omit it — do not fabricate.
Block 4 — Observable Signals
The differentiating block. Each signal must answer: "what could a scraping agent look for to detect this type of organization or person?"
Organize by data source (LinkedIn, Web, Job Boards, Databases, Activity Signals). Each signal includes a query_hint — a hint on how to search for it (e.g. "LinkedIn Sales Nav filter: headcount growth > 20% last 6mo").
Consult references/signal-patterns.md for patterns by org type and data source.
Block 5 — Anti-ICP
Exclusions that save time for the pipeline. Must be verifiable. Examples: "Companies with fewer than 10 employees — no budget or decision structure", "Public sector — incompatible buying cycles".
Block 6 — Scoring Heuristic
Combines signals from block 4 with weights (1-5). Enables automatic ranking:
Weight 5: signal that nearly confirms fit (e.g. "uses [competitor tool] + posted a [relevant area] role")
Weight 1: weak signal that only adds context
Signal combinations can have compound weights (e.g. "signal A + signal B together = weight 8").
Multi-segment
When multiple segments are generated, create:
One file per segment: icp-[segment-name].md
An index: icp-index.md with ranking, one-line summary per segment, and beachhead recommendation
Refinement Mode
When invoked on an existing ICP:
Read the current artifact.
Integrate new input (scraping data, sales feedback, new hypothesis).
Update affected fields, adjust confidence levels.
Log what changed and why in the ## Changelog block.
Bump status if warranted (draft → refined → validated).
Anti-patterns
Filling all 6 blocks with weak inferences when input is poor. Better to have 3 solid blocks and 3 marked as [pending input].
Signals that cannot be looked up in any real data source. If it is not scrapeable or verifiable, it is not a signal.
Confusing the ICP with the offer. This artifact defines who to target, not what to sell them.
ICPs that fail the concreteness test — if you cannot name companies, it is too abstract.
Output exceeding ~120 lines (human render + YAML). Compress or downstream agent context windows will saturate.
Inventing blocker roles or trigger events without evidence. Omit what you do not know.
