菜单
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.
