| name | release-changelog-workflow |
| description | Use this skill when preparing releases, version bumps, changelog entries, GitHub tag workflows, GoReleaser changes, generated release notes, or release-gate summaries in ametel01 repos. It detects manual changelog versus tag-driven release variants. |
Release Changelog Workflow
Purpose
Keep release work aligned with each repo's observed release mechanism instead of imposing one universal process.
When to use
Use when editing CHANGELOG.md, version fields, release workflows, installer scripts, GoReleaser config, package metadata, or docs that describe shipped behavior.
Evidence from repositories
Strength: Moderate.
agents-toolbelt: CHANGELOG.md follows Keep a Changelog and SemVer; .github/workflows/release.yml runs GoReleaser on v* tags with checksums, cosign, and provenance.vitals-db: CHANGELOG.md documents SemVer releases with release-gate commands and release links.agent-vitals: CHANGELOG.md uses version sections and user-facing change categories.horizon-starknet: .github/workflows/release.yml creates GitHub releases from v* tags with generated notes and prerelease detection.
Standard workflow
- Detect the repo's release variant from
CHANGELOG.md, version fields, and .github/workflows/release.yml.
- Update changelogs only when the repo already keeps one or the user asks.
- Keep release notes user-facing: Added, Changed, Fixed, Removed, security, release gate, and migration notes where relevant.
- Include validation commands actually run for the release candidate when the repo's changelog uses release gates.
- For tag-driven workflows, do not create tags or releases unless the user explicitly asks.
Variant table
| Variant | Repos | Guidance |
|---|
| Manual changelog plus SemVer | agents-toolbelt, vitals-db | Preserve Keep a Changelog-style headings and release links when present |
| Simple version changelog | agent-vitals | Match existing concise version sections |
| Generated GitHub release notes | horizon-starknet | Keep workflow tag behavior; changelog may not be canonical |
| No clear release process | orgs-ai-harness | Do not invent a changelog or release workflow without explicit request |
Required checks
- Confirm version numbers and dates are consistent.
- Keep tag pattern
v* workflows intact unless deliberately changing release behavior.
- If touching GoReleaser or install scripts, run or explain release-specific validation.
- Link changelog entries to actual changed behavior, not internal implementation churn.
Common pitfalls
- Do not assume every repo uses Keep a Changelog, even though several do.
- Do not use generated release notes as a substitute for manual changelog entries in repos that maintain them.
- Do not claim release validation commands ran unless they did.
Escalation / uncertainty rules
If release evidence is weak, phrase changes as draft release notes and ask before tagging, publishing, or modifying release automation.
