メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
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.
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.
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.
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.
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.
| 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. |
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.
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.
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.
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.
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.fix(<area>): <imperative summary> (#<issue>).Closes #<issue>.