From personal-corp-skills
Decomposes epics into INVEST-validated user stories with Given-When-Then acceptance criteria, Fibonacci/T-shirt estimates (default Sprint-level), and a Story Map for sprint planning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/personal-corp-skills:pm-user-storiesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Part of the Personal Corp framework — running a one-person business through AI agents.
Part of the Personal Corp framework — running a one-person business through AI agents. Decompose a large requirement or Epic into independently-deliverable User Stories. Every Story is validated against INVEST. Output is ready to paste into Jira, Linear, or GitHub Issues.
| Field | Required | Notes |
|---|---|---|
| Requirement description | yes | An Epic or large requirement; can paste a PRD section |
| Granularity | no | Sprint-level (1-3 days/story) or iteration-level (1-2 weeks); default Sprint |
| Team composition | no | FE+BE split / full-stack / has mobile — affects per-tier splitting |
| Estimation system | no | Fibonacci (1/2/3/5/8/13) or T-shirt (S/M/L/XL); default Fibonacci |
Extract from the requirement:
Five patterns. Pick by requirement shape; combine for hybrids.
| Pattern | When to use | Example |
|---|---|---|
| By workflow step | Requirement is a complete process | Checkout → pick item / address / payment / confirm |
| By business-rule variant | Same feature with multiple rule sets | Discount → fixed-amount / coupon / points / combined |
| By CRUD operation | Requirement centers on one data object | Address book → create / edit / delete / set default |
| By role perspective | Multi-role feature | Order management → user view / merchant processing / ops dashboard |
| By complexity progression | Feature has simple and full versions | Search → keyword / filters / suggestions / history |
Selection principle: target ≤ 1 Sprint per Story. Hybrid requirements combine patterns.
Granularity calibration:
### US-{N}: {Story title — verb-led, e.g. "Choose payment method"}
**Role:** As a {role}
**Action:** I want to {specific action}
**Value:** so that {business value}
**Priority:** P0 (must) / P1 (important) / P2 (nice-to-have)
**Story Points:** {estimate}
**Acceptance Criteria:**
- [ ] Given {precondition}, When {action}, Then {expected result}
- [ ] Given {exception precondition}, When {action}, Then {error handling}
**Dependencies:** {other Story IDs, or "none"}
**Tech notes:** {dev callouts, optional}
Story Point reference (Fibonacci):
| Points | Complexity | Effort | Typical scope |
|---|---|---|---|
| 1 | Trivial | < 0.5 day | Copy change, config tweak, add an event |
| 2 | Simple | 0.5-1 day | One CRUD operation, form validation |
| 3 | Medium | 1-2 days | A complete feature point with business logic |
| 5 | Complex | 2-4 days | Multi-module interaction |
| 8 | Big | 4-7 days | New system / new flow core module |
| 13 | Re-split | > 1 week | Means the Story is too big — must split |
AC quality rules — every AC must satisfy:
Run each Story against the six checks:
| Principle | Check | If fails |
|---|---|---|
| Independent | Delete this Story — can the others still ship? | Cyclic deps → merge or re-split |
| Negotiable | Does it describe "what" or "how"? | Strip implementation detail, keep value |
| Valuable | Will the user perceive value when this ships? | Pure refactor → attach to a user-perceivable feature |
| Estimable | Can the team agree on points within 5 minutes? | Wide spread = unclear requirement; clarify first |
| Small | Fits in one Sprint? | Larger → split |
| Testable | Can QA write test cases directly from the AC? | Add concrete edge values and expected results |
Definition of Ready (must hold before entering development):
| Check | Standard | If unmet |
|---|---|---|
| AC complete | ≥ 1 happy + ≥ 1 exception | Fill ACs, then schedule |
| No blocking deps | All upstream Stories done or mockable | Tag "Blocked", push to a later Sprint |
| Designs ready | UI Stories have design specs | No designs → tag "Needs design" |
| Estimation consensus | Spread < 2× | Re-discuss scope until agreed |
| Business rules confirmed | All [TBD] resolved | Confirm with PM/business, then dev |
Dependency rules:
## Epic: {requirement name}
### Story Map (user journey → Story mapping)
| Journey stage | Stories | Priority | Points |
|---|---|---|---|
| {stage 1} | US-001, US-002 | P0 | 5 |
| {stage 2} | US-003, US-004 | P1 | 8 |
### Sprint planning
- **Sprint 1 (MVP):** {Story list}, total {X} points
- **Sprint 2:** {Story list}, total {X} points
### Dependencies
US-001 → US-003 → US-005 (must follow this order)
US-002, US-004 (parallel)
[business rule TBD] and propose plausible assumptions for confirmation/pm-prd — write a PRD first to lock scope, then break into Stories/pm-prioritize — when there are many Stories, RICE-rank for Sprint prioritynpx claudepluginhub serejaris/personal-corp-skills --plugin personal-corp-skillsUse this skill when the user asks to "write user stories", "decompose this into user stories", "break this into stories", "write acceptance criteria for this feature", "turn this PRD into stories", "create a story map", "help me write stories for sprint planning", or has a feature or PRD and wants to decompose it into shippable units for engineering. Do NOT use this skill to write a full PRD — use prd-authoring for that.
Decomposes features into granular, INVEST-compliant user stories with acceptance criteria, MoSCoW priorities, and relative estimates (S/M/L). Useful for breaking down requirements into 8-hour implementable units.
Breaks PRDs or feature descriptions into implementable user stories with acceptance criteria, priorities, and notes. Use for sprint planning or engineering handoff.