Customer Journey Map Skill
A living customer journey map that lives in your conversation — not in a Figma file nobody opens again.
Most journey maps die the week they're made: a beautiful artifact, frozen, stale by
the next sprint. This skill makes the map a living document your AI builds, updates,
and reshapes with you across the whole life of a project — then renders it for whoever's
in the room. You just talk; it does the structure.
▶ Explore the live showcase →
What it does — by where you are in the work
You don't invoke modes or learn commands. You describe your situation, and the skill
meets you where you are:
| Where you are | What you say | What the skill does |
|---|
| Kicking off — a fuzzy idea of a user flow | "Map how a first-time buyer sets up online payments." | Builds a structured journey from the conversation — milestone by milestone, no form to fill. |
| Something changed — new research, a shipped feature | "We just launched instant verification — fold it in." | Updates with a diff: what changed, why, and the downstream steps it touches — never a silent redraw. |
| Bringing others along — a kickoff, a VP, the dev team | "Turn this into something for Monday's kickoff." | Renders the same map for that audience — a story, a one-pager, a spec, or an interactive map. |
| The map has matured — what now? | "Where's it weak, and what should we map next?" | Reviews it for soft spots and proposes the adjacent journeys worth mapping. |
What you're actually working with
A real, structured map — written from a conversation. You describe the flow in plain
words; the skill maintains a canonical journey file: milestones, steps, and the fields
that actually matter on each one. No diagramming, no template.
### Step: wait-in-silence
- persona: [Maya, Recruiter, Hiring Manager, ATS]
- emotion: Hope curdling into anxiety, then resignation
- emotionValence: -2
- waitTime: Days to several weeks, often indefinite
- handoff: Recruiter → Hiring Manager for shortlist review
- bottleneck: Hiring Manager review capacity
- lineOfVisibility: Status changes exist inside the ATS and are deliberately not exposed
- painPoint: No status, no timeline, no closure
- momentOfTruth: This silence is the make-or-break of the whole experience
- priority: must-fix
A ~100-field vocabulary you never have to learn. Underneath sits the language of
service design — emotion, channels, backstage systems, failure modes, metrics,
accessibility, and more (NN/g, Forrester, Shostack's service blueprints, Jobs-to-be-Done).
But you never pick from a menu: mention a frustrating wait and duration + painPoint
appear; describe a backend bot and the backstage layer shows up. The depth is there when
the conversation calls for it, invisible when it doesn't.
A living document. The map is a file that persists across sessions and grows by diff.
Come back in three weeks and it's still your expert collaborator who's been on the project
the whole time — not a blank slate.
Provenance, automatically. Every field quietly tracks what you asserted, what's
backed by evidence you cited, and what the model inferred itself. So when it builds you
a brief, it won't dress a guess up as a statistic — it flags the hypothesis and tells you
to go measure it.
Express it for any audience
Once the map exists, the same understanding renders for whoever needs it. Everything below
comes from one journey file — fifteen steps, read for different rooms. (Full versions in
demos/gallery/.)
Storyline — makes a team feel the experience. For kickoffs, empathy-building.
Maya has a job. That is the first thing to understand about her, because it changes
everything that follows… every single thing she does about our role happens in the margins
of a day that already belongs to someone else.
…At 10:20 she hits Submit. And here is the thing worth noticing: she feels good.
That is the emotional high point of this entire journey, and it happens forty-three
minutes in, with everything still ahead of her.1
One-page brief — for a VP with 90 seconds and a decision to make.
Ask: Approve three changes — surface real status, disclose the AI screen, auto-close
dead applications.
The problem in one line: Candidates who pass our screen enter a queue with no status,
no timeline, and no guaranteed ending — and the most common way our process concludes is
that it doesn't.
Engineering handoff — spec-shaped, for the team that has to build it.
Acceptance criteria
Interactive HTML — self-contained, explorable maps. Rendering is a choice, not a fixed
output; you just ask. All nine are live — open each one from
demos/gallery/, or explore the example journeys on the
showcase site.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
