From fenix
Workflow for translating business requirements into epics, features, and stories in Fenix. Use when the user wants to plan a product, define scope, or create work item hierarchies.
How this skill is triggered — by the user, by Claude, or both
Slash command
/fenix:fenix-product-planningThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill guides you through translating business requirements into a structured work item hierarchy in Fenix: **Epics → Features → Stories**.
This skill guides you through translating business requirements into a structured work item hierarchy in Fenix: Epics → Features → Stories.
Use this when the user talks about: requirements, business needs, product scope, MVP, new features, project kickoff, or wants to create epics/features/stories.
Understand context → Search memories → Define hierarchy → Create items → Save decisions
Before creating anything, have a conversation with the user to understand:
<EXTREMELY_IMPORTANT> Do NOT jump to creating work items before you understand the business context. Ask questions. Clarify ambiguities. The quality of planning depends on the quality of understanding. </EXTREMELY_IMPORTANT>
If the user already has clear requirements (e.g., a PRD, a spec, a detailed description), skip the discovery questions and move to Step 2.
Before creating new items, check what already exists:
memory_search(query: "{product/project name} requirements")
memory_search(query: "{product/project name} architecture")
Also check existing work items:
work_list(query: "{product/project name}")
If related items exist:
Plan the hierarchy before creating items. Present it to the user for approval.
| Type | Purpose | Example |
|---|---|---|
| Epic | Large initiative spanning multiple features. Weeks to months of work. | "User Authentication System" |
| Feature | A distinct capability within an epic. Days to weeks. | "Social Login (Google, GitHub)" |
| Story | A user-facing outcome within a feature. Hours to days. Can be implemented in one session. | "As a user, I can log in with my Google account" |
Show the user the proposed hierarchy before creating anything:
Epic: User Authentication System
├── Feature: Email/Password Auth
│ ├── Story: User can register with email and password
│ ├── Story: User can log in with email and password
│ └── Story: User can reset password via email
├── Feature: Social Login
│ ├── Story: User can log in with Google
│ └── Story: User can log in with GitHub
└── Feature: Session Management
├── Story: User session persists across browser restarts
└── Story: User can log out from all devices
Wait for the user to approve, modify, or add to this structure before proceeding.
Before creating items, understand the available statuses:
work_statuses()
board_columns()
This ensures you know:
New items should typically be created in backlog or todo status.
Create the top-level epic first:
work_create(
title: "User Authentication System",
item_type: "epic",
description: "## Goal\n{business goal}\n\n## Scope\n{what's included}\n\n## Out of scope\n{what's excluded}\n\n## Success criteria\n{how we know it's done}"
)
Use work_bulk_create to create the full hierarchy in one call:
work_bulk_create(items: [
{
"temp_id": "feat-1",
"title": "Email/Password Auth",
"item_type": "feature",
"work_category": "feature",
"parent_key": "PROJ-100", // existing epic key
"description": "..."
},
{
"temp_id": "story-1",
"title": "User can register with email and password",
"item_type": "story",
"work_category": "story",
"parent_temp_id": "feat-1", // references the feature above
"description": "..."
},
{
"temp_id": "story-2",
"title": "User can log in with email and password",
"item_type": "story",
"work_category": "story",
"parent_temp_id": "feat-1",
"description": "..."
}
])
work_bulk_create rulestemp_id, title, item_type, work_categoryparent_key to reference an existing item (e.g., an epic already in Fenix)parent_temp_id to reference another item in the same batchEvery story should have a clear description:
## User Story
As a {role}, I can {action} so that {benefit}.
## Acceptance Criteria
- [ ] {criterion 1}
- [ ] {criterion 2}
- [ ] {criterion 3}
## Notes
{any additional context, constraints, or dependencies}
For each story, consider setting:
Check the active sprint:
sprint_active()
Save key decisions as memories for future reference:
memory_save(
title: "Planning — {Epic name} scope and decisions",
content: "## Scope\n{what was included/excluded and why}\n\n## Key decisions\n- {decision 1}: {rationale}\n- {decision 2}: {rationale}\n\n## Hierarchy\n{the approved structure}\n\n## Open questions\n{anything deferred}",
tags: ["planning", "decision", "{epic-key}"],
work_item_id: "{epic uuid}"
)
Before considering product planning complete, verify:
After product planning is complete, the user will pick a story to work on. That transitions to Technical Planning — load the fenix-technical-planning skill.
npx claudepluginhub fenix-assistant/fenix-plugin --plugin fenixBreaks requirements into epics and user stories for agile planning. Auto-activates when user says "create the epics and stories list" or invoke via /bmad-create-epics-and-stories.
Transforms business analyses into epics, features, and tech-agnostic success criteria. Creates handoff documents, triages artifacts as FEATURE/IMP/FIX/ADR, manages BACKLOG.md entries, and runs GitHub integration for issues/PRs.
Creates and maintains product/project backlogs with prioritization, acceptance criteria, and estimates. Supports user stories, MoSCoW, grooming, and tracking.