mcpField
W
write-user-story

write-user-story

github.com/testomatioDevelopment1664 installsUpdated 6d ago
Repository

About write-user-story

A skill for turning source material into atomic, testable user stories with acceptance criteria. It is intended for people defining requirements and emphasizes clarification instead of inventing missing rules.

Key features

  1. 01Converts source material into one or more stories
  2. 02Requires testable acceptance criteria
  3. 03Checks clarity and atomicity
  4. 04Flags assumptions and open questions
  5. 05Provides follow-up review and test-case skills

Use cases

  1. 01Drafting stories from product requirements
  2. 02Clarifying incomplete or ambiguous rules
  3. 03Preparing stories for requirement review
  4. 04Deriving test cases from written stories

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/testomatio/skills --skill write-user-story

After installing, type/write-user-storyin Claude Code to confirm it loaded.

Details

From the project README

Write User Story

Turn source material into user story (or multiple stories). Acceptance criteria on each story are the requirements — testable, atomic rules the story must satisfy.

If the source of data is a PR, use qa-pr-requirements-analyzer skill. If the source is a ticket in issue tracking system, ask for MCP connection.

Rules

User story must be (at least, but not limited to):

  • Atomic — one actor, one capability.
  • Clear — no vague words (fast, relevant, user-friendly, should work, as needed).
  • Complete — actor, trigger, outcome, business rules; empty, error, and permission paths covered in AC.
  • Consistent — same terms throughout; no contradictions.
  • Testable — every story has acceptance criteria with a measurable pass/fail.

Follow these rules:

  • Follow other best practices for writing user stories.
  • Describe what, not how. No UI widgets, API implementation details or frameworks unless the user asked for that.
  • Flag assumptions and open questions. Never silently invent missing rules. Do NOT: guess, imagine, assume. Always ask the user for clarification if something is unclear.

Output

Default: requirement (description) + acceptance criteria. Match the user's format if they specify one. (Other sections depending on context provided by the user).

Each requirement has at least one AC. Mark AC with a short unique id (e.g. AC-1). (Better to set ids at the end of the line to make the output more readable.)

Next actions

  • Review for gaps and testability → qa-requirement-reviewer
  • Risk scenarios → qa-thinking
  • Test cases from these user stories → qa-write-test-cases

Comments

Markdown supported