feature-epic-breakdown

Étoiles14

Forks0

Mis à jour11 juillet 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

mpyw

mpyw/suve

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.