菜单
Use when preparing a release, tagging a version, or when user says "release", "tag", "ship it", "push to production" - ensures all release artifacts are verified before tagging to avoid the retag-four-times failure pattern
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when evaluating, designing, or pressure-testing the business model of an AI agent product. Triggers on "agent business model", "agent economics", "agent canvas", "evaluate agent product", "agent pricing", "agent unit economics", "agentic business", "AI agent company", "agent cost structure".
Use when someone wants to launch a content brand from scratch on any platform. Triggers on "launch a channel", "start a YouTube channel", "build a podcast", "start a newsletter", "content brand", "creator launchpad", "build my audience", "start creating content", "grow on TikTok", "start a blog".
Use when you have an existing pipeline DOT file that needs review, fixing, or validation. Use when validation produces warnings or errors, when a DOT file was hand-written or generated by another tool, or when you want to verify a pipeline covers 100% of a spec before running it.
Use when you want to build a project but don't have a spec yet and need to brainstorm the idea into a design doc structured for pipeline DOT generation. Use when starting from a vague idea, project concept, or feature request that needs to become a headless autonomous build pipeline.
Use when you have a spec, design doc, structured plan, or prompt_plan and need to generate a pipeline Graphviz DOT file for headless autonomous building. The agent reads the spec, extracts build pipeline phases, determines tech stack, asks about human gates and model preferences, generates a validated DOT digraph with rich self-contained prompts, and saves it to the project root. Handles any language or framework.
Use when a pipeline DOT file has passed structural validation but may still have flow inefficiencies, spec fidelity gaps, or information loss in prompts. Use after dotfile-audit or dotfile-from-spec when you want to deeply verify a pipeline captures everything from the original spec. Use when prompts might be missing critical domain rules, data models, or invariants.
| name | releasing-software |
| description | Use when preparing a release, tagging a version, or when user says "release", "tag", "ship it", "push to production" - ensures all release artifacts are verified before tagging to avoid the retag-four-times failure pattern |
Never tag until CI passes. Every retag erodes trust and wastes time.
This skill prevents the "tag, watch CI fail, retag, repeat" anti-pattern by establishing a pre-flight checklist that catches issues BEFORE creating the tag.
NO TAG WITHOUT GREEN CI
Run the full verification locally. Fix everything. THEN tag. Not before.
MANDATORY: Use TodoWrite to create todos for EACH item.
Check ALL places that reference your main package:
goreleaser.yml - main: field (common: ./cmd/app vs .).github/workflows/*.yml - any go build commandsMakefile - build targetsDockerfile - build commands# Find all references to cmd/ or main package paths
grep -r "cmd/" . --include="*.yml" --include="*.yaml" --include="Makefile" --include="Dockerfile"
grep -r "go build" . --include="*.yml" --include="*.yaml" --include="Makefile"
Go 1.23+ coverage tool fails on packages without tests:
# Check for test files in each package
find . -name "*_test.go" | wc -l
# If zero, add placeholder tests to EVERY package
Every package needs at least one test file or CI coverage step fails with no such tool "covdata".
# Run what CI runs
make test # or go test ./...
make lint # or golangci-lint run
make build # verify it compiles
# If using coverage
make test-coverage
.gitignore includes build artifacts, coverage filesgit status # Nothing unexpected staged
git diff --stat # Review all changes
git log --oneline -5 # Verify recent history
Only after ALL checks pass:
# 1. Commit all changes
git add -A && git commit -m "release: prepare v0.0.X"
# 2. Wait for pre-commit hooks to pass
# If hooks fail, fix and re-commit
# 3. Push and wait for CI
git push origin main
# 4. WAIT FOR CI TO PASS - check status
gh run list --limit 2
# OR watch in browser
# 5. Only after CI is green, create tag
git tag -a v0.0.X -m "v0.0.X"
git push origin v0.0.X
# 6. Verify release workflow completes
gh run list --limit 2
If you catch yourself doing any of these, STOP:
All of these mean: Wait for CI. Fix issues. Then tag.
| Symptom | Cause | Fix |
|---|---|---|
couldn't find main file | Wrong path in goreleaser | Set main: . if main.go at root |
no such tool "covdata" | Package without tests | Add placeholder test to each package |
| Release succeeds but brew fails | Wrong description/homepage | Update goreleaser brews section |
| Had to retag | Tagged before CI passed | WAIT FOR GREEN CI |
| 504 errors in CI | GitHub infra issue | Retry workflow, not a code problem |
When incrementing version:
Search codebase for version references:
grep -r "version" . --include="*.go" --include="*.yml" --include="*.json" | grep -v test | grep -v vendor
After tag is pushed:
# Watch release workflow
gh run watch
# Verify release assets
gh release view v0.0.X
# Test installation (if applicable)
go install github.com/user/repo@v0.0.X
Retagging is a symptom of rushing.
The 5 minutes spent on pre-flight checks saves 30 minutes of retag cycles and preserves your release history integrity.
Every tag should be final. If you're deleting tags, you skipped the checklist.