peach-release

peach-release — batch release processing

Handles the release of the peach-harness repository all at once. Automates everything from syncing the two version files → updating CHANGELOG.md → commit/push to develop → create main PR → merge → create GitHub Release.

Prerequisites

• At the root of the peach-harness repositoryrun from
• develop checked out to the branch
• gh CLI authentication complete

---

Workflow

Step 1: Check status

git status && git branch && git log --oneline -5

• Verify that the branch is develop. If not, stop and notify the user.
• If there are unstaged changes, show them to the user and confirm whether to continue.

Step 2: Analyze → present plan at once

2-1. Check current version (double cross-verification)

grep '"version"' .claude-plugin/marketplace.json
grep '"version"' .claude-plugin/plugin.json

It is normal for the two values to match. If they do not match, stop and notify the user.

2-2. Extract new commits (based on the Release commit)

git log main..developincludes commits that have already been released when main is behind, so do not use. Instead, Release v{현재버전} extract only new commits after the commit.

CURRENT_VER=$(grep -m1 '"version"' .claude-plugin/plugin.json | grep -o '[0-9]*\.[0-9]*\.[0-9]*')
RELEASE_COMMIT=$(git log --oneline --all | grep "Release v${CURRENT_VER}" | head -1 | awk '{print $1}')
git log ${RELEASE_COMMIT}..HEAD --oneline
git diff ${RELEASE_COMMIT}..HEAD --stat

Core principle: the analysis target is Release v{현재버전} only new commits after the commit. Release v{현재버전} The commit itself is excluded from the analysis.

If there are 0 new commits, output "There are no changes to release" and stop.

2-3. Combined analysis + plan output

The AI analyzes the commits to determine the version type, and outputs the CHANGELOG draft and execution plan at once .

Version determination criteria (core skills: team series, gen-* series):

Change type	Version	Example
Documentation fixes, typos, bug fixes, adding utility skills	patch	Fixing SKILL.md errors, adding 1 auxiliary skill
Adding/improving core skills, changing agent logic	minor	Adding a new gen-* skill, improving the team workflow
Breaking backward compatibility, structural changes	major	Changing the distribution structure, changing skill interfaces

🚀 Release v{새버전} 계획
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
버전 검증:
  plugin.json      : v{현재버전}
  marketplace.json : v{현재버전}  ← 일치 ✅

커밋 ({N}개):
  {커밋 해시} {커밋 메시지}
  ...

버전: {현재버전} → {새버전} ({patch/minor/major})
이유: {판단 근거 한 줄}

📝 CHANGELOG.md 추가 내용:
## [v{새버전}] - {YYYY-MM-DD}

### Added
- ...

### Changed
- ...

### Removed
- ...

### Fixed
- ...

📦 실행 순서:
  1. marketplace.json / plugin.json 버전 업데이트
  2. CHANGELOG.md 맨 위에 블록 추가
  3. git commit -m "Release v{새버전}"
  4. git push origin develop
  5. gh pr create --base main --head develop --title "Release v{새버전}"
  6. gh pr merge {PR번호} --merge --delete-branch=false
  7. gh release create v{새버전} --target main
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
진행할까요? 수정이 필요하면 말씀해 주세요.

Dialog refinement: When the user requests a version change, CHANGELOG edit, item addition, etc., modify only that part and output the above plan again. Repeat until approval ("proceed") is given.

When the user approves proceed, execute Step 3 in order. If the user selects cancel, stop.

Step 3: Batch execution

After approval, execute the following tasks in order. Output progress as each step completes.

4-1. Update both version files simultaneously

Both files must always be updated to the same version at the same time. If they do not match, auto update will fail.

• .claude-plugin/marketplace.json → plugins[0].version
• .claude-plugin/plugin.json → version

4-2. Update CHANGELOG.md

Add the version block created in step 3 CHANGELOG.md at the top .

• If the section does not exist, omit it (do not create an empty section).
• Write each item concisely in one line in Korean.
• CHANGELOG.mdIf it does not exist, create a new one. Include the following header at the top of the file:

# Changelog

> [keep-a-changelog](https://keepachangelog.com) 포맷을 따릅니다.
> 버전은 [Semantic Versioning](https://semver.org)을 따릅니다.

CHANGELOG.md format (keep-a-changelog standard):

## [v{버전}] - {YYYY-MM-DD}

### Added
- 새로 추가된 스킬, 기능, 파일

### Changed
- 기존 기능 개선, 워크플로우 변경, 구조 개편

### Removed
- 제거된 스킬, 파일, 기능

### Fixed
- 버그 수정, 오타 수정

Classification criteria:

Commit prefix / file change	Section
feat:, add new SKILL.md	Added
refactor:, docs:, modify existing SKILL.md, restructure references	Changed
Delete file, move	Removed
fix:, fix typos	Fixed

4-3. Commit

git add .claude-plugin/marketplace.json .claude-plugin/plugin.json CHANGELOG.md
git commit -m "Release v{버전}"

4-4. Push develop

git push origin develop

4-5. Create main PR

Before running, check whether an existing PR exists. If a PR is already open, skip creation and use that number.

PR_NUM=$(gh pr list --base main --head develop --state open --json number --jq '.[0].number')
if [ -z "$PR_NUM" ]; then
  gh pr create \
    --base main \
    --head develop \
    --title "Release v{버전}" \
    --body "..."
  PR_NUM=$(gh pr list --base main --head develop --state open --json number --jq '.[0].number')
fi

For the PR body, use the contents of the version block just written in CHANGELOG.md as is.

## Release v{버전}

### 변경 사항
{CHANGELOG.md 해당 버전 블록의 내용}

### 버전
- {이전 버전} → {새 버전}
- 변경 유형: {patch/minor/major}

🤖 Generated with [Claude Code](https://claude.com/claude-code)

4-6. Merge PR

gh pr merge {PR_NUM} --merge --delete-branch=false

--delete-branch=false: Do not delete the develop branch.

4-7. Create GitHub Release

Before running, check whether a Release for the same version already exists. If it exists, skip creation.

if ! gh release view v{버전} > /dev/null 2>&1; then
  gh release create v{버전} \
    --title "v{버전}" \
    --notes "..." \
    --target main
else
  echo "ℹ️ Release v{버전} 이미 존재 — 건너뜀"
fi

For the release notes, use the corresponding version block in CHANGELOG.md as is.

Step 5: Completion report

✅ Release v{버전} 완료
- develop 커밋: {커밋 해시}
- PR: {PR URL}
- main 머지: 완료
- GitHub Release: {Release URL}

---

Rules

• Only on the develop branch update the version. Do not work directly on main.
• The version type (major/minor/patch) is determined by AI analysis.
• Output the analysis → CHANGELOG draft → execution plan all at once . Do not ask for the analysis and plan separately.
• If the user requests changes, revise only that part and output the plan again. Continue refining through conversation until approval ("proceed") is given.
• Approval is only once . Do not require individual approval for each step.
• The two version files must always be kept at the same version.
• In CHANGELOG.md, the latest version must always be at the top.
• The PR body and GitHub Release notes must be written based on the contents of CHANGELOG.md (do not write them twice).