菜单
Manage the full Go module release lifecycle: determine next semver version, update CHANGELOG.md, create and push a git tag, and verify pkg.go.dev picks up the new version. Use when the user asks to tag a release, bump the version, update the changelog, or publish a new module version.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audit and optimize CLI flag definitions across all skeptic subcommands. Reviews help text quality, global-vs-local flag modeling, short flag coverage, shorthand config-precedence safety, help formatter consistency, and test isolation. Use when adding flags, reviewing CLI ergonomics, refactoring subcommand interfaces, or debugging flag override behavior.
Audit a document against the codebase for accuracy, then tighten it: verify claims, cut drift, simplify, restructure for the reader. Use when the user says a doc is loose, stale, or wrong, or asks to tighten/audit a README, guide, config reference, or any prose that makes claims about code.
Generate, update, and maintain per-module documentation under docs/modules/, keep ARCHITECTURE.md and README.md current, and produce Mermaid diagrams for data-flow, block, and dependency views. Use when the user asks to document a package, update architecture docs, generate diagrams, or audit documentation freshness.
Add or update rule definitions, create and manage rule groups, and migrate rules across groups in skeptic using the property-based layout. Use when the user asks to add/update rules, add/manage groups, or reorganize `internal/rules`.
Ingest fresh security research from URLs/files, generate signed scanner rule packs, and validate with policy and behavior scan styles across ecosystems. Use when the user asks to operationalize new threat intel into skeptic detections.
Audit and update GitHub Actions workflow files to use the latest action releases pinned to full commit SHAs. Scans all .github/workflows/*.yml files, resolves current vs latest versions, and applies upgrades. Use when the user asks to update actions, check for outdated workflow dependencies, pin actions to SHAs, or audit CI workflow hygiene.
| name | go-release |
| description | Manage the full Go module release lifecycle: determine next semver version, update CHANGELOG.md, create and push a git tag, and verify pkg.go.dev picks up the new version. Use when the user asks to tag a release, bump the version, update the changelog, or publish a new module version. |
Tag a new semver release for the skeptic Go module. The release process is lightweight — no GoReleaser, no binary uploads. The git tag is the version, the CHANGELOG is the source of truth, and pkg.go.dev resolves the rest.
main is ready to be versioned| Bump | When |
|---|---|
| patch | Bug fixes, CI/CD changes, documentation, test improvements |
| minor | New rules, new features, new subcommands, license changes |
| major | Breaking CLI changes (renamed/removed flags, changed exit codes, removed subcommands) |
No major release has been made yet. Reserve v1.0.0 for when the CLI
surface is considered stable.
skeptic does not embed a semver string via ldflags. The Makefile
injects buildCommit, buildDate, and buildGoVersion at build time.
The semver lives only in the git tag and CHANGELOG. No code changes are
needed for a tag to work.
git tag --sort=-v:refname | head -5
git log $(git describe --tags --abbrev=0)..HEAD --oneline
Review the commits since the last tag. Apply the semver rules above to decide whether this is a patch, minor, or major bump.
Add a new section at the top of the changelog, below the # Changelog
heading and above the previous version entry:
## vX.Y.Z — YYYY-MM-DD
### Category
- Change description
Group changes under categories that match the nature of the work:
| Category | Use for |
|---|---|
| Detection | New rules, rule changes, behavior chains |
| Infrastructure | Scan engine, cache, decoders, correlation |
| CLI | New flags, subcommands, output changes |
| CI/CD | Workflow fixes, action updates |
| License | License changes |
| Documentation | Doc updates shipped with the release |
| Build | Toolchain, Makefile, build process |
Only include categories that have changes. Keep descriptions concise — one line per change.
The changelog update must be committed to main before tagging. Since
main has branch protection, this goes through a PR:
git checkout -b release/vX.Y.Z-prep
git add CHANGELOG.md
git commit -m "Add vX.Y.Z changelog entry"
git push -u origin HEAD
gh pr create --title "Release vX.Y.Z" --body "Changelog entry for vX.Y.Z."
Merge the PR before proceeding to the tag step.
After the changelog PR is merged and main is up to date:
git checkout main
git pull origin main
git tag -a vX.Y.Z -m "vX.Y.Z"
git push origin vX.Y.Z
Use an annotated tag (-a), not a lightweight tag. The message should
be the version string.
After pushing the tag, the Go module proxy needs to index the new version. Trigger it and verify:
curl -s "https://proxy.golang.org/github.com/TGPSKI/skeptic/@v/vX.Y.Z.info"
Then check the pkg.go.dev page:
https://pkg.go.dev/github.com/TGPSKI/skeptic@vX.Y.Z
It may take a few minutes for pkg.go.dev to update. Verify that:
If the release warrants release notes beyond the changelog:
gh release create vX.Y.Z --title "vX.Y.Z" --notes-file - <<'EOF'
Release notes here. Can reference the CHANGELOG for details.
EOF
For most releases, the changelog entry is sufficient and a GitHub release is not required.
git status must be clean.main
before tagging.main. The tag itself can be pushed directly since
rulesets apply to branch refs, not tag refs.main (via PR if branch protection active)git status clean on mainmain