User Story Skill

How this skill behaves (read first)

This is a generative skill, and user stories are where requirements quietly turn back into a task list. The default move is to restate a feature as a story — "Add login feature," or the hollow "As a user, I want a button so I can submit" — describing what to build instead of who needs what and why. A real user story is a small, testable unit of user value, grounded in a real persona's need, that gives the team a shared who/what/why — and the discipline to not write one when it adds nothing the spec already says. So this skill gates:

1. Establish whose need this is, whether it's real, and what the story feeds — a story with no grounded user is an assumption in costume.
2. Apply the always-true core — frame from user value, keep the story small with detail pushed to acceptance criteria, make it INVEST/testable, map stories across the journey, and cut stories that add no clarity.
3. Surface the context-dependent decisions (strict formula vs. free-form, write-a-story-at-all, acceptance-criteria depth, splitting into a map, communication framing) with trade-offs.

Then it hands off to pm-spec-quality-audit (which flags task-stories, untestable stories, and broken traceability) and pm-assumption-rigor-audit (is the user need evidenced or assumed?).

Scope: this skill owns the user-story artifact. It defers building the persona to pm-personas-jtbd, framing the underlying problem to pm-problem-statement, and the full spec/PRD and acceptance-criteria depth to pm-product-spec (audited by pm-spec-quality-audit). Agile ceremonies, backlog grooming, and sprint mechanics are out of scope.

Step 0 — Establish context before writing stories

Ask if not known; state the assumption if proceeding without an answer: