releasing-software
Skill17 starsChanged 51 days agoMITView on GitHub
Release prep and tagging with pre-flight verification. Use when user says release, tag, ship it, push to production, create release, or bump version. Not for editing a version string outside a release, a lockfile or a changelog entry by hand, and not for reading what changed in a past release: those are ordinary edits, just do them.
- Commits and pushes
In this repository37 other files it gives its agents.
- adrSkill
- android-kotlinSkill
- apple-swiftSkill
- autoresearch-promptSkill
- blog-writerSkill
- cloud-infrastructureSkill
- commitSkill
- cover-imageSkill
- freezeSkill
- gemini-reviewSkill
- golangSkill
- harness-mechanicSkill
- harness-traceSkill
- humanizerSkill
- ios-debuggerSkill
- knowledge-syncSkill
- learning-docsSkill
- learning-loopSkill
- obsidianSkill
- orchestratorSkill
- plan-forgeSkill
- process-clippingsSkill
- project-analyzerSkill
- project-checksSkill
- pr-reviewSkill
- pythonSkill
- railsSkill
- react-nextjsSkill
- refine-requirementsSkill
- rubySkill
- scoreSkill
- second-opinionSkill
- skill-forgeSkill
- source-controlSkill
- terraformSkill
- test-design-reviewerSkill
- verify-frontendSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Wait for pre-commit hooks
- Distinctive: line 34
Verify release workflow triggered
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ABOUTME: Release preparation skill with pre-flight verification, prevents retag-four-times pattern
ABOUTME: Invoked on "release", "tag", "ship it", "push to production"
Releasing Software
Rule
Tag only after CI is green on the release commit. Run full verification locally, fix everything, then tag: a tag cut before CI passes gets deleted and recut when CI fails, and every retag breaks whoever already pulled it.
Pre-Release Checklist
| Check | Items | Why |
| Build Paths | goreleaser.yml main:, workflows, Makefile, Dockerfile | Wrong path = build failure |
| Test Coverage | Every package has ≥1 test file | Go 1.23+ covdata fails without tests |
| Local CI | make test && make lint && make build | Catch failures before push |
| Docs | README.md, CHANGELOG.md, version refs | Professional releases |
| Release Config | goreleaser description, homepage URL, .gitignore | Proper artifact generation |
| Git State | git status, git diff --stat, git log | Clean history |
Release Procedure
Only after ALL checks pass:
- Commit:
git add -A && git commit -m "release: prepare vX.Y.Z" - Wait for pre-commit hooks
- Push and WAIT:
git push origin main - Check CI:
gh run list --limit 2 - Only after green:
git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z - Verify release workflow triggered
Stop and reassess if you catch yourself
- Tagging before CI completes
- "CI will probably pass"
- Deleting/recreating tags
- Force-pushing tags
Common Failures
| Symptom | Root Cause | Fix |
| "couldn't find main file" | Wrong goreleaser path | Set main: . if main.go at root |
| "no such tool 'covdata'" | Package without tests | Add _test.go with placeholder |
| Had to retag | Tagged before CI passed | Tag only after CI is green |
| Build fails but tests pass | Wrong build path | Check Makefile/goreleaser match |
Troubleshooting
# Verify goreleaser config
goreleaser check
# Dry run release
goreleaser release --snapshot --clean
# Check for packages without tests
find . -type d -not -path "*/.*" -exec sh -c 'ls {}/*_test.go 2>/dev/null || echo "No tests: {}"' \;Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

