220 lines
6 KiB
Markdown
220 lines
6 KiB
Markdown
|
|
---
|
||
|
|
name: flow-create-epic
|
||
|
|
description: Use when grouping 3+ ungrouped issues into epics with branches. Creates parent epic issues with checklists and corresponding epic branches.
|
||
|
|
---
|
||
|
|
|
||
|
|
# Flow: Create Epic
|
||
|
|
|
||
|
|
Turn a group of related issues into an epic with child issues, an epic branch, and a parent checklist — ready for the issue-epic flow to execute.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## When to Use
|
||
|
|
|
||
|
|
- A repo has multiple open issues that share a theme (audit, migration, feature area)
|
||
|
|
- You want to parallelise work across agents on related tasks
|
||
|
|
- You need to track progress of a multi-issue effort
|
||
|
|
|
||
|
|
## Inputs
|
||
|
|
|
||
|
|
- **Repo**: `owner/repo`
|
||
|
|
- **Theme**: What groups these issues (e.g. "security audit", "io migration", "help system")
|
||
|
|
- **Candidate issues**: Found by label, keyword, or manual selection
|
||
|
|
|
||
|
|
## Process
|
||
|
|
|
||
|
|
### Step 1: Find Candidate Issues
|
||
|
|
|
||
|
|
Search for issues that belong together. Use structural signals only — labels, title patterns, repo.
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# By label
|
||
|
|
gh search issues --repo OWNER/REPO --state open --label LABEL --json number,title
|
||
|
|
|
||
|
|
# By title pattern
|
||
|
|
gh search issues --repo OWNER/REPO --state open --json number,title \
|
||
|
|
--jq '.[] | select(.title | test("PATTERN"))'
|
||
|
|
|
||
|
|
# All open issues in a repo (for small repos)
|
||
|
|
gh issue list --repo OWNER/REPO --state open --json number,title,labels
|
||
|
|
```
|
||
|
|
|
||
|
|
Group candidates by dependency order if possible:
|
||
|
|
- **Blockers first**: Interface changes, shared types, core abstractions
|
||
|
|
- **Parallel middle**: Independent migrations, per-package work
|
||
|
|
- **Cleanup last**: Deprecation removal, docs, final validation
|
||
|
|
|
||
|
|
### Step 2: Check for Existing Epics
|
||
|
|
|
||
|
|
Before creating a new epic, check if one already exists.
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# Search for issues with child checklists in the repo
|
||
|
|
gh search issues --repo OWNER/REPO --state open --json number,title,body \
|
||
|
|
--jq '.[] | select(.body | test("- \\[[ x]\\] #\\d+")) | {number, title}'
|
||
|
|
```
|
||
|
|
|
||
|
|
If an epic exists for this theme, update it instead of creating a new one.
|
||
|
|
|
||
|
|
### Step 3: Order the Children
|
||
|
|
|
||
|
|
Arrange child issues into phases based on dependencies:
|
||
|
|
|
||
|
|
```
|
||
|
|
Phase 1: Blockers (must complete before Phase 2)
|
||
|
|
- Interface definitions, shared types, core changes
|
||
|
|
|
||
|
|
Phase 2: Parallel work (independent, can run simultaneously)
|
||
|
|
- Per-package migrations, per-file changes
|
||
|
|
|
||
|
|
Phase 3: Cleanup (depends on Phase 2 completion)
|
||
|
|
- Remove deprecated code, update docs, final validation
|
||
|
|
```
|
||
|
|
|
||
|
|
Within each phase, issues are independent and can be dispatched to agents in parallel.
|
||
|
|
|
||
|
|
### Step 4: Create the Epic Issue
|
||
|
|
|
||
|
|
Create a parent issue with the child checklist.
|
||
|
|
|
||
|
|
```bash
|
||
|
|
gh issue create --repo OWNER/REPO \
|
||
|
|
--title "EPIC_TITLE" \
|
||
|
|
--label "agentic,complexity:large" \
|
||
|
|
--body "$(cat <<'EOF'
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
DESCRIPTION OF THE EPIC GOAL.
|
||
|
|
|
||
|
|
## Child Issues
|
||
|
|
|
||
|
|
### Phase 1: PHASE_NAME (blocking)
|
||
|
|
- [ ] #NUM - TITLE
|
||
|
|
- [ ] #NUM - TITLE
|
||
|
|
|
||
|
|
### Phase 2: PHASE_NAME (parallelisable)
|
||
|
|
- [ ] #NUM - TITLE
|
||
|
|
- [ ] #NUM - TITLE
|
||
|
|
|
||
|
|
### Phase 3: PHASE_NAME (cleanup)
|
||
|
|
- [ ] #NUM - TITLE
|
||
|
|
|
||
|
|
## Acceptance Criteria
|
||
|
|
|
||
|
|
- [ ] CRITERION_1
|
||
|
|
- [ ] CRITERION_2
|
||
|
|
EOF
|
||
|
|
)"
|
||
|
|
```
|
||
|
|
|
||
|
|
**Checklist format matters.** The issue-epic flow detects children via `- [ ] #NUM` and `- [x] #NUM` patterns. Use exactly this format.
|
||
|
|
|
||
|
|
### Step 5: Link Children to Parent
|
||
|
|
|
||
|
|
Add a `Parent: #EPIC_NUMBER` line to each child issue body, or comment it.
|
||
|
|
|
||
|
|
```bash
|
||
|
|
for CHILD in NUM1 NUM2 NUM3; do
|
||
|
|
gh issue comment $CHILD --repo OWNER/REPO --body "Parent: #EPIC_NUMBER"
|
||
|
|
done
|
||
|
|
```
|
||
|
|
|
||
|
|
### Step 6: Create the Epic Branch
|
||
|
|
|
||
|
|
Create a branch off dev (or the repo's default branch) for the epic.
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# Get default branch SHA
|
||
|
|
SHA=$(gh api repos/OWNER/REPO/git/refs/heads/dev --jq '.object.sha')
|
||
|
|
|
||
|
|
# Create epic branch
|
||
|
|
gh api repos/OWNER/REPO/git/refs -X POST \
|
||
|
|
-f ref="refs/heads/epic/EPIC_NUMBER-SLUG" \
|
||
|
|
-f sha="$SHA"
|
||
|
|
```
|
||
|
|
|
||
|
|
**Naming:** `epic/<issue-number>-<short-slug>` (e.g. `epic/118-mcp-daemon`)
|
||
|
|
|
||
|
|
### Step 7: Dispatch Blockers
|
||
|
|
|
||
|
|
Add the agent label to the first unchecked child in each phase (the blocker). Add a target branch comment.
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# Label the blocker
|
||
|
|
gh issue edit CHILD_NUM --repo OWNER/REPO --add-label jules
|
||
|
|
|
||
|
|
# Comment the target branch
|
||
|
|
gh issue comment CHILD_NUM --repo OWNER/REPO \
|
||
|
|
--body "Target branch: \`epic/EPIC_NUMBER-SLUG\` (epic #EPIC_NUMBER)"
|
||
|
|
```
|
||
|
|
|
||
|
|
**IMPORTANT:** Adding the agent label (e.g. `jules`) immediately dispatches work. Only label when ready. Each label costs a daily task from the agent's quota.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Creating Epics from Audit Issues
|
||
|
|
|
||
|
|
Many repos have standalone audit issues (e.g. `[Audit] Security`, `[Audit] Performance`). These can be grouped into a single audit epic per repo.
|
||
|
|
|
||
|
|
### Pattern: Audit Epic
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# Find all audit issues in a repo
|
||
|
|
gh issue list --repo OWNER/REPO --state open --label jules \
|
||
|
|
--json number,title --jq '.[] | select(.title | test("\\[Audit\\]|audit:"))'
|
||
|
|
```
|
||
|
|
|
||
|
|
Group by category and create an epic:
|
||
|
|
|
||
|
|
```markdown
|
||
|
|
## Child Issues
|
||
|
|
|
||
|
|
### Security
|
||
|
|
- [ ] #36 - OWASP Top 10 security review
|
||
|
|
- [ ] #37 - Input validation and sanitization
|
||
|
|
- [ ] #38 - Authentication and authorization flows
|
||
|
|
|
||
|
|
### Quality
|
||
|
|
- [ ] #41 - Code complexity and maintainability
|
||
|
|
- [ ] #42 - Test coverage and quality
|
||
|
|
- [ ] #43 - Performance bottlenecks
|
||
|
|
|
||
|
|
### Ops
|
||
|
|
- [ ] #44 - API design and consistency
|
||
|
|
- [ ] #45 - Documentation completeness
|
||
|
|
```
|
||
|
|
|
||
|
|
Audit issues are typically independent (no phase ordering needed) — all can be dispatched in parallel.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Creating Epics from Feature Issues
|
||
|
|
|
||
|
|
Feature repos (e.g. `core-claude`) may have many related feature issues that form a product epic.
|
||
|
|
|
||
|
|
### Pattern: Feature Epic
|
||
|
|
|
||
|
|
Group by dependency:
|
||
|
|
1. **Foundation**: Core abstractions the features depend on
|
||
|
|
2. **Features**: Independent feature implementations
|
||
|
|
3. **Integration**: Cross-feature integration, docs, onboarding
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Checklist
|
||
|
|
|
||
|
|
Before dispatching an epic:
|
||
|
|
|
||
|
|
- [ ] Candidate issues identified and ordered
|
||
|
|
- [ ] No existing epic covers this theme
|
||
|
|
- [ ] Epic issue created with `- [ ] #NUM` checklist
|
||
|
|
- [ ] Children linked back to parent (`Parent: #NUM`)
|
||
|
|
- [ ] Epic branch created (`epic/<number>-<slug>`)
|
||
|
|
- [ ] Blocker issues (Phase 1 first children) labelled for dispatch
|
||
|
|
- [ ] Target branch commented on labelled issues
|
||
|
|
- [ ] Agent quota checked (don't over-dispatch)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
*Companion to: RFC.flow-issue-epic.md*
|