القائمة
Use when you need to understand what users believe, feel, and predict — builds empathy maps with emotional/informational layers from research, transcripts, and code
التثبيت باستخدام 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 | empathy-analysis |
| description | Use when you need to understand what users believe, feel, and predict — builds empathy maps with emotional/informational layers from research, transcripts, and code |
Core principle: True empathy = cognitive model of the user's emotional state + what they believe is happening. The test: "Does this make sense for someone who doesn't know what's coming next?"
| Layer | What it captures | Key question |
|---|---|---|
| Informational | What users believe is happening vs. what's actually happening. What they need to predict next. Whether labels/cues help them estimate a path's value (information scent). | Where will the mental model diverge from system reality? |
| Emotional | Baseline emotion before contact, peak intensity during, ending impression (peak-end rule). Which backstage conditions create negative peaks. | What will they remember feeling? |
Accept transcripts, interviews, pasted content, files, and URLs as input — ingest them, don't summarize them. Code reveals what the system actually does; contrast that with what users believe. Populate says/thinks/does/feels quadrants from observed evidence. Never invent quotes or emotions.
Tag every claim: [confirmed] (direct quote or observed behavior), [hypothesis] (inferred from patterns), or [gap] (unknown). Flag inferred emotions explicitly — "User likely feels frustrated [hypothesis]" not "User feels frustrated." For each hypothesis, note what evidence would confirm or refute it.
Cognitive empathy predicts confusion, fear, and skepticism. If your empathy map cannot predict where users will be confused, it is decorative. Walk each row of the Informational Empathy table and ask: given what they believe, what will they expect next? If the system does something different, that is a failure point.
Write to docs/service-design/<slice>/empathy-map.md using the template at service-design/templates/empathy-map.md. Populate the Actor table, Quadrants, Emotional Arc, Informational Empathy, and Information Scent sections.
service-design:service-blueprint maps the backstage conditions that create the peaks this analysis identifies. service-design:journey-map sequences the same experience across time and channels.
