Set up or align a GitHub Actions release pipeline for a versioned package, library, CLI, or marketplace action. Use when standardizing repos around the verify-then-release shape: push to main → guardrails → semantic-release tags + publishes → version-bump commit back to main with [skip ci].
99
100%
Does it follow best practices?
Impact
98%
1.55xAverage score across 4 eval scenarios
Passed
No known issues
action.yml uses dist/index.js
100%
100%
dist built in verify
100%
100%
Moving major tag step
100%
100%
Major tag step is conditional
100%
100%
No npm publish plugin
100%
100%
SR plugins for action
100%
100%
git before github
100%
100%
skip ci on both jobs
0%
100%
Release concurrency non-cancellable
0%
100%
fetch-depth: 0
50%
100%
Bot identity in step env
0%
100%
SR action v4
100%
100%
fetch-depth verify
0%
100%
fetch-depth release
100%
100%
Verify concurrency group
0%
100%
Release concurrency group
50%
100%
skip ci on verify
0%
100%
skip ci on release
0%
100%
Bot identity in step env
0%
100%
Bot uses noreply address
0%
100%
Release permissions
100%
100%
semantic-release action version
0%
100%
Plugin order
50%
100%
Matching preset
0%
100%
git plugin message
100%
100%
registry-url in setup-node
0%
100%
release needs verify
100%
100%
Secrets on step
100%
100%
Tag-only SR plugins
0%
100%
GoReleaser conditional
0%
100%
GoReleaser --clean flag
80%
100%
Tap repo naming
100%
100%
TAP_GITHUB_TOKEN scope
75%
100%
Attestation permissions
100%
100%
Attest step conditional
37%
100%
GoReleaser brews block
100%
100%
No non-Go Homebrew action for Go
100%
100%
fetch-depth: 0
50%
100%
skip ci guards
0%
100%
Release concurrency
0%
100%
Secrets on step
66%
100%
SR action version
0%
100%
Uses sibling action
100%
100%
Removes incompatible action
100%
100%
No inline tap hack
100%
100%
Direct tap inputs
100%
100%
Conditional on release
100%
100%
Token scope documented
100%
100%
Preserves semantic-release
100%
100%
No broad PAT advice
50%
100%
Mentions sibling precedent
0%
0%
No manual PR requirement
100%
100%