القائمة
Use when mapping what a user experiences over time — actions, thoughts, emotions, touchpoints across pre-service, during-service, and post-service stages
التثبيت باستخدام 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 | journey-map |
| description | Use when mapping what a user experiences over time — actions, thoughts, emotions, touchpoints across pre-service, during-service, and post-service stages |
Core principle: A journey map is a user-centered narrative. It answers "what is this person going through?" not "how does our system work?" — that's the blueprint's job.
Read code (routes, controllers, mailers, views) to extract touchpoints and channels. Read transcripts and support tickets to extract thoughts and emotions. Code reveals what the user encounters; it cannot reveal what they think or feel. Accept docs, pasted content, URLs — ingest, don't summarize.
One scenario, one actor. Define start and end from the actor's POV. Three lenses:
| Lens | What it prevents |
|---|---|
| Lifecycle sequencing (pre/during/post) | Optimizing one moment while degrading surroundings |
| Context of use (environment, stakes, frequency) | Designing for a user who doesn't exist |
| JTBD forces (functional, social, emotional) | Reducing the journey to task completion |
Three stages: pre-service -> during-service -> post-service. Making before-and-after visible prevents local optimization. Per stage, capture:
| Dimension | Guidance |
|---|---|
| Actions | Observable behavior |
| Touchpoints + channels | Extract from code |
| Thoughts | Verbatim quotes when available; mark inferred |
| Emotions | Grounded in research, not invented — name + valence |
| Pain points | Friction, confusion, anxiety |
| Opportunities | Unmet needs |
Tag every claim: [confirmed] (verified in code, transcript, or docs), [hypothesis] (inferred), [gap] (unknown). Verbatim quotes = [confirmed]. Inferred emotions = [hypothesis]. Missing stages = [gap]. Note what would confirm each hypothesis.
Journey map = user side. Blueprint = org side. Both needed. Two failure modes to prevent:
Write to docs/service-design/<slice>/journey-map.md using the template at service-design/templates/journey-map.md.
service-design:service-blueprint for the org-side view. service-design:empathy-analysis for the deeper emotional/informational layer underlying thoughts and emotions here.
