user-journey-mapping

Use when running /ux:user-journey, after a persona exists — walks that persona through a scenario end to end. Philosophy adapted from the toolkit's UX extension (Business Goal -> Persona -> Journey -> Wireframe -> Prototype).

インストールへ移動

リポジトリ: KiemVM/AI-SDLC
ソースの最終更新活動: 2026年7月23日 10:04
検出された SKILL.md の言語: 英語
スター: 5
フォーク: 0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/KiemVM/AI-SDLC --skill user-journey-mapping

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

検索に戻るインストールに戻る

decision-capture

Use when running /decide, or whenever a product/technical decision changes something already written (a spec, plan, architecture doc) mid-work — captures it as an ADR and finds what needs to be updated downstream. Philosophy adapted from GitHub Spec-Kit's ADR discipline and BMAD-METHOD's documentation-first governance.

2026-07-29

implementation-planning

Use when running /spec:plan, after a Specification.md exists and before task breakdown — turns approved requirements into a technical approach, file structure, and testing strategy. Philosophy adapted from GitHub Spec-Kit's plan phase and BMAD-METHOD's architecture discipline.

2026-07-24

reviewing-code

Use when running /engineering:review, or whenever asked to review a diff or PR for bugs and spec/constitution adherence. If the host project already has Anthropic's official code-review plugin configured, prefer that instead. Philosophy adapted from Superpowers' code-review discipline.

2026-07-24

このリポジトリのすべてを見る

User Journey Mapping

A journey is the bridge between a persona (who) and wireframes (what screens). It exists to answer: given this persona's actual goals and pain points, what does success look like step-by-step, and where could it fail?

Process

Start from the persona's goal, not a feature. The journey should read as "the persona wants X, so they do..." not "the app has a flow where..."

Walk it step by step, naming the touchpoint (screen, notification, external channel) at each step — vague steps like "user interacts with the app" produce vague wireframes later.

Mark the emotional arc. Where does friction peak? Where's the moment of relief or accomplishment? This tells /ux:wireframe where to invest the most design care.

Identify drop-off risk per step. A step with high drop-off risk is a design priority, not an afterthought.

Define success concretely, bounded by time or step count where possible, and tied back to the persona's original goal.

List candidate screens as a bridge to /ux:wireframe — names only, no layout.

Self-review checklist

Every step ties back to the persona's stated goal.

Each step names a concrete touchpoint, not a vague interaction.

At least one drop-off risk is identified, or the journey is trivial enough that none exists (state that explicitly).

Success criteria are concrete and traceable to the persona's goal.

Red flags

Red flag

Why it matters

Steps describe UI ("clicks the blue button") instead of intent

Premature UI commitment before wireframing has happened

No step is marked as risky/frustrating

Either the journey is genuinely trivial, or friction points were missed

The journey doesn't match anything in the persona's goals/pain points

Likely designed from assumption rather than the actual persona document