القائمة
Cuts a new release with semantic versioning and GoReleaser. Use when the user wants to release a new version, tag a release, or understand release workflow.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Runs tests, lint, and format checks; explains CI workflows. Use when running or debugging tests, lint, or GitHub Actions.
Ensures human and AI documentation stay in sync with code and config. Use when changing behavior, adding features, refactoring, or when the user asks to update docs. Delegates the actual updates to the documentation-maintainer subagent.
Commits current changes and opens a pull request via GitHub CLI (gh). Use only when the user explicitly says "open a pull request", "open an pull request", or "create a pull request". Do not run this workflow for other requests.
| name | release-and-versioning |
| description | Cuts a new release with semantic versioning and GoReleaser. Use when the user wants to release a new version, tag a release, or understand release workflow. |
v0.1.0, v1.0.0).v prefix is required for the release workflow.git tag vX.Y.Zgit push origin vX.Y.Z.github/workflows/release.yml runs on tag push. GoReleaser creates the GitHub Release with three Lambda zip archives (webhook.zip, scaleup.zip, scaledown.zip), raw binaries, checksums, and release notes. The release body is generated by GitHub (changelog.use: github-native) and categorized by .github/release.yml and PR labels.git push or creating tags) without user confirmation.webhook, scaleup, scaledown) from lambda/cmd/*/. Each is packaged as a zip archive (e.g. webhook.zip) for AWS Lambda deployment. With changelog.use: github-native, the release body is generated by GitHub and categorized via .github/release.yml and PR labels. Release footer links to full changelog.goreleaser/goreleaser-action with release --clean and contents: write permission. Runs on self-hosted medium runner.With github-native changelog, release-note sections are determined by PR labels and .github/release.yml, not by commit subject. Apply the breaking-change label to PRs that introduce breaking changes so they appear under "Breaking Changes" in the generated release notes. Maintainers should apply the appropriate label (e.g. breaking-change, enhancement, bug) when merging so the next release is correctly categorized.
If the user only wants to understand the workflow, explain the steps and point to .goreleaser.yml, .github/release.yml, and .github/workflows/release.yml without running any commands.