home / skills / yellinzero / aico / aico-pm-user-story-writing

aico-pm-user-story-writing skill

/.codex/skills/aico-pm-user-story-writing

This skill converts requirements into well-structured user stories with acceptance criteria and saves them to docs/reference/pm/stories.

npx playbooks add skill yellinzero/aico --skill aico-pm-user-story-writing

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.2 KB
---
name: aico-pm-user-story-writing
description: |
  Transform requirements into well-structured User Stories using "As a [user], I want [goal], So that [benefit]" format with Given/When/Then acceptance criteria.

  Use this skill when:
  - User asks to "write user story", "create story", "add story"
  - User mentions "user story", "backlog item", "story"
  - Running /pm.plan and need to break PRD into implementable stories
  - Creating backlog items for development team
  - Need to formalize a requirement into standard story format
  - Converting feature request into actionable story with acceptance criteria

  Output: ALWAYS write story files to docs/reference/pm/stories/{story-name}.md
---

# User Story Writing

## Language Configuration

Before generating any content, check `aico.json` in project root for `language` field to determine the output language. If not set, default to English.

## Process

1. **Identify user type**: Who benefits from this feature
2. **Define goal**: What they want to do
3. **Clarify value**: Why it matters to them
4. **Write acceptance criteria**: 3-5 Given/When/Then scenarios
5. **Add metadata**: Priority, complexity, dependencies
6. **Save story**: ALWAYS write to `docs/reference/pm/stories/{story-name}.md`

## Story Template

```markdown
# [STORY-ID] Story Title

> Project: [project-name]
> Created: YYYY-MM-DD
> Last Updated: YYYY-MM-DD

**As a** [user type]
**I want** [goal/action]
**So that** [benefit/value]

### Acceptance Criteria

- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]

### Notes

- Priority: P1/P2/P3
- Estimated complexity: S/M/L/XL
- Dependencies: [list any dependencies]
```

## Key Rules

- ALWAYS specify the user type (who benefits)
- MUST focus on user value, not technical solution
- ALWAYS include 3-5 testable acceptance criteria
- Use Given/When/Then format for all criteria
- MUST save to `docs/reference/pm/stories/` directory

## Common Mistakes

- ❌ Vague acceptance criteria → ✅ Specific, testable conditions
- ❌ Solution-focused stories → ✅ Focus on user value
- ❌ Missing user type → ✅ Always specify who benefits

Overview

This skill transforms raw requirements and feature requests into well-structured User Stories using the canonical "As a [user], I want [goal], So that [benefit]" format. It always produces 3–5 Given/When/Then acceptance criteria and writes the resulting story file to docs/reference/pm/stories/{story-name}.md. The output focuses on user value, clear testable conditions, and PM metadata for prioritization and planning.

How this skill works

The skill inspects the provided requirement, PRD excerpt, or feature request, identifies the user type, the specific goal, and the value delivered. It crafts a concise user story with 3–5 testable Given/When/Then acceptance criteria, adds priority, estimated complexity, and dependencies, and saves the file to docs/reference/pm/stories/{story-name}.md. It respects project language settings from aico.json if present.

When to use it

  • When asked to "write user story", "create story", or "add story"
  • When a user mentions "user story", "backlog item", or "story"
  • While running /pm.plan to break PRD features into implementable stories
  • When creating backlog items for the development team
  • When formalizing a requirement or feature request into a standard story format

Best practices

  • Always specify the user type — name who benefits from the feature
  • Focus on user value, not on implementation details or solutions
  • Include 3–5 clear, testable Given/When/Then acceptance criteria
  • Add metadata: priority (P1/P2/P3), estimated complexity (S/M/L/XL), and dependencies
  • Use concise story file names and save to docs/reference/pm/stories/{story-name}.md

Example use cases

  • Convert a stakeholder feature request into a ready-to-implement backlog item
  • Break a PRD epic into granular stories during sprint planning
  • Create acceptance criteria for QA to validate a shipped feature
  • Standardize backlog items so the engineering team has testable requirements
  • Document a small enhancement with priority and complexity for roadmapping

FAQ

Where is the generated story file saved?

Every story is saved to docs/reference/pm/stories/{story-name}.md as the canonical source.

How many acceptance criteria should each story include?

Each story includes 3–5 Given/When/Then acceptance criteria to ensure testability and clarity.