/wwas
Create product backlog items in Why-What-Acceptance format โ independent, valuable, testable items with strategic context. Use when writing structured backlog items, breaking features into work items, or using the WWA format.
One skill from pm-skills.
shell
$ npx -y skills add phuryn/pm-skills --skill wwas --agent claude-codeInstalls just this skill. Get the whole plugin for auto-invocation.
How it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/wwas
Context preview
The summary Claude sees to decide when to auto-load this skill.
Create product backlog items in Why-What-Acceptance format โ independent, valuable, testable items with strategic context. Use when writing structured backlog items, breaking features into work items, or using the WWA format.
Stats
Stars24,323
Forks2,502
LicenseMIT
SKILL.md
wwas.SKILL.md
--- name: wwas description: "Create product backlog items in Why-What-Acceptance format โ independent, valuable, testable items with strategic context. Use when writing structured backlog items, breaking features into work items, or using the WWA format." --- # Why-What-Acceptance (WWA) Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context. **Use when:** Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams. **Arguments:** - `$PRODUCT`: The product or system name - `$FEATURE`: The new feature or capability - `$DESIGN`: Link to design files (Figma, Miro, etc.) - `$ASSUMPTIONS`: Key assumptions and strategic context ## Step-by-Step Process 1. **Define the strategic Why** - Connect work to business and team objectives 2. **Describe the What** - Keep descriptions concise, reference designs 3. **Write Acceptance Criteria** - High-level, not detailed specifications 4. **Ensure independence** - Items can be developed in any order 5. **Keep items negotiable** - Invite team conversation, not constraints 6. **Make items valuable** - Each delivers measurable user or business value 7. **Ensure testability** - Outcomes are observable and verifiable 8. **Size appropriately** - Small enough for one sprint estimate
