Breakdown Plan

GitHub issue planning and project automation

Transform PRD, UX, technical, implementation, and testing artifacts into a traceable GitHub project plan with issue templates, dependency mapping, priority labels, sprint planning, and DevOps automation guidance.

When to invoke

• "Break this feature into GitHub issues."
• "Create an Epic > Feature > Story plan for this PRD."
• "Generate a project plan and issues checklist for this feature."
• "Map dependencies, priorities, labels, and estimates for GitHub Projects."
• "Create sprint planning and Kanban tracking for this feature."

Source artifacts

Use the feature artifacts available in the repository. Expected source paths are:

If the UX design or testing plan is present, use it. If an artifact is absent, proceed with available evidence and mark the gap in the plan.

Adjacent planning primitive names from legacy workflows may appear as plan-test, plan-epic-arch, or plan-feature-prd; treat them as source context labels, not files to link.

Work item hierarchy

Use placeholder issue references consistently while drafting: #{epic-issue-number}, #{feature-issue-number}, #{story-issue-number}, #{enabler-issue-number}, #{task-issue-number}, and #{test-issue-number}. Preserve milestone placeholders such as {Release version/date} until real data exists, and call out any post-release fixes that would violate the Definition of Done.

Planning principles

Procedure

1. Read the source artifacts and extract feature summary, business value, success criteria, user personas, technical scope, testing requirements, risks, dependencies, and constraints.
2. Create the project overview: feature summary, measurable outcomes/KPIs, key milestones without timelines, and risk assessment with mitigation.
3. Build the hierarchy from Epic to Feature to Story, Enabler, Test, and Task. Keep each story independently valuable and testable.
4. Map dependencies using Blocks, Blocked by, Related, Prerequisite, and Parallel. Identify the critical path.
5. Assign priorities, value labels, components, estimates, milestones, and project fields.
6. Generate /docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md and /docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md.
7. If sprint-by-sprint output, project board configuration, or GitHub Actions snippets are required, read references/sprint-planning-template.md and include its detailed material.

Project plan structure

Include these sections in project-plan.md:

graph TD
    A[Epic: {Epic Name}] --> B[Feature: {Feature Name}]
    B --> C[Story 1: {User Story}]
    B --> D[Story 2: {User Story}]
    B --> E[Enabler 1: {Technical Work}]
    B --> F[Enabler 2: {Infrastructure}]
    C --> G[Task: Frontend Implementation]
    C --> H[Task: API Integration]
    C --> I[Test: E2E Scenarios]
    D --> J[Task: Component Development]
    D --> K[Task: State Management]
    D --> L[Test: Unit Tests]
    E --> M[Task: Database Schema]
    E --> N[Task: Migration Scripts]
    F --> O[Task: CI/CD Pipeline]
    F --> P[Task: Monitoring Setup]

graph LR
    A[Epic Planning] --> B[Feature Definition]
    B --> C[Enabler Implementation]
    C --> D[Story Development]
    D --> E[Testing Execution]
    E --> F[Feature Delivery]
    G[Infrastructure Setup] --> C
    H[API Design] --> D
    I[Database Schema] --> C
    J[Authentication] --> D

Priority, value, and estimates

Success metrics

The detailed issues-checklist must cover stories/enablers and issue-creation readiness from end-to-end (to-end appears in legacy wording).

Progressive disclosure and bundled resources

Use bundled resources only when the requested output needs their detail:

• references/sprint-planning-template.md: sprint goal format, Kanban column structure, custom fields, GitHub Actions issue creation, automated status updates, and issue creation checklist details.

Gotchas

• Do not create untestable stories: every Story, Enabler, and Test must have acceptance criteria and Definition of Done evidence.
• Do not hide dependencies in prose: use Blocks, Blocked by, Related, Prerequisite, or Parallel so the project board can represent them.
• Do not put timeline guesses into key milestones unless the source artifacts provide dates; milestones are deliverable-oriented by default.
• Do not reference prompt files: refer to adjacent capabilities by primitive name and type, not by VS Code prompt paths.

Output template

## GitHub project plan result — <epic>/<feature>

**Status:** complete | partial | blocked
**Source artifacts:** <PRD, UX, technical breakdown, implementation plan, testing plan>
**Outputs:**
- `/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md`
- `/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md`

### Project overview
- **Feature Summary:** <summary>
- **Success Criteria:** <measurable outcomes and KPIs>
- **Key Milestones:** <deliverables>
- **Risk Assessment:** <blockers and mitigations>

### Issue hierarchy
| Type | Title | Parent | Priority | Value | Estimate | Dependencies |
| --- | --- | --- | --- | --- | --- | --- |
| Epic | <title> | - | P0-P3 | High/Medium/Low | XS-XXL | <none/list> |
| Feature | <title> | <epic> | P0-P3 | High/Medium/Low | <size> | <blocks/blocked by> |
| Story | <title> | <feature> | P0-P3 | High/Medium/Low | 1/2/3/5/8 | <dependencies> |
| Enabler | <title> | <feature> | P0-P3 | High/Medium/Low | <points> | <dependencies> |
| Test | <title> | <story/enabler> | P0-P3 | High/Medium/Low | <points> | <dependencies> |

### Validation
- INVEST criteria checked: pass | fail
- Definition of Ready checked: pass | fail
- Definition of Done checked: pass | fail
- Dependency graph checked: pass | fail
- Labels, estimates, milestones, and project fields checked: pass | fail

Quality gate

• Source artifacts and missing inputs are listed.
• The hierarchy includes Epic, Feature, Story, Enabler, Test, and Task where applicable.
• Every story follows INVEST Criteria and contains acceptance criteria, testing requirements, dependencies, and Definition of Done.
• Priority, value, component, estimate, sprint, assignee, epic, labels, and milestone guidance are present where needed.
• Dependency types and critical path are explicit.
• Project Management KPIs, Process Efficiency Metrics, and Project Delivery Metrics are preserved when relevant.
• Bundled references/sprint-planning-template.md is used only when sprint, board, automation, or detailed checklist output is required.
• The output follows ## Output template exactly.