Add multi-platform export generator (single source of truth)
Make the library multi-platform without duplicating content. Each skills/<name>/SKILL.md body remains the single source of truth; a new generator renders platform-ready exports from it. - scripts/build-exports.mjs — dependency-free Node generator with a PLATFORMS registry so new platforms (Gemini, Cursor, …) are a few lines. Ships ChatGPT exports at exports/chatgpt/<bundle>/<skill>/SYSTEM_PROMPT.md (172 skills), plus generated index READMEs. Supports --platform and --check. - exports/ — generated ChatGPT system prompts, ready to paste into a Custom GPT. - .github/workflows/check-generated.yml — fails a PR if exports or web/skills.json drift from the source skills. - README "Works With" now documents the ready-to-use exports and regen command. - CHANGELOG + SKILL-AUTHORING-STANDARD note the generated artifacts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px
This commit is contained in:
Claude
@@ -0,0 +1,133 @@
|
||||
# Job Story Mapper Skill
|
||||
|
||||
Stop writing features. Start understanding jobs. This skill translates product requirements and user interviews into precise job stories that keep the team focused on outcomes — not outputs.
|
||||
|
||||
## Jobs-to-be-Done Fundamentals
|
||||
|
||||
A "job" is the progress a customer is trying to make in a given situation. People don't buy products — they hire them to get a job done.
|
||||
|
||||
Three dimensions of every job:
|
||||
- **Functional job:** The practical task ("get from A to B")
|
||||
- **Emotional job:** How they want to feel ("feel confident I made the right choice")
|
||||
- **Social job:** How they want to be perceived ("look like a competent professional to my team")
|
||||
|
||||
Great products address all three. Most roadmaps only address the functional one.
|
||||
|
||||
---
|
||||
|
||||
## Job Story Format
|
||||
|
||||
**Template:**
|
||||
> When [situation/trigger], I want to [motivation/goal], so I can [expected outcome].
|
||||
|
||||
**Not a user story:**
|
||||
User stories focus on roles and features: "As a [role] I want [feature] so that [benefit]."
|
||||
Job stories focus on situations and motivations: "When [I'm in this specific situation] I want [this capability] so I can [achieve this outcome]."
|
||||
|
||||
**The situation is the most important part.** "When I'm in the middle of a sprint and my PM asks for an update" is a much richer trigger than "As a developer."
|
||||
|
||||
---
|
||||
|
||||
## Mapping Process
|
||||
|
||||
### Step 1: Identify the main job
|
||||
One sentence: What is the core job your product is hired for?
|
||||
> "Help [user type] [accomplish outcome] when [context]."
|
||||
|
||||
### Step 2: Break into job steps
|
||||
What are all the sub-tasks within the main job?
|
||||
(Use a job map: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude)
|
||||
|
||||
### Step 3: Identify pain points per step
|
||||
Where does the job fall down today? Where do customers use workarounds?
|
||||
|
||||
### Step 4: Write job stories for each pain point
|
||||
One job story per distinct situation-motivation pair.
|
||||
|
||||
### Step 5: Map to product opportunities
|
||||
Which job stories are underserved? Which have existing solutions? Where is your differentiation?
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Job Story Map — [Product/Feature Area] — [Date]
|
||||
|
||||
**Core Job Statement:**
|
||||
> When [context], [user type] wants to [main job outcome], so they can [ultimate goal].
|
||||
|
||||
---
|
||||
|
||||
**Job Map:**
|
||||
|
||||
| Step | Sub-Job | Current Solution | Pain Points | Underserved? |
|
||||
|---|---|---|---|---|
|
||||
| Define | [What user does] | [Tool/method used] | [Frustration] | H/M/L |
|
||||
| Locate | | | | |
|
||||
| Prepare | | | | |
|
||||
| Confirm | | | | |
|
||||
| Execute | | | | |
|
||||
| Monitor | | | | |
|
||||
| Modify | | | | |
|
||||
| Conclude | | | | |
|
||||
|
||||
---
|
||||
|
||||
**Job Stories (prioritised by underservice):**
|
||||
|
||||
**Job Story 1 — [Situation label]**
|
||||
> When [specific situation], I want to [motivation], so I can [outcome].
|
||||
|
||||
Functional dimension: [What they need to get done]
|
||||
Emotional dimension: [How they want to feel]
|
||||
Social dimension: [How they want to be perceived]
|
||||
|
||||
Current workaround: [What they do today]
|
||||
Pain intensity: [High / Medium / Low]
|
||||
Frequency: [How often this situation occurs]
|
||||
Product opportunity: [What we could build to address this]
|
||||
|
||||
---
|
||||
|
||||
Repeat for each major job story.
|
||||
|
||||
**Opportunity Scoring:**
|
||||
Rate each job story on:
|
||||
- Importance to customer (1–10)
|
||||
- Satisfaction with current solution (1–10)
|
||||
- Opportunity score = Importance + max(Importance – Satisfaction, 0)
|
||||
- Prioritise: Opportunity score > 10
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Job stories use the "When / I want to / So I can" format (not user story format)
|
||||
- [ ] Situation is specific (not "as a user" — a real moment or trigger)
|
||||
- [ ] All three dimensions covered: functional, emotional, social
|
||||
- [ ] Opportunity score calculated for each job story
|
||||
- [ ] Current workaround identified for each high-opportunity story
|
||||
- [ ] Product opportunity is distinct from "build the feature" (it's an outcome)
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or feature area** to map (e.g. onboarding, checkout, dashboard)
|
||||
- **User type or persona** (who are we mapping jobs for?)
|
||||
- **Source material** (user interview notes, support tickets, discovery findings, or describe from memory)
|
||||
- **Scope** (full product job map vs. a single feature area)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write job stories that describe a feature rather than a situation-motivation pair
|
||||
- [ ] Do not skip the social and emotional dimensions — mapping only functional jobs misses the most defensible differentiation opportunities
|
||||
- [ ] Do not define situations too broadly ("as a user who wants to manage their work") — the situation must be a specific moment or trigger
|
||||
- [ ] Do not conflate opportunity scoring with priority — a high opportunity score still requires feasibility and strategic fit assessment
|
||||
- [ ] Do not produce a job map without identifying current workarounds — the workaround reveals what the job is worth to the customer
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never write a job story for a feature — write it for the situation that makes the feature valuable
|
||||
- If you can't identify the situation, you don't understand the job yet — go back to user research
|
||||
- Social and emotional jobs are harder to surface but often the most defensible differentiators
|
||||
- Recommend sharing job stories with engineering — they make better technical decisions when they understand the "why"
|
||||
Reference in New Issue
Block a user