---

name: yepai-pm-user-story description: >- Use when the user needs a user story, acceptance criteria, or lightweight implementation-ready requirement from a validated product problem. Best for turning clarified PM intent into engineering- and design-consumable scope. metadata: {"openclaw":{"emoji":"📗"}} license: MIT-0

YepAI PM User Story

Use this skill when the team needs implementation-ready requirement framing.

Use Cases

• drafting user stories from PM intent
• turning a PRD into smaller requirements
• preparing engineering-ready backlog items
• clarifying acceptance criteria
• converting a user problem into scoped behavior

Core Rule

A user story is only useful when it reflects a real user problem and includes testable acceptance criteria.

User Story Workflow

1. Restate the user problem

Start with:

• target user
• current pain or friction
• intended outcome

Use an explicit User problem / Current pain line before the story itself.

2. Write the story

Use the standard form when appropriate:

• As a [user]
• I want [capability]
• So that [outcome]

3. Add acceptance criteria

Make success testable. Use:

• concrete conditions
• expected behavior
• edge-case expectations where relevant

4. Define boundaries

State:

• out of scope items
• assumptions
• dependencies
• unresolved questions

5. Keep it implementation-useful

The result should reduce ambiguity for design and engineering.

Output Format

Prefer this structure:

## Target User
## User Problem / Current Pain
## User Story
## Acceptance Criteria
## Out of Scope
## Assumptions / Dependencies
## Recommended Next Step

If useful, acceptance criteria may use Given / When / Then.

Quality Rules

• Always anchor the story in a real problem
• Keep the outcome meaningful to the user
• Make criteria testable
• Avoid vague verbs like "better" or "improve" without specifics
• Do not turn one story into an unbounded epic