# /icp-research — Ideal customer profile research
Research a defensible answer to **which customers should be pursued first and why**. This is a dual-class skill: it can produce a customer-facing research deliverable or an internal strategy artifact, but it creates **one canonical artifact per run**.
The shared method, source protocol, model, output structure, and handoffs live in `references/icp-research.md`. Read it in full before starting. Do not copy or redefine its method here.
Scope and boundaries
Use this skill to compare candidate segments, recommend a primary ICP when the evidence permits, map the buying group and job to be done, identify exclusions, and create a practical validation plan.
Do not turn this into:
- market sizing, broad industry analysis, or pricing-power research — use `/market-research`; - a technology or vendor landscape — use `/research-usecase`; - a named-account prospect list or public signal scan — use `/value-signal-scan`; - positioning, channel selection, or an activation plan — use `/campaign-planner` after the ICP decision exists; - interviews, surveys, or new customer research. This v1 uses available public and supplied first-party evidence, then specifies the next validation work.
Load context and governing references
At the start of every run, load:
1. `references/icp-research.md` in full. 2. `references/output-paths.md`. 3. `references/client-deliverable-standards.md` in full for client-deliverable mode, and at least section 4 for internal-strategy mode. 4. `references/org/identity.md` and `references/org/anti-patterns.md` for a client deliverable. Also load `references/org/pricing.md` when discussing budget, value, or fees. 5. Every structural org-bundle file for an internal strategy run, following AGENTS.md's current bundle list. 6. `references/browser-etiquette.md` before any high-friction browsing.
Print `Loaded ICP method and context as of <date>` after loading. For an internal strategy run, `<date>` is the most recent commit date across the structural org bundle. For a client-deliverable run, use the date the method and required client context were checked.
When a live CRM read is useful, route it through `/crm` and its helpers. Do not write to CRM, Gmail, Drive, or any other system of record from this skill; use `/gmail` and `/gdrive` only as explicit downstream owners when the user asks. Proceed without live CRM access when it is unavailable and record the resulting limitation.
Inputs and mode selection
Accept:
- a customer name and offering; - an internal topic, market, or offer; - supplied customer material: customer lists, CRM exports, win/loss notes, transcripts, proposals, support or usage summaries, or existing research; - public sources gathered during the run.
Ask one batched scoping question only for information not already supplied:
1. **Mode:** `client deliverable` or `internal strategy`. 2. **Decision and offer:** What offer, market, or targeting decision does this research need to support? 3. **Customer and inputs:** For client mode, confirm customer display name and supplied first-party sources. For internal mode, confirm topic slug and any usable internal inputs. 4. **Candidate segments:** Name up to three if the user has a view; otherwise propose two or three evidence-based candidates before researching deeply. 5. **Format and preparer:** In client mode, use the three-way Markdown / DOCX / both picker and ask who prepared the deliverable, as required by `references/client-deliverable-standards.md`. Internal mode is Markdown only.
If the user asks for a customer-facing artifact but has not authorized use of supplied confidential material in it, use the material only as private context and report provenance at source-type/date level. Do not expose raw paths, contact data, row-level CRM data, or unapproved names.
Research workflow
1. **Frame the decision.** State the offering, geography, customer context, candidate segments, and what an ICP recommendation must enable next. 2. **Build the source plan.** Apply the lane protocol in `references/icp-research.md`: customer/offer; official population where available; primary organization evidence; observed buyer/workflow evidence; buying ecosystem; alternatives; and timing signals. Add conditional modules only where relevant. 3. **Gather and log evidence.** Use Fetch first for page content. If a page cannot be read or rendered, use the Playwright CLI according to AGENTS.md. Search snippets, AI summaries, listicles, vendor claims, and consultancy reports are discovery aids, not sole proof. Maintain the required research ledger as evidence is gathered. 4. **Compare candidates.** Apply the five-criterion decision model. Use `Strong`, `Mixed`, `Weak`, or `Unknown`; do not invent a weighted score. Mark the whole research result `Partial` when an applicable required lane is missing or too thin. 5. **Select or decline to select.** Recommend a primary ICP only if it clears the hard gates in the shared method. Otherwise make the uncertainty visible and recommend the smallest next validation action. 6. **Map the decision journey.** For the primary ICP, document the economic buyer, champion, user, and blocker; their concerns; likely decision stages; and observable timing signals. Distinguish evidence from an assumption. 7. **Create a validation plan.** Convert each material unknown into a short, specific test: a first-party data cut, win/loss review, customer interview, buyer conversation, or bounded message/account experiment. Public research alone is never `Validated`.
Evidence and citation rules
Follow `references/icp-research.md` without exception:
- A recommended ICP must draw on at least three independent evidence lanes, including official/authoritative population evidence where available, primary organization evidence, and observed buyer/workflow or purchase evidence. - A vendor, analyst, or consultancy source cannot be the sole proof of the recommendation. - Capture URLs while researching. Cite every non-trivial external claim inline, list all sources at the end, and re-check the URL-to-claim pairing before writing the artifact. - Record first-party provenance as source type and date. Do not create a false public citation for it. - Use `Hypothesis`, `Supported`, `Validated`, and `Partial` exactly as defined in the shared method.
Checkpoint before writing
Before creating files, present a concise decision review:
- the proposed primary ICP or the reason no recommendation clears the gate;
- the two or three candidate comparison and evidence status;
- material limitations and anti-ICP conditions;
- the shortest validation plan;
- client mode only: selected format and preparer.
Ask: `Ready to write the ICP research artifact, or would you like to adjust the decision or evidence gaps first?` Do not write until the user confirms, unless the user explicitly asked in the same turn to create the artifact after research.
Output
Use the exact section order in `references/icp-research.md`:
- Decision Summary
- Research Scope and Source Coverage Status
- Evidence Base and Limitations
- Candidate Segment Comparison
- Primary ICP Card
- Secondary Segment Hypothesis
- Anti-ICP and Exclusions
- Jobs to Be Done
- Buying Group and Decision Journey
- Timing and Observable Signals
- Validation Plan
- Evidence Ledger
- Sources
Client-deliverable mode
Follow every applicable convention in `references/client-deliverable-standards.md`, including format picker, pre-load, voice, citation check, checkpoint, branded DOCX process when selected, user-driven Drive boundary, and commit behavior.
Write the Markdown to the customer folder:
```text customers/<Customer Name>/<filename>.md ```
Use `[Customer] - Ideal Customer Profile Research.md` for a company-wide ICP, or `[Offering] - Ideal Customer Profile Research.md` when an offering is the clear subject. Use the same basename for the DOCX when selected. See `references/output-paths.md` for the canonical table.
Internal-strategy mode
Write Markdown only:
```text research-thought-leadership/<topic-slug>/icp-research.md ```
It remains a research artifact, not a campaign plan or prospect list. Follow the citation, source-ledger, stable-filename, commit, and user-driven Drive rules in the governing references.
Save and hand off
After approval, commit the Markdown artifact with:
```bash scripts/commit-md-to-main.sh \ "<absolute path to the Markdown artifact>" \ "Update ICP research: <customer or topic>" ```
Return the printed `GitHub URL:` as the primary shareable result. Do not auto-upload to Drive. Offer the relevant next step without invoking it:
- `/campaign-planner` for positioning, channel, and activation planning;
- `/value-signal-scan` for a public prospect scan using the primary ICP card;
- `/market-research` for sizing, category, competitive, or pricing questions;
- `/research-usecase` for technology, vendor, or use-case analysis;
- `/crm` only if the user wants a separate CRM read or handoff.
Final quality check
- [ ] Mode, offering/topic, candidate segments, and output location are clear. - [ ] The shared ICP method and relevant org/client references were loaded. - [ ] Three independent applicable source lanes support any recommendation. - [ ] Official population, primary organization, and observed buyer/workflow evidence were used where available, or gaps are labeled `Partial`. - [ ] Candidate hard gates were applied without a synthetic score. - [ ] The primary ICP card, buying group, JTBD, timing signals, exclusions, and validation plan are all present. - [ ] First-party provenance is safe for the audience; no raw confidential or personal data is exposed. - [ ] Every external claim has an inline citation and a verified Sources entry. - [ ] The evidence ledger is complete and stable filenames are used.