ICP Persona Builder
Research a company's ideal customer profiles and build detailed synthetic buyer personas.
How to use it
- Hit Copy SKILL.md — or use the Claude Code line below to get every file.
- Claude: ⋯ → Download .md, then Customize → Skills → Add → Upload skill.
ChatGPT: make a Project and paste it into Instructions.
Neither? Paste it at the top of a new chat — it works for that chat. - Describe your job in plain words. The AI follows the skill from there.
npx degit gooseworks-ai/goose-skills/skills/research/capabilities/buyer-persona-generator#main ~/.claude/skills/buyer-persona-generatorFor one project only, change the path to .claude/skills/buyer-persona-generator. This skill also uses personas.json, personas.md, segments.md — copying SKILL.md alone won't be enough. See the folder on GitHub.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Show the full text184 lines
ICP Persona Builder
Research a company's buyer segments and build detailed synthetic personas that model their ideal customers. These personas become a reusable client asset — once built, any skill can load them to evaluate content, messaging, websites, or campaigns through buyer eyes.
Quick Start
Build ICP personas for [company]. Their site is [url].
With known ICPs:
Build personas for [company]. Their ICPs are: [ICP 1], [ICP 2], [ICP 3].
Inputs
| Input | Required | Source |
|---|---|---|
| Company name | Yes | User provides |
| Company URL | Recommended | Helps with research |
| Known ICPs | No | User provides, or discovered via research |
| Client context file | No | Any existing company context file, if available |
Process
Phase 1: Company Research
Understand what the company does and who they serve:
- WebFetch their website — homepage, product/solutions pages, pricing, "who it's for" pages
- WebSearch for:
- "[company] customers" / "[company] case studies"
- "[company] reviews" (G2, Capterra, TrustRadius)
- "[company] vs" (comparison searches reveal buyer segments)
- "[company] jobs" (who they're hiring to sell to / support)
- Extract signals:
- What problem do they solve?
- What's their pricing/packaging? (Signals ACV and buyer type)
- What industries/verticals do they serve?
- What company sizes do they target?
- What roles/titles appear in case studies and testimonials?
- What's their go-to-market motion? (Self-serve, sales-led, hybrid)
Phase 2: Identify ICP Segments
From the research, identify 4-6 distinct buyer segments. Each segment should represent a meaningfully different type of buyer — different role, different company profile, or different buying motivation.
For each segment, define:
| Attribute | Description |
|---|---|
| Segment name | Short label (e.g., "Enterprise IT Leader", "Startup Founder", "Agency Operator") |
| Role/titles | Typical job titles in this segment |
| Company profile | Size, stage, industry, tech stack |
| Core pain point | The #1 problem driving them to look for a solution |
| Buying trigger | What event makes them start searching NOW |
| Decision criteria | What matters most when evaluating (ranked) |
| Sophistication | How well they understand the problem space and solution landscape |
| Alternatives | What else they'd consider (competitors, DIY, status quo) |
| Segment size estimate | Rough sense of how big this segment is for the company (primary, secondary, emerging) |
Segment diversity rules:
- At least one technical buyer (evaluates capabilities, architecture, integrations)
- At least one business buyer (evaluates ROI, outcomes, competitive advantage)
- At least one skeptical profile (has been burned before, hard to convince)
- At least one junior/researcher (doing initial research for a decision-maker)
- Try to cover different company sizes if the company serves multiple tiers
Phase 3: Build Synthetic Personas
For each segment, create a detailed synthetic persona. The persona should feel like a real, specific person — not a marketing abstraction.
Persona structure:
{
"id": "persona-slug",
"name": "Jordan Chen",
"segment": "Enterprise IT Leader",
"title": "VP of Engineering",
"company": {
"type": "Mid-market SaaS company",
"size": "200-500 employees",
"stage": "Series B, scaling fast",
"industry": "Financial services technology"
},
"demographics": {
"experience_years": 12,
"reports_to": "CTO",
"team_size": 35,
"budget_authority": "$50K-200K without board approval"
},
"situation": "Jordan's team is growing faster than their tooling can support. They've been using a patchwork of internal scripts and are losing engineering hours to maintenance. The CTO has asked Jordan to evaluate modern solutions before next quarter's planning cycle.",
"pain_points": [
"Team productivity is dropping as they scale",
"Current tools don't integrate well",
"Onboarding new engineers takes too long"
],
"buying_trigger": "CTO mandate to evaluate solutions before Q3 planning",
"decision_criteria_ranked": [
"Enterprise security and compliance (SOC2, SSO)",
"Integration with existing stack (GitHub, Jira, Datadog)",
"Scalability — will this work at 2x team size?",
"Total cost of ownership, not just sticker price",
"Implementation timeline — needs to be live in 6 weeks"
],
"skepticism_profile": {
"trust_level": "Low — has been burned by vendor promises before",
"research_style": "Deep dive. Reads docs, checks GitHub issues, asks peers in Slack communities",
"key_objections": [
"Will this actually scale or will we outgrow it in a year?",
"What's the real implementation cost beyond the license?",
"How good is the support when things break at 2am?"
]
},
"technical_sophistication": "High — understands the technical landscape well, can evaluate architecture decisions, wants to see under the hood",
"language": {
"describes_problem_as": "We need to consolidate our toolchain and reduce operational overhead",
"searches_for": ["engineering productivity platform", "developer tools consolidation", "[competitor] alternative enterprise"],
"red_flag_words": ["revolutionary", "AI-powered", "seamless" — overpromising triggers skepticism],
"trust_signals": ["SOC2 badge", "customer logos in their industry", "transparent pricing", "public changelog"]
},
"evaluation_behavior": {
"first_visit": "Scans headline, checks if it's for their company size, looks for enterprise/security page",
"deep_evaluation": "Reads docs, checks integrations list, looks for case studies from similar companies",
"social_proof_needs": "Wants to see companies their size in their industry, not just FAANG logos",
"deal_breakers": ["No SSO/SAML", "No self-hosted option", "Pricing only available via sales call"]
}
}
Phase 4: Save Persona Assets
Save to the client directory as reusable assets:
personas.json — Machine-readable, all personas in an array. Save to the current working directory or wherever the user prefers:
{
"company": "Acme Corp",
"url": "https://acme.com",
"created": "2026-02-26",
"segment_count": 5,
"personas": [ ... ]
}
personas.md — Human-readable Markdown with all personas written out in prose form, easy to review and share.
segments.md — Summary table of all segments with key attributes, useful as a quick reference.
Output Summary
After building, present:
- Segment overview table — All segments with key attributes at a glance
- Persona summaries — 2-3 sentence summary of each persona
- Coverage check — Confirm diversity rules are met (technical, business, skeptical, researcher)
- Next steps — Suggest running
icp-website-auditor other skills that can use the personas
Tips
- Research depth matters. Spend real time in Phase 1. The better you understand the company's actual customers, the more realistic the personas. Don't just read the homepage — dig into reviews, case studies, job postings.
- Make personas specific. "Marketing Manager" is too generic. "Sarah, Senior Demand Gen Manager at a 50-person B2B SaaS startup who just lost her SDR team to budget cuts" tells you exactly how she'll evaluate a tool.
- Include the language dimension. How the persona describes their problem is often completely different from how the vendor describes their solution. This gap is where messaging fails.
- Skepticism is the most important trait. Every persona needs a clear skepticism profile. What would make them NOT buy? What's their default assumption about vendors?
- This skill has no code script. It's agent-executed using WebSearch and WebFetch. The structured process above guides the research and persona creation.
Dependencies
- Web search capability (for company and ICP research)
- Web fetch capability (for reading website pages)
- No API keys or paid tools required
| 1 | |
| 2 | name buyer-persona-generator |
| 3 | description > |
| 4 | Research a company's ideal customer profiles and build detailed synthetic buyer personas. |
| 5 | Identifies 4-6 distinct buyer segments through web research, then creates rich, |
| 6 | realistic personas with demographics, motivations, skepticism profiles, decision |
| 7 | criteria, and language patterns. Use when you need to understand who your buyers are |
| 8 | at a deep level — their motivations, objections, and how they evaluate solutions. |
| 9 | tags [research] |
| 10 | |
| 11 | |
| 12 | # ICP Persona Builder |
| 13 | |
| 14 | Research a company's buyer segments and build detailed synthetic personas that model their ideal customers. These personas become a reusable client asset — once built, any skill can load them to evaluate content, messaging, websites, or campaigns through buyer eyes. |
| 15 | |
| 16 | ## Quick Start |
| 17 | |
| 18 | |
| 19 | Build ICP personas for [company]. Their site is [url]. |
| 20 | |
| 21 | |
| 22 | With known ICPs: |
| 23 | |
| 24 | Build personas for [company]. Their ICPs are: [ICP 1], [ICP 2], [ICP 3]. |
| 25 | |
| 26 | |
| 27 | ## Inputs |
| 28 | |
| 29 | | Input | Required | Source | |
| 30 | |-------|----------|--------| |
| 31 | | **Company name** | Yes | User provides | |
| 32 | | **Company URL** | Recommended | Helps with research | |
| 33 | | **Known ICPs** | No | User provides, or discovered via research | |
| 34 | | **Client context file** | No | Any existing company context file, if available | |
| 35 | |
| 36 | ## Process |
| 37 | |
| 38 | ### Phase 1: Company Research |
| 39 | |
| 40 | Understand what the company does and who they serve: |
| 41 | |
| 42 | **WebFetch their website** — homepage, product/solutions pages, pricing, "who it's for" pages |
| 43 | **WebSearch** for: |
| 44 | "[company] customers" / "[company] case studies" |
| 45 | "[company] reviews" (G2, Capterra, TrustRadius) |
| 46 | "[company] vs" (comparison searches reveal buyer segments) |
| 47 | "[company] jobs" (who they're hiring to sell to / support) |
| 48 | **Extract signals:** |
| 49 | What problem do they solve? |
| 50 | What's their pricing/packaging? (Signals ACV and buyer type) |
| 51 | What industries/verticals do they serve? |
| 52 | What company sizes do they target? |
| 53 | What roles/titles appear in case studies and testimonials? |
| 54 | What's their go-to-market motion? (Self-serve, sales-led, hybrid) |
| 55 | |
| 56 | ### Phase 2: Identify ICP Segments |
| 57 | |
| 58 | From the research, identify **4-6 distinct buyer segments**. Each segment should represent a meaningfully different type of buyer — different role, different company profile, or different buying motivation. |
| 59 | |
| 60 | For each segment, define: |
| 61 | |
| 62 | | Attribute | Description | |
| 63 | |-----------|-------------| |
| 64 | | **Segment name** | Short label (e.g., "Enterprise IT Leader", "Startup Founder", "Agency Operator") | |
| 65 | | **Role/titles** | Typical job titles in this segment | |
| 66 | | **Company profile** | Size, stage, industry, tech stack | |
| 67 | | **Core pain point** | The #1 problem driving them to look for a solution | |
| 68 | | **Buying trigger** | What event makes them start searching NOW | |
| 69 | | **Decision criteria** | What matters most when evaluating (ranked) | |
| 70 | | **Sophistication** | How well they understand the problem space and solution landscape | |
| 71 | | **Alternatives** | What else they'd consider (competitors, DIY, status quo) | |
| 72 | | **Segment size estimate** | Rough sense of how big this segment is for the company (primary, secondary, emerging) | |
| 73 | |
| 74 | **Segment diversity rules:** |
| 75 | At least one **technical** buyer (evaluates capabilities, architecture, integrations) |
| 76 | At least one **business** buyer (evaluates ROI, outcomes, competitive advantage) |
| 77 | At least one **skeptical** profile (has been burned before, hard to convince) |
| 78 | At least one **junior/researcher** (doing initial research for a decision-maker) |
| 79 | Try to cover different company sizes if the company serves multiple tiers |
| 80 | |
| 81 | ### Phase 3: Build Synthetic Personas |
| 82 | |
| 83 | For each segment, create a detailed synthetic persona. The persona should feel like a real, specific person — not a marketing abstraction. |
| 84 | |
| 85 | **Persona structure:** |
| 86 | |
| 87 | |
| 88 | { |
| 89 | "id": "persona-slug", |
| 90 | "name": "Jordan Chen", |
| 91 | "segment": "Enterprise IT Leader", |
| 92 | "title": "VP of Engineering", |
| 93 | "company": { |
| 94 | "type": "Mid-market SaaS company", |
| 95 | "size": "200-500 employees", |
| 96 | "stage": "Series B, scaling fast", |
| 97 | "industry": "Financial services technology" |
| 98 | }, |
| 99 | "demographics": { |
| 100 | "experience_years": 12, |
| 101 | "reports_to": "CTO", |
| 102 | "team_size": 35, |
| 103 | "budget_authority": "$50K-200K without board approval" |
| 104 | }, |
| 105 | "situation": "Jordan's team is growing faster than their tooling can support. They've been using a patchwork of internal scripts and are losing engineering hours to maintenance. The CTO has asked Jordan to evaluate modern solutions before next quarter's planning cycle.", |
| 106 | "pain_points": [ |
| 107 | "Team productivity is dropping as they scale", |
| 108 | "Current tools don't integrate well", |
| 109 | "Onboarding new engineers takes too long" |
| 110 | ], |
| 111 | "buying_trigger": "CTO mandate to evaluate solutions before Q3 planning", |
| 112 | "decision_criteria_ranked": [ |
| 113 | "Enterprise security and compliance (SOC2, SSO)", |
| 114 | "Integration with existing stack (GitHub, Jira, Datadog)", |
| 115 | "Scalability — will this work at 2x team size?", |
| 116 | "Total cost of ownership, not just sticker price", |
| 117 | "Implementation timeline — needs to be live in 6 weeks" |
| 118 | ], |
| 119 | "skepticism_profile": { |
| 120 | "trust_level": "Low — has been burned by vendor promises before", |
| 121 | "research_style": "Deep dive. Reads docs, checks GitHub issues, asks peers in Slack communities", |
| 122 | "key_objections": [ |
| 123 | "Will this actually scale or will we outgrow it in a year?", |
| 124 | "What's the real implementation cost beyond the license?", |
| 125 | "How good is the support when things break at 2am?" |
| 126 | ] |
| 127 | }, |
| 128 | "technical_sophistication": "High — understands the technical landscape well, can evaluate architecture decisions, wants to see under the hood", |
| 129 | "language": { |
| 130 | "describes_problem_as": "We need to consolidate our toolchain and reduce operational overhead", |
| 131 | "searches_for": ["engineering productivity platform", "developer tools consolidation", "[competitor] alternative enterprise"], |
| 132 | "red_flag_words": ["revolutionary", "AI-powered", "seamless" — overpromising triggers skepticism], |
| 133 | "trust_signals": ["SOC2 badge", "customer logos in their industry", "transparent pricing", "public changelog"] |
| 134 | }, |
| 135 | "evaluation_behavior": { |
| 136 | "first_visit": "Scans headline, checks if it's for their company size, looks for enterprise/security page", |
| 137 | "deep_evaluation": "Reads docs, checks integrations list, looks for case studies from similar companies", |
| 138 | "social_proof_needs": "Wants to see companies their size in their industry, not just FAANG logos", |
| 139 | "deal_breakers": ["No SSO/SAML", "No self-hosted option", "Pricing only available via sales call"] |
| 140 | } |
| 141 | } |
| 142 | |
| 143 | |
| 144 | ### Phase 4: Save Persona Assets |
| 145 | |
| 146 | Save to the client directory as reusable assets: |
| 147 | |
| 148 | **`personas.json`** — Machine-readable, all personas in an array. Save to the current working directory or wherever the user prefers: |
| 149 | |
| 150 | { |
| 151 | "company": "Acme Corp", |
| 152 | "url": "https://acme.com", |
| 153 | "created": "2026-02-26", |
| 154 | "segment_count": 5, |
| 155 | "personas": [ ... ] |
| 156 | } |
| 157 | |
| 158 | |
| 159 | **`personas.md`** — Human-readable Markdown with all personas written out in prose form, easy to review and share. |
| 160 | |
| 161 | **`segments.md`** — Summary table of all segments with key attributes, useful as a quick reference. |
| 162 | |
| 163 | ## Output Summary |
| 164 | |
| 165 | After building, present: |
| 166 | **Segment overview table** — All segments with key attributes at a glance |
| 167 | **Persona summaries** — 2-3 sentence summary of each persona |
| 168 | **Coverage check** — Confirm diversity rules are met (technical, business, skeptical, researcher) |
| 169 | **Next steps** — Suggest running `icp-website-audit` or other skills that can use the personas |
| 170 | |
| 171 | ## Tips |
| 172 | |
| 173 | **Research depth matters.** Spend real time in Phase 1. The better you understand the company's actual customers, the more realistic the personas. Don't just read the homepage — dig into reviews, case studies, job postings. |
| 174 | **Make personas specific.** "Marketing Manager" is too generic. "Sarah, Senior Demand Gen Manager at a 50-person B2B SaaS startup who just lost her SDR team to budget cuts" tells you exactly how she'll evaluate a tool. |
| 175 | **Include the language dimension.** How the persona describes their problem is often completely different from how the vendor describes their solution. This gap is where messaging fails. |
| 176 | **Skepticism is the most important trait.** Every persona needs a clear skepticism profile. What would make them NOT buy? What's their default assumption about vendors? |
| 177 | **This skill has no code script.** It's agent-executed using WebSearch and WebFetch. The structured process above guides the research and persona creation. |
| 178 | |
| 179 | ## Dependencies |
| 180 | |
| 181 | Web search capability (for company and ICP research) |
| 182 | Web fetch capability (for reading website pages) |
| 183 | No API keys or paid tools required |
| 184 |