菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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 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.
Load when wiring a top-level command group, adding a cloud, or touching internal/provider/registry.go, internal/provider/detect/, or internal/cli/commands/internal/client.go. Explains how a provider is selected (explicit groups plus env-detected flat aliases), how the registry composes backends, how each provider's scope is built, and the SDK-confinement boundary.
| name | release-highlights |
| description | 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. |
Every tag's release body is auto-generated by .github/workflows/release.yml: NEW_NOTES (GitHub's generate-notes → ## What's Changed + Full Changelog) followed by the ## Downloads table (.github/templates/release-notes-downloads.md). Highlights are not part of that flow. A ## Highlights section is written by hand after the release exists and prepended to the auto-generated body — leave ## What's Changed and ## Downloads untouched. Precedent: v1.9.0 (TUI), v1.9.1 (npm + cloud shell), v1.9.2 (CloudShell fix).
Write them when a reader skimming the release needs a "what changed and why it matters" that the raw PR list doesn't convey:
A pure dependency-bump or internal-only patch does not need them.
## Highlights heading.No breaking changes; existing CLI, TUI, and GUI behavior is unchanged. Only claim a break when there genuinely is one.### subsections grouping related items (e.g. Distribution, Cloud shell support, TUI, Documentation, Quality, CI). Order most-to-least user-facing.(#PR) references. Cite the PRs that delivered the item; a coverage/sweep item may cite a range (#831–#848).Keep it accurate: only claim what the PRs actually did, and don't assert an epic is "complete" unless verified.
Reconstruct the full body (Highlights + existing) rather than editing in the GitHub UI — the auto-generated tail must survive verbatim.
gh release view vX.Y.Z --json body -q .body > body.md # existing (## What's Changed … ## Downloads)
# write highlights.md, then:
cat highlights.md body.md > full.md
gh release edit vX.Y.Z --notes-file full.md
immutable: true on a release refers to its assets, not the body — the notes stay editable, and re-running gh release edit is safe and reversible.
Editing a public release page is outward-facing; draft the Highlights text and confirm with the maintainer before publishing unless already told to proceed.