job-stories

Overview of job-stories skill

The job-stories skill helps you turn rough product ideas into JTBD-style job stories in the form: “When [situation], I want to [motivation], so I can [outcome].” It is most useful when you need clearer backlog items, better requirements planning, or a shared way to describe user context before solution design.

What this skill is best for

Use the job-stories skill when you already know a feature area but need to sharpen the user problem behind it. It fits product managers, designers, analysts, and AI agents drafting requirements from design links, feature prompts, or stakeholder notes.

Why it is different from a generic prompt

The main value is structure: it pushes the model to start from situation and motivation, then add acceptance criteria that are tied to observable outcomes. That makes job-stories more useful than a loose “write user stories” prompt when the team cares about context, intent, and testable results.

When it is a good fit

This skill is a strong match for job-stories for Requirements Planning, pre-discovery backlog shaping, and translating feature concepts into user-centered stories. It is less useful if you only need a quick sentence-level idea list with no acceptance criteria or if your team uses a different requirements format entirely.

How to Use job-stories skill

Install and trigger it correctly

For job-stories install, use the directory’s normal skill loader: npx skills add phuryn/pm-skills --skill job-stories. Then invoke the skill with enough input for the model to infer the user situation, the product area, and the desired outcome. A bare feature name is usually too thin.

Give it the right input shape

The skill works best when your prompt includes the product, feature, user context, and any design reference. A strong starting prompt looks like: “Create job stories for [product] feature [feature] using these user situations: [context]. Use the design link [design] and focus on outcomes, not roles.” That is better than “write job stories for checkout.”

Read these files first

Start with SKILL.md because it contains the workflow, story template, and required arguments. If your local copy includes adjacent documentation, read README.md, AGENTS.md, and metadata.json next, plus any rules/, resources/, references/, or scripts/ folders. In this repo, SKILL.md is the main source of truth, so there is little extra surface to scan.

Workflow tips that improve output

Use the skill in two passes: first for raw job stories, then for refinement against your real constraints. If the first output is vague, add concrete situations, decision points, and design links. If the stories feel role-based, ask for a rewrite that centers the trigger and desired progress instead of the persona.

job-stories skill FAQ

Is job-stories good for Requirements Planning?

Yes. job-stories is designed for requirements planning when you want user-centered backlog items instead of feature-first tickets. It helps convert scope into situations, motivations, and outcomes that are easier to discuss with design and engineering.

Do I need a design file to use it well?

No, but the job-stories skill is stronger when you provide one. A Figma or Miro link helps the model anchor acceptance criteria to visible behavior instead of inventing assumptions.

How is this different from ordinary user stories?

Ordinary prompts often produce role-based templates or shallow acceptance criteria. The job-stories skill is better when the key decision is why the user is acting and what outcome they need, not just what the system should do.

Is this beginner-friendly?

Yes, if you can describe a feature in plain language. The main limitation is input quality: beginners get better results when they provide one or two real user situations rather than a broad feature theme.

How to Improve job-stories skill

Provide richer situations, not just feature names

The biggest quality gain comes from concrete context. Instead of “notifications,” give a situation like “When a user misses a payment reminder while traveling” so the job-stories skill can produce a meaningful situation, motivation, and outcome chain.

Add constraints and success signals

If you care about accessibility, timing, device limits, or approval flows, include those upfront. Stronger acceptance criteria happen when the prompt explains what success looks like, what must be observable, and what would make the story fail.

Ask for revision by failure mode

If the first draft is too generic, ask for fewer role references and more situational detail. If it is too solution-heavy, ask for job stories that avoid implementation language. If it is too broad, narrow the feature to one user goal at a time.

Use the first output as a planning draft

Treat the first pass as an exploration tool, not final requirements. The best job-stories usage comes from iterating until the stories align with your roadmap, design, and engineering constraints, then trimming anything that does not help Requirements Planning or delivery.