Stats
Actions
Tags
From service-design
Use when defining who the actors in a service are — segments, JTBD forces, context, constraints, and relationships between actors
How this skill is triggered — by the user, by Claude, or both
Slash command
/service-design:actor-profileThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Core principle:** Every artifact references actors. If actors aren't defined, every artifact invents its own definition. Actor profiles are the shared foundation — run this skill before all others.
Core principle: Every artifact references actors. If actors aren't defined, every artifact invents its own definition. Actor profiles are the shared foundation — run this skill before all others.
Map four forces per actor. These explain why someone adopts or abandons a service, distinct from what they experience once using it:
| Force | Question |
|---|---|
| Push | What's broken about their current solution? |
| Pull | What about this service looks better? |
| Anxiety | What makes them hesitate? |
| Habit | What keeps them doing it the old way? |
Extend to functional, social, and emotional goals. Task completion alone misses half the switching calculus.
Environment, stakes, frequency, constraints. A user on a phone in a noisy shop with 30 seconds is not the same actor as one at a desk with an hour. Make these explicit.
Customer ↔ frontline staff ↔ back-office ↔ external partners. Map who serves whom, who depends on whom, who sets terms. One actor's constraint is often another's backstage action.
Code reveals what the system assumes about users — roles, permissions, workflows. Transcripts reveal what they actually think and struggle with. Business docs reveal intended segments. Accept all three; triangulate. Never invent quotes or emotions.
One profile per actor type. Multiple actors = multiple files in the same slice.
Tag every claim: [confirmed] (verified in code, analytics, or direct quote), [hypothesis] (inferred from patterns), or [gap] (unknown). Segments from analytics = [confirmed]. Inferred motivations = [hypothesis]. For each hypothesis, note what would confirm.
Write to docs/service-design/<slice>/actor-profile-<name>.md using the template at service-design/templates/actor-profile.md. One file per actor type.
service-design:empathy-analysis deepens the emotional layer for a single actor this profile defines. service-design:service-blueprint maps the service structure actors move through. service-design:journey-map sequences their experience across time.
npx claudepluginhub zemptime/zemptime-marketplace --plugin service-designGenerates structured personas and JTBD analysis with ODI job step tables, pain point mapping, and quantified success metrics. Use for Phase 1 user definition.
Use this skill when the user asks to "create user personas", "develop personas", "write a persona", "define our users", "user profile", "who is our user", "help me define the target user", "create a user archetype", or wants to build or update structured user persona definitions grounded in research or known user characteristics.
Defines who you're building for by producing PERSONAS.md with JTBD proto-personas and an anti-persona. Reverse-engineers personas from existing codebase and artifacts (refine mode) or interviews you from scratch (create mode).