Consolidates agentic-flows plugin (v0.5.0) into claude/ folder: - 14 autonomous agents (engineer tiers, PR resolver, training collector) - 11 skills (flow orchestration, pattern library, KB learning) - 8 commands (/junior, /senior, /engineer, /qa, /analyze, /delegate, /seed, /learn) - 3 patterns (agent-memory, capability-tiers, handoff-protocol) - MCP server config, hooks, marketplace metadata Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
8 KiB
| name | description |
|---|---|
| flow-create-epic | 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.
# 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.
# 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.
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.
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.
# 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.
# 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
# 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:
## 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:
- Foundation: Core abstractions the features depend on
- Features: Independent feature implementations
- 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
- [ ] #NUMchecklist - 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)
Repos with Ungrouped Issues
As of 2026-02-04, these repos have open issues not yet in epics:
| Repo | Open issues | Theme | Notes |
|---|---|---|---|
core |
~40 audit + feature | Audit, AI commands, testing | 8 epics: #101,#118,#127,#133,#299,#300,#301,#302 |
core-php |
~15 audit | Security, quality, performance | No epics yet |
core-claude |
~25 features | CLI skills, hooks, integrations | No epics yet |
core-api |
3 audit | DB queries, REST design, rate limiting | No epics yet |
core-admin |
2 audit | UX, security | No epics yet |
core-mcp |
2 audit | Protocol, tool handlers | No epics yet |
core-tenant |
2 audit | DB queries, multi-tenancy security | No epics yet |
core-developer |
2 audit | DX, OAuth | No epics yet |
core-service-commerce |
2 audit | Payment, subscriptions | No epics yet |
core-devops |
2 | CI/CD, labeler | No epics yet |
core-agent |
2 | Workflow, test command | No epics yet |
core-template |
2 | Audit, composer fix | No epics yet |
build |
1 audit | Build security | No epics yet |
ansible-coolify |
1 audit | Infrastructure security | No epics yet |
docker-server-php |
1 audit | Container security | No epics yet |
docker-server-blockchain |
1 audit | Container security | No epics yet |
Priority candidates for epic creation:
core-php(15 audit issues → 1 audit epic)core-claude(25 feature issues → 1-2 feature epics)- Small repos with 2-3 audit issues → 1 audit epic each, or a cross-repo audit epic
Core audit epics created (2026-02-04):
- #299
epic/299-error-handling— Error Handling & Panic Safety (4 children: #227,#228,#229,#230) - #300
epic/300-security-observability— Security & Observability (6 children: #212,#213,#214,#217,#221,#222) - #301
epic/301-architecture— Architecture & Performance (4 children: #216,#224,#225,#232) - #302
epic/302-testing-docs— Testing & Documentation (7 children: #218,#219,#220,#231,#235,#236,#237)
Created: 2026-02-04 Companion to: flows/issue-epic.md