메뉴
Use when defining who the actors in a service are — segments, JTBD forces, context, constraints, and relationships between actors
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when writing Rails controllers or implementing state changes - enforces resource extraction, thin controllers delegating to models, params.expect, and controller concerns for scoping
Use when designing database schema, writing migrations, or making data storage decisions - enforces UUIDs, account_id multi-tenancy, no foreign keys, and proper index patterns
Use when writing Hotwire (Turbo/Stimulus) code in Rails - enforces dom_id helpers, morph updates, focused Stimulus controllers, and JavaScript private methods
Use when writing background jobs or async operations - enforces thin job wrappers (3-5 lines) that delegate to models using _later/_now naming pattern
Use when writing Rails models - enforces state-as-records not booleans, concerns as adjectives namespaced under model, and concern extraction triggers
Use when naming classes, methods, routes in vanilla Rails codebases - enforces concern adjectives (-able/-ible only), no bangs for state, resource naming cascade, and commit message format
| name | actor-profile |
| description | Use when defining who the actors in a service are — segments, JTBD forces, context, constraints, and relationships between actors |
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.
