5483ecf437
Epics now require a "Working Model" section in their description, in addition to "Success Criteria". This provides clear guidance on HOW the epic will be executed: - Owner role: Coordinator vs Implementer - Delegation target: Polecats, crew, external - Review process: Approval gates Closes gt-0lp Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
description, argument-hint
| description | argument-hint | |
|---|---|---|
| Epic management commands |
|
Manage epics (large features composed of multiple issues).
Available Commands
-
status: Show epic completion status
- Shows progress for each epic
- Lists child issues and their states
- Calculates completion percentage
-
close-eligible: Close epics where all children are complete
- Automatically closes epics when all child issues are done
- Useful for bulk epic cleanup
Epic Workflow
- Create epic:
bd create "Large Feature" -t epic -p 1 - Link subtasks:
bd dep add bd-10 bd-20 --type parent-child(epic bd-10 is parent of task bd-20) - Track progress:
bd epic status - Auto-close when done:
bd epic close-eligible
Epics use parent-child dependencies to track subtasks.
Epic Template Sections
Epics require two sections in their description:
Success Criteria
Define high-level criteria for epic completion. What does "done" look like?
Working Model
Define HOW the epic will be executed:
- Owner role: Is the assignee a Coordinator (decomposes and delegates) or Implementer (does hands-on work)?
- Delegation target: Who does the work? Polecats? Other crew? External contributors?
- Review process: Who approves completed subtasks? What gates must pass?
Example:
## Working Model
- **Owner role**: Coordinator - decompose into subtasks and sling to polecats
- **Delegation target**: Polecat swarm (3-5 workers)
- **Review process**: Refinery MQ for each subtask, owner approval for epic closure