القائمة
Use when creating or refining Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST)-aligned user stories.
Use when multiple independent read-only research tasks can run simultaneously, or when you need to fan out investigation across many files or hypotheses.
Use when communication quality or trust is in question. Always active -- applies to every session, every turn, every task.
Use when completing any session.
Use when a completed session needs behavioral retrospective analysis.
Use when delegating implementation tasks, confirming theories, running parallel research, or reviewing completed work.
Use when running parallel agent work, testing an approach in isolation, or keeping the main branch clean while a subagent operates on a separate branch.
| name | user-story-generator |
| license | MIT |
| description | Use when creating or refining Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST)-aligned user stories. |
VALIDATE EVERY STORY AGAINST INVEST CRITERIA AND INCLUDE ACCEPTANCE CRITERIA BEFORE SHIPPING
YOU MUST validate every story against INVEST criteria and include acceptance criteria before shipping.
No exceptions.
Violating the letter of this rule is violating the spirit of this rule.
Announce at start: "I am using the user-story-generator skill to create/refine a story for [brief description]."
After you've had the conversation and before generating, mentally verify you have:
references/PV_PROJECT_CONTEXT.md if this is a Particle-Viewer session. If this session is NOT about the Particle-Viewer project, skip this file -- it is PV-specific. Use the actual project context from the repo README or the user's description instead.[+] All 9 met -> proceed to generate the story [-] Any unmet -> ask the missing questions or gather the missing information. Do not generate until all 9 conditions are met.
RED FLAGS - Stop and ask for clarification:
Every generated story MUST be:
If a story violates INVEST, fix it or break it down.
See references/INVEST_GUIDE.md for conversation principles and common edge cases.
See references/INVEST_FRAMEWORK.md for per-criterion elaboration and examples.
As a [role: developer, tester, user]
I want to [action]
So that [outcome/business value]
See references/STORY_TEMPLATE.md for the full story template with all sections.
| Excuse | Reality |
|---|---|
| "The story is clear enough, INVEST is overkill" | INVEST catches scope creep and untestable requirements before sprint start. |
| "Acceptance criteria can be added later" | Stories without acceptance criteria can't be verified as done. Add them now. |
| "This story is too big but we'll split it in sprint" | Split it now. Big stories hide risk and block delivery. |
| "The story depends on another, but we'll handle it" | Dependent stories can't be independently delivered. Redesign the split. |
| "We can estimate it after starting" | Inestimable stories signal unclear scope. Clarify before committing. |
| "Good enough -- the team will figure out the details" | Vague stories produce vague implementations. Write precise acceptance criteria. |
| "AskUserQuestion covered the clarification, Discovery is redundant" | AskUserQuestion is informal Q&A. Discovery produces a Feature Specification that validates field optionality, invocation paths, and behavioral Acceptance Criteria under three personas. They are not equivalent. |
See references/OUTPUT_ROUTING.md for the full routing rule with context and forces.
three-amigos Ceremony 1 before finalizing any acceptance criterion.See references/CONVERSATION_SCRIPTS.md for story elicitation conversation scripts.
See references/PV_PROJECT_CONTEXT.md for project scope verification and reference loading guide (Particle-Viewer sessions only).
Always include the Effort Estimate section with:
See the user-story-estimation skill for S/M/L size breakdown, premium request ranges, model tier selection, and validated examples. Always include the Effort Estimate section in every generated story.