/proto-persona
Create a proto-persona from current research, market signals, and team knowledge. Use when you need a working customer profile before deeper validation.
$ npx -y skills add getcrew44/crew44 --skill proto-persona --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/proto-persona
Context preview
The summary Claude sees to decide when to auto-load this skill.
Create a proto-persona from current research, market signals, and team knowledge. Use when you need a working customer profile before deeper validation.
SKILL.md
proto-persona.SKILL.mdname: proto-persona
description: Create a proto-persona from current research, market signals, and team knowledge. Use when you need a working customer profile before deeper validation.
intent: >-
Create an initial, assumption-based persona profile that synthesizes available user research, market data, and stakeholder knowledge into a working hypothesis about your target user. Use this to align teams early in product development, guide initial design decisions, and identify gaps in understanding that require validation through research.
type: component
Purpose
Create an initial, assumption-based persona profile that synthesizes available user research, market data, and stakeholder knowledge into a working hypothesis about your target user. Use this to align teams early in product development, guide initial design decisions, and identify gaps in understanding that require validation through research.
This is not a validated persona—it's a "proto" (prototype) persona that evolves as you learn more. Think of it as a structured placeholder that prevents design-by-committee while acknowledging you don't have all the answers yet.
Key Concepts
What is a Proto-Persona?
A proto-persona is a lightweight, hypothesis-driven persona created from:
- **Existing research:** User interviews, surveys, analytics (if available)
- **Market data:** Industry reports, competitor analysis, demographic trends
- **Stakeholder knowledge:** Sales, support, and team insights
- **Informed assumptions:** Best guesses that need validation
Proto vs. Validated Persona
| Proto-Persona | Validated Persona | |---------------|-------------------| | Created in hours/days | Created over weeks/months | | Based on assumptions + limited research | Based on extensive user research | | Used to align teams early | Used to guide detailed design | | Evolves rapidly | Stable over time | | Good enough to start | High confidence |
Why Use Proto-Personas?
- **Speed:** Align teams quickly without waiting for months of research
- **Focus:** Provides a shared reference point for "who we're building for"
- **Hypothesis framing:** Makes assumptions explicit, which can then be validated
- **Prevents generic design:** "Design for everyone" = design for no one
Anti-Patterns (What This Is NOT)
- **Not validated research:** Don't treat it as fact—it's a hypothesis
- **Not a replacement for user research:** Use it to *guide* research, not avoid it
- **Not demographic data alone:** Age and location don't explain behavior
- **Not permanent:** Proto-personas should evolve as you learn
When to Use This
- Early-stage product development (before extensive user research)
- Kicking off a new feature or pivot
- Aligning stakeholders on target users
- Identifying research gaps (who do we need to interview?)
When NOT to Use This
- After you've done extensive user research (create a validated persona instead)
- For mature products with known user segments (you should already have validated personas)
- As a substitute for quantitative data (proto-personas inform research; research validates them)
---
Application
Use `template.md` for the full fill-in structure.
Step 1: Gather Available Context
Before creating a proto-persona, collect:
- **User research:** Interview notes, survey results, support tickets
- **Analytics:** Usage data, demographics, behavioral patterns
- **Market data:** Industry reports, competitor user bases
- **Stakeholder insights:** Sales/support/CS teams who interact with users
- **Product context:** What problem are you solving? (reference `skills/problem-statement/SKILL.md`)
**If missing context:** Don't fabricate—note gaps and plan research to fill them.
---
Step 2: Define the Persona's Identity
Name
Give the persona an **alliterative, memorable name** (makes it easier to reference).
### Name
- [Alliterative name, e.g., "Manager Mike," "Startup Sarah," "Enterprise Emma"]
**Quality checks:**
- **Memorable:** Can the team recall it easily?
- **Not generic:** Avoid "User 1" or "Persona A"
---
Bio & Demographics
Describe who this person is in the real world.
### Bio & Demographics
- [Age range]
- [Geographic location]
- [Social status (married, single, family, etc.)]
- [Online presence (active on LinkedIn, avoids social media, etc.)]
- [Leisure activities]
- [Career status (job title, industry, seniority)]
**Quality checks:**
- **Behavioral, not just demographic:** Don't stop at "30-40 years old, lives in SF"—add "Works remotely, active in Slack communities, juggles 3 side projects"
- **Context-relevant:** Only include demographics that influence product decisions
**Example:**
- "35-45 years old, lives in urban areas (NYC, SF, Austin)"
- "Director-level at mid-sized tech companies (50-500 employees)"
- "Active on LinkedIn and Twitter, attends 2-3 conferences per year"
- "Married with young kids, values work-life balance"
- "Plays rec sports on weekends, listens to business podcasts during commute"
---
Step 3: Capture Their Voice
Quotes
Use real or representative quotes that reveal how they think and speak.
### Quotes
- "[Quote 1 revealing what they say, feel, or think]"
- "[Quote 2 revealing frustrations or motivations]"
- "[Quote 3 revealing attitudes or beliefs]"
**Quality checks:**
- **Authentic:** Use real quotes from interviews/support tickets if available
- **Revealing:** Quotes should expose mindset, not just facts ("I need better tools" is weak; "I'm drowning in manual work and can't focus on strategy" is strong)
**Example:**
- "I spend 10 hours a week in status meetings that could be emails."
- "I'm tired of tools that promise automation but require a developer to set up."
- "My team expects me to have answers immediately, but I'm constantly searching for data."
---
Step 4: Document Their Context
Pains
What problems or frustrations does this persona experience? (Reference `skill
Read more
name: proto-persona description: Create a proto-persona from current research, market signals, and team knowledge. Use when you need a working customer profile before deeper validation. intent: >- Create an initial, assumption-based persona profile that synthesizes available user research, market data, and stakeholder knowledge into a working hypothesis about your target user. Use this to align teams early in product development, guide initial design decisions, and identify gaps in understanding that require validation through research. type: component
Purpose
Create an initial, assumption-based persona profile that synthesizes available user research, market data, and stakeholder knowledge into a working hypothesis about your target user. Use this to align teams early in product development, guide initial design decisions, and identify gaps in understanding that require validation through research.
This is not a validated persona—it's a "proto" (prototype) persona that evolves as you learn more. Think of it as a structured placeholder that prevents design-by-committee while acknowledging you don't have all the answers yet.
Key Concepts
What is a Proto-Persona?
A proto-persona is a lightweight, hypothesis-driven persona created from:
- **Existing research:** User interviews, surveys, analytics (if available)
- **Market data:** Industry reports, competitor analysis, demographic trends
- **Stakeholder knowledge:** Sales, support, and team insights
- **Informed assumptions:** Best guesses that need validation
Proto vs. Validated Persona
| Proto-Persona | Validated Persona | |---------------|-------------------| | Created in hours/days | Created over weeks/months | | Based on assumptions + limited research | Based on extensive user research | | Used to align teams early | Used to guide detailed design | | Evolves rapidly | Stable over time | | Good enough to start | High confidence |
Why Use Proto-Personas?
- **Speed:** Align teams quickly without waiting for months of research
- **Focus:** Provides a shared reference point for "who we're building for"
- **Hypothesis framing:** Makes assumptions explicit, which can then be validated
- **Prevents generic design:** "Design for everyone" = design for no one
Anti-Patterns (What This Is NOT)
- **Not validated research:** Don't treat it as fact—it's a hypothesis
- **Not a replacement for user research:** Use it to *guide* research, not avoid it
- **Not demographic data alone:** Age and location don't explain behavior
- **Not permanent:** Proto-personas should evolve as you learn
When to Use This
- Early-stage product development (before extensive user research)
- Kicking off a new feature or pivot
- Aligning stakeholders on target users
- Identifying research gaps (who do we need to interview?)
When NOT to Use This
- After you've done extensive user research (create a validated persona instead)
- For mature products with known user segments (you should already have validated personas)
- As a substitute for quantitative data (proto-personas inform research; research validates them)
---
Application
Use `template.md` for the full fill-in structure.
Step 1: Gather Available Context
Before creating a proto-persona, collect:
- **User research:** Interview notes, survey results, support tickets
- **Analytics:** Usage data, demographics, behavioral patterns
- **Market data:** Industry reports, competitor user bases
- **Stakeholder insights:** Sales/support/CS teams who interact with users
- **Product context:** What problem are you solving? (reference `skills/problem-statement/SKILL.md`)
**If missing context:** Don't fabricate—note gaps and plan research to fill them.
---
Step 2: Define the Persona's Identity
Name
Give the persona an **alliterative, memorable name** (makes it easier to reference).
### Name - [Alliterative name, e.g., "Manager Mike," "Startup Sarah," "Enterprise Emma"]
**Quality checks:**
- **Memorable:** Can the team recall it easily?
- **Not generic:** Avoid "User 1" or "Persona A"
---
Bio & Demographics
Describe who this person is in the real world.
### Bio & Demographics - [Age range] - [Geographic location] - [Social status (married, single, family, etc.)] - [Online presence (active on LinkedIn, avoids social media, etc.)] - [Leisure activities] - [Career status (job title, industry, seniority)]
**Quality checks:**
- **Behavioral, not just demographic:** Don't stop at "30-40 years old, lives in SF"—add "Works remotely, active in Slack communities, juggles 3 side projects"
- **Context-relevant:** Only include demographics that influence product decisions
**Example:**
- "35-45 years old, lives in urban areas (NYC, SF, Austin)"
- "Director-level at mid-sized tech companies (50-500 employees)"
- "Active on LinkedIn and Twitter, attends 2-3 conferences per year"
- "Married with young kids, values work-life balance"
- "Plays rec sports on weekends, listens to business podcasts during commute"
---
Step 3: Capture Their Voice
Quotes
Use real or representative quotes that reveal how they think and speak.
### Quotes - "[Quote 1 revealing what they say, feel, or think]" - "[Quote 2 revealing frustrations or motivations]" - "[Quote 3 revealing attitudes or beliefs]"
**Quality checks:**
- **Authentic:** Use real quotes from interviews/support tickets if available
- **Revealing:** Quotes should expose mindset, not just facts ("I need better tools" is weak; "I'm drowning in manual work and can't focus on strategy" is strong)
**Example:**
- "I spend 10 hours a week in status meetings that could be emails."
- "I'm tired of tools that promise automation but require a developer to set up."
- "My team expects me to have answers immediately, but I'm constantly searching for data."
---
Step 4: Document Their Context
Pains
What problems or frustrations does this persona experience? (Reference `skill
Orchestrate a crew of specialist AI agents in one local-first workspace. Each role on its best model, with memory and skills that compound. Free, MIT.
Repo: getcrew44/crew44
Other skills on crew44.
- /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Open skill - /finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Open skill - /receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Open skill - /requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Open skill - /systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Open skill

