Stats
Actions
Tags
From service-design
Use when mapping how a service actually works — frontstage/backstage/support lanes from code, docs, and operational knowledge
How this skill is triggered — by the user, by Claude, or both
Slash command
/service-design:service-blueprintThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Core principle:** A blueprint connects what users experience to what the organization produces. Touchpoints are commitments, not screens.
Core principle: A blueprint connects what users experience to what the organization produces. Touchpoints are commitments, not screens.
Read routes, controllers, models, mailers, and jobs to extract the operational backbone: customer actions, frontstage responses, backstage processes, support systems. Code reveals what happens; it cannot reveal what it feels like or why the org chose this shape. Ask targeted questions for those layers. Accept docs, transcripts, and URLs as supplementary sources — ingest them, don't summarize them.
Pick one scenario and one actor. Define start and end conditions from the actor's POV. Combine three lenses to find the right boundary:
| Lens | What it prevents |
|---|---|
| Lifecycle sequencing (pre/during/post) | Optimizing one moment while degrading the surrounding system |
| Context of use (environment, stakes, frequency) | Designing for a user who doesn't exist |
| JTBD forces (functional, social, emotional) | Reducing the service to task completion |
| Line | What it reveals |
|---|---|
| Interaction | Where the user touches the org — every crossing is a moment of truth |
| Visibility | What's hidden vs. shown — a design choice, not just operational fact |
| Internal interaction | Where bottlenecks and systemic failures hide |
Tag every claim: [confirmed] (verified in code or docs), [hypothesis] (inferred from patterns), or [gap] (unknown). Separate observation from inference. For each hypothesis, note what would confirm it — a stakeholder interview, a log query, a support ticket search.
Write to docs/service-design/<slice>/blueprint.md using the template at service-design/templates/blueprint.md. Populate the Service Slice table, Blueprint Lanes, Moments of Truth, and Failure Modes sections.
service-design:empathy-analysis produces the emotional/informational layer this blueprint references. service-design:journey-map sequences the same service across time and channels. Use all three for a complete picture.
npx claudepluginhub zemptime/zemptime-marketplace --plugin service-designMaps, analyzes, and redesigns product systems—service blueprints, ecosystem maps, process architecture, and dependency diagrams. Use when investigating structural issues behind user experiences.
Designs end-to-end service experiences via customer journey maps, service blueprints, touchpoint analysis, and backstage workflows for digital/hybrid services.
Researches codebase systems and generates or updates technical blueprint docs in repo root blueprints/ directory with architecture diagrams and data flows.