user-story-fundamentals_skill

This skill captures user-centered requirements as structured user stories to guide backlog items, acceptance criteria, and cross-functional collaboration.

136

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill flpbalada/my-opencode-config --skill user-story-fundamentals

SKILL.md10.9 KB

Overview

This skill teaches a structured approach to capturing requirements from the user’s perspective using concise user stories. It frames who the user is, what they want to accomplish, and why it matters to deliver clear, testable backlog items. Use it to keep product work user-focused and easier to estimate, prioritize, and implement.

How this skill works

The skill uses the standard "As a [user], I want [goal], so that [benefit]" template and enforces the WHO/WHAT/WHY split to avoid implementation detail. It applies INVEST quality checks and a clear acceptance-criteria pattern so each story is independent, estimable, small, and testable. It also provides splitting techniques, prioritization options (RICE, MoSCoW), and a DoD vs AC checklist to ensure delivery quality.

When to use it

Writing or refining backlog items
Defining acceptance criteria for features
Prioritizing features for a release
Breaking epics into sprint-sized work
Communicating requirements between product and engineering

Best practices

Specify the user persona precisely (avoid generic “user”)
Focus on goals and outcomes, not UI or technical solutions
Write clear, measurable acceptance criteria for testability
Apply INVEST to keep stories small, valuable, and estimable
Split large stories by workflow, user type, CRUD operations, or acceptance criteria

Example use cases

Create a password reset story with time-bound, testable acceptance criteria
Define invitation flows for admins with role selection and pending-invites visibility
Prioritize new features using RICE to compare reach, impact, confidence, and effort
Split a checkout epic into add-to-cart, shipping, payment, and confirmation stories
Convert vague requests into outcome-focused stories for clearer engineering proposals

FAQ

Be specific enough to guide solution choices: prefer roles with context (e.g., “marketing manager” or “first-time visitor”) instead of generic “user.”

What makes good acceptance criteria?

They must be specific, measurable, and testable — include success conditions, timing, edge cases, and security or performance limits when relevant.

When should I split a story?

Split if it can’t be completed in one sprint, contains multiple distinct user values, is too large to estimate reliably, or combines many acceptance criteria.