bug-fix-pr

Étoiles14

Forks0

Mis à jour11 juillet 2026 à 23:17

Use when turning one filed bug issue into a fix PR — reproduce from the issue's Failure-scenario section, fix at the cited site, add a regression test at every layer the three-layer rule names, run the gates, and write a PR whose Verification section shows real command output.

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	bug-fix-pr
description	Use when turning one filed bug issue into a fix PR — reproduce from the issue's Failure-scenario section, fix at the cited site, add a regression test at every layer the three-layer rule names, run the gates, and write a PR whose Verification section shows real command output.

Bug fix PR

One filed bug = one PR. Evidence for this workflow: the fix-PR waves #363–#408, #494–#517, #571–#613, each closing a single audit child.

Procedure

1. Reproduce first

Read the issue. Its ## Failure scenario gives the exact reproduction; its ## Where gives the file:line anchors. Replay the failure before touching anything, so the fix is validated against a real reproduction rather than a guess. Confirm the cites still resolve at current main.

2. Fix at the cited site

Make the minimal correct change at the anchors the issue names. If the true root cause is elsewhere, fix the root cause and say so in the PR body — do not paper over it at the symptom site.

3. Regression test at every layer the three-layer rule names

A feature/bug that is visible at multiple layers must be tested at each: Go unit test, CLI e2e test, and GUI Playwright test. Anything visible in the GUI needs Playwright coverage — a Go-only fix for a GUI-visible bug is incomplete (cf. #417 tag-only staged changes made visible in the Staging Area; #606 auto-unstaged notice; #607 inline-row double-fire guard, all with Playwright coverage). Add the regression test at the layer the bug actually lives in, plus any layer that surfaces it.

4. Run the gates

mise test and mise lint — always.
mise e2e-aws (and the -gcloud / -azure-appconfig / -azure-keyvault variants for the affected providers) when command behavior changed.
mise build-gui when GUI code or the wailsjs bindings were touched.

5. Write the PR

Title: fix(<area>): <imperative summary> (#<issue>).
Body opens with Closes #<issue>.
Body ends with a Verification section showing real command output (the actual test/gate runs, or a before/after transcript) — not a claim that it passes. #231 and #619 are the exemplars for a Verification section.
Before opening the PR, have a context-isolated subagent critically review the change and apply the improvements it surfaces (repo convention).

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

Bug fix PR

One filed bug = one PR. Evidence for this workflow: the fix-PR waves #363–#408, #494–#517, #571–#613, each closing a single audit child.

Procedure

1. Reproduce first

2. Fix at the cited site

Make the minimal correct change at the anchors the issue names. If the true root cause is elsewhere, fix the root cause and say so in the PR body — do not paper over it at the symptom site.

3. Regression test at every layer the three-layer rule names

4. Run the gates

mise test and mise lint — always.

mise e2e-aws (and the -gcloud / -azure-appconfig / -azure-keyvault variants for the affected providers) when command behavior changed.

mise build-gui when GUI code or the wailsjs bindings were touched.

5. Write the PR

Title: fix(<area>): <imperative summary> (#<issue>).

Body opens with Closes #<issue>.

Body ends with a Verification section showing real command output (the actual test/gate runs, or a before/after transcript) — not a claim that it passes. #231 and #619 are the exemplars for a Verification section.

Before opening the PR, have a context-isolated subagent critically review the change and apply the improvements it surfaces (repo convention).