From product-owner
Create a user story map — a spatial arrangement of stories along a narrative backbone. Produces a backbone of user activities, a walking skeleton, and release slices. Use when planning a new feature area, epic, or release to ensure coverage and sequence.
npx claudepluginhub hpsgd/turtlestack --plugin product-ownerThis skill is limited to using the following tools:
Create a user story map for $ARGUMENTS.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Create a user story map for $ARGUMENTS.
Follow every step below. The output must be a complete story map that a team can use to plan releases — not a flat backlog list.
Before mapping any stories, establish the framing:
Document:
| Field | Description |
|---|---|
| User | [Specific role + context] |
| Goal | [End-to-end outcome] |
| Journey start | [First action] |
| Journey end | [Success state] |
| Scope boundary | [What is explicitly excluded from this map] |
The backbone is the sequence of high-level activities the user performs to achieve their goal. Activities read left-to-right as a narrative.
Create Posting → Source Candidates → Review Applications → Interview → Evaluate → Hire
Write each activity with a one-sentence description of what the user is doing and why.
Under each activity, list the tasks that make up the minimal happy path — the simplest way to complete each activity successfully.
Create Posting Source Candidates Review Applications
├── Write description ├── Post to job board ├── View applicant list
├── Set requirements ├── Share link ├── Read resume
├── Get approval ├── Receive referrals ├── Score candidate
The happy path is the top row of tasks — the minimal set that gets the user from start to finish.
Below the happy path, add tasks for:
Place these below the happy-path tasks, ordered by priority (most important first). Each row down is less critical than the row above.
Draw horizontal lines across the map to define release boundaries. Each slice is a shippable increment.
The thinnest possible end-to-end slice that demonstrates the full flow. It must:
The walking skeleton is NOT an MVP. It is smaller — it proves the flow works, not that it is valuable to users.
The minimum set of tasks that delivers enough value for real users to adopt. It must:
Additional tasks that improve the experience, add alternative paths, or handle edge cases. Group them into coherent releases — each release should make a specific aspect noticeably better.
Before finalising, verify the map:
| Check | Question | Action if Failing |
|---|---|---|
| Backbone completeness | Does the backbone cover the user's journey from start to finish? | Add missing activities |
| No orphan stories | Does every task sit under an activity? | Move orphans or add a missing backbone activity |
| Walking skeleton coverage | Does the walking skeleton include at least one task per activity? | Add missing tasks to the skeleton |
| Story independence | Can each task be built and delivered independently? | Split coupled tasks |
| No hidden activities | Are there activities the user does outside the product that affect the flow? | Add them or note them as external dependencies |
| Edge case coverage | Are error paths and empty states represented? | Add edge case tasks below the happy path |
# Story Map: [Feature Area / Epic]
## User and Goal
| Field | Description |
|-------|-------------|
| **User** | [Specific role + context] |
| **Goal** | [End-to-end outcome] |
| **Journey** | [Start] → [End] |
| **Scope boundary** | [What is excluded] |
## Story Map
| | Activity 1 | Activity 2 | Activity 3 | Activity 4 | Activity 5 |
|---|---|---|---|---|---|
| **Backbone** | [Activity name] | [Activity name] | [Activity name] | [Activity name] | [Activity name] |
| **Walking Skeleton** | [Task] | [Task] | [Task] | [Task] | [Task] |
| **MVP** | [Task] | [Task] | [Task] | [Task] | [Task] |
| | [Task] | [Task] | | [Task] | |
| **Enhancement** | [Task] | [Task] | [Task] | [Task] | [Task] |
| | [Task] | | [Task] | | [Task] |
| **Future** | [Task] | [Task] | | [Task] | |
## Release Slices
### Slice 1: Walking Skeleton
- **Goal:** Prove the end-to-end flow works
- **Stories:** [list of tasks from the walking skeleton row]
- **Definition of done:** User can complete the full journey, even if manually or with minimal features
### Slice 2: MVP
- **Goal:** Deliver enough value for real adoption
- **Stories:** [list of tasks from the MVP row]
- **Definition of done:** User can complete their goal without workarounds
### Slice 3: [Enhancement theme]
- **Goal:** [What this release improves]
- **Stories:** [list of tasks]
- **Definition of done:** [Measurable improvement]
## Validation Checklist
- [ ] Backbone covers full user journey (start to finish)
- [ ] No orphan stories (every task has an activity)
- [ ] Walking skeleton touches every activity
- [ ] Each task is independently deliverable
- [ ] Edge cases and error paths are represented
- [ ] Each release slice is independently shippable
Write the output to a file: docs/story-map-[feature].md.
/product-owner:write-user-story — write detailed user stories (with Gherkin acceptance criteria) for individual tasks from the map./product-owner:groom-backlog — prioritise the mapped stories within the backlog./coordinator:decompose-initiative — decompose a large initiative before mapping individual features.Use the story map template (templates/story-map.md) for output structure.