feature-epic-breakdown

Stars14

Forks0

UpdatedJuly 11, 2026 at 23:17

Use when planning a multi-PR feature or cross-cutting refactor as an epic — write a design-complete epic body, slice into layer-ordered sub-issues that each restate their slice standalone with DELETE/ADD/MODIFY tasks and dependencies, use an integration branch when the change must land coherently, and require a context-isolated review before every PR.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

mpyw

mpyw/suve

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	feature-epic-breakdown
description	Use when planning a multi-PR feature or cross-cutting refactor as an epic — write a design-complete epic body, slice into layer-ordered sub-issues that each restate their slice standalone with DELETE/ADD/MODIFY tasks and dependencies, use an integration branch when the change must land coherently, and require a context-isolated review before every PR.

Feature epic breakdown

Plan a feature so that each sub-issue is a self-contained PR and the whole lands coherently. Evidence: #451 (the gold standard — export/import, sub-issues #452–457), #419 (phased domain→adapters→usecase→CLI→GUI refactor), #410 (integration-branch epic).

Epic body

Write the epic so a work agent needs nothing else:

Summary → Motivation.
Finalized design — schemas and tables inline, not linked. #451 embeds the full JSON envelope schema and a complete CLI-surface table; #419 tables the per-provider semantics being modeled.
Sub-issues in dependency order, with the order stated explicitly (#452 → #453 → #454 → (#455 and #456 in parallel) → #457; each green under its gates before the next starts).
Edge cases shared across all steps — called out once, centrally.
Blast radius — file counts per layer, so scope is legible.
Validation gates — the concrete mise commands.
"Done when" acceptance criteria (#410 closes with an explicit Done-when list).

Slicing

Slice by layer, in dependency order:

Storage (schema, serialization; delete the thing being replaced).
Usecase (business logic).
CLI + e2e (commands, wiring, e2e coverage).
GUI (Go DTO/API, regenerated wailsjs bindings, Svelte view, Playwright).
Docs + breaking-change note (reference docs current-state-only; migration to release notes).
Final integration & comprehensive review — its own last sub-issue (#457).

Each sub-issue must: restate its slice standalone (a fixer reads only that issue), list DELETE / ADD / MODIFY tasks against concrete file:line sites, name its gates, and state its dependency (Do not start until Step 2 (Usecase) is merged — #454). Link children as GitHub sub-issues and mirror them as a body checklist.

Integration branch

When the change must land as one coherent concept rather than piecemeal, sub-PRs target an integration branch epic/<name> and a final PR merges it to main (epic/version-state-vs-staging-labels in #419; epic/appconfig-namespace-terminology in #410). Otherwise each sub-PR targets main directly.

Mandatory review clause

Include this clause verbatim in the epic (and echo it in each sub-issue, as #454 does):

Before opening the PR, have a context-isolated subagent (one that does not share this conversation's context) perform a critical review of the changes, apply the quality improvements it surfaces, and only then open the pull request.

More from this repository

same repository

docs-site-pages

mpyw/suve

Use when restructuring the README or the GitHub Pages site generated from it — the left-nav/left-pane, section reorg, or per-provider command docs. Covers the build-docs-site.py split + literate-nav SUMMARY pipeline, its HTML-comment directives and site-only transforms (nav-group, site:skip, hero <h1>, asset ../ prefix, DOC_NAV grouping), the python-markdown gotchas GitHub hides, and the `mise docs-build` strict gate.

2026-07-1614

release-highlights

mpyw/suve

Use when authoring or backfilling the "## Highlights" section of a GitHub release — the human-written summary that prepends the auto-generated notes. Covers when a release earns highlights, the fixed format (bold lead + breaking-change note, `###` subsections, PR-referenced bullets), and the prepend-in-place mechanics.

2026-07-1514

refresh-demo-gifs

mpyw/suve

Use when re-recording the CLI, TUI, or GUI demo GIFs after a UI change or a user-visible output change. Covers the record scripts, robust Playwright selectors, output-drift triggers, frame verification, and Git LFS.

2026-07-1314

collection-idioms

mpyw/suve

Load when writing or reviewing Go that builds or transforms slices/maps. Prefer samber/lo, samber/lo/it, and stdlib slices/maps callback & iterator utilities over hand-rolled make + range + append; keep an explicit loop only where side effects or control flow are genuinely complex.

2026-07-1214

suve-cli-map

mpyw/suve

Load when you need the per-provider capability, versioning, and alias matrix for suve's CLI without reading the full docs/{aws,azure,gcloud}.md option tables. A one-page orientation; link out for per-command detail.

2026-07-1214

provider-seam-invariants

mpyw/suve

Load when adding or modifying a provider adapter, or when touching internal/provider/** or internal/domain/**. Captures the invariants that keep the provider-neutral seam honest: the neutral domain model, opaque version refs, the typed write/delete option pattern, interface segregation, and SDK confinement.

2026-07-1214

name	feature-epic-breakdown
description	Use when planning a multi-PR feature or cross-cutting refactor as an epic — write a design-complete epic body, slice into layer-ordered sub-issues that each restate their slice standalone with DELETE/ADD/MODIFY tasks and dependencies, use an integration branch when the change must land coherently, and require a context-isolated review before every PR.

Feature epic breakdown

Epic body

Write the epic so a work agent needs nothing else:

Summary → Motivation.
Finalized design — schemas and tables inline, not linked. #451 embeds the full JSON envelope schema and a complete CLI-surface table; #419 tables the per-provider semantics being modeled.
Sub-issues in dependency order, with the order stated explicitly (#452 → #453 → #454 → (#455 and #456 in parallel) → #457; each green under its gates before the next starts).
Edge cases shared across all steps — called out once, centrally.
Blast radius — file counts per layer, so scope is legible.
Validation gates — the concrete mise commands.
"Done when" acceptance criteria (#410 closes with an explicit Done-when list).

Slicing

Slice by layer, in dependency order:

Storage (schema, serialization; delete the thing being replaced).
Usecase (business logic).
CLI + e2e (commands, wiring, e2e coverage).
GUI (Go DTO/API, regenerated wailsjs bindings, Svelte view, Playwright).
Docs + breaking-change note (reference docs current-state-only; migration to release notes).
Final integration & comprehensive review — its own last sub-issue (#457).

Integration branch

Mandatory review clause

Include this clause verbatim in the epic (and echo it in each sub-issue, as #454 does):

Before opening the PR, have a context-isolated subagent (one that does not share this conversation's context) perform a critical review of the changes, apply the quality improvements it surfaces, and only then open the pull request.