본문으로 건너뛰기
cccskills
무료GitHub에 공개

releasing-software

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구GitHub
설치 방법 보기

포함된 파일(1)

  • SKILL.md4.4 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Releasing Software

Overview

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.

The Iron Law

NO TAG WITHOUT GREEN CI

Run the full verification locally. Fix everything. THEN tag. Not before.

Pre-Release Checklist

MANDATORY: Use TodoWrite to create todos for EACH item.

1. Verify Build Paths

Check ALL places that reference your main package:

  • goreleaser.yml - main: field (common: ./cmd/app vs .)
  • .github/workflows/*.yml - any go build commands
  • Makefile - build targets
  • Dockerfile - 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"

2. Verify Tests Exist

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".

3. Verify Local CI Passes

# 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

4. Verify Documentation

  • README.md exists and is current
  • CHANGELOG.md updated (if maintained)
  • Version references updated

5. Verify Release Config

  • goreleaser description is correct (not template leftovers)
  • goreleaser homepage URL is correct
  • .gitignore includes build artifacts, coverage files

6. Verify Clean Git State

git status                    # Nothing unexpected staged
git diff --stat              # Review all changes
git log --oneline -5         # Verify recent history

Release Procedure

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

Red Flags - STOP

If you catch yourself doing any of these, STOP:

  • Tagging before CI completes
  • "CI will probably pass"
  • "I'll fix it if it fails"
  • Deleting and recreating tags
  • Force-pushing tags
  • "It's just a minor release"

All of these mean: Wait for CI. Fix issues. Then tag.

Common Failures

SymptomCauseFix
couldn't find main fileWrong path in goreleaserSet main: . if main.go at root
no such tool "covdata"Package without testsAdd placeholder test to each package
Release succeeds but brew failsWrong description/homepageUpdate goreleaser brews section
Had to retagTagged before CI passedWAIT FOR GREEN CI
504 errors in CIGitHub infra issueRetry workflow, not a code problem

Version Bumping

When incrementing version:

  1. Patch (0.0.X): Bug fixes, no new features
  2. Minor (0.X.0): New features, backwards compatible
  3. Major (X.0.0): Breaking changes

Search codebase for version references:

grep -r "version" . --include="*.go" --include="*.yml" --include="*.json" | grep -v test | grep -v vendor

Post-Release Verification

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

The Bottom Line

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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

Create user-facing App Store release notes by collecting and summarizing all user-impacting changes since the last git tag (or a specified ref). Use when asked to generate a comprehensive release changelog, App Store "What's New" text, or release notes based on git history or tags.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

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".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

harperreed/dotfiles3352026년 10월 16일 업데이트

harperreed의 스킬 모두 보기

이 스킬의 문제 신고