git-flow-release-manager

SKILL.md

---
name: git-flow-release-manager
description: Use when user says 'release', 'リリース', 'publish', 'vtag', 'version up', 'バージョンアップ', 'bump version', 'prepare release', 'ship version', or discusses merging to main/develop. Guides through version bump and release flow.
---

# Release Procedure

Manage the entire release flow (version bump → CI → PR → merge → vtag → JSR publish). If CI is green, automatically proceed to the next step (no user confirmation needed).

## Release Flow

```
develop → release/* →PR→ develop →PR→ main → vtag → publish.yml → JSR
```

## Version Files

The "version" in `deno.json` and the `VERSION` in `lib/version.ts` must match. Patch (x.y.Z): bug fixes / Minor (x.Y.0): new features / Major (X.0.0): breaking changes

## Execution Rules (Must Read)

**When this skill is activated, always register the following task list with TaskCreate and execute and mark complete (`[x]`) one step at a time in order. Skipping, batch execution, or changing the order is prohibited.**

- Each step is **execute → check results → automatically proceed**. If CI/command succeeds, proceed without waiting for confirmation.
- Do not proceed to the next step if the previous step is incomplete (`[ ]`).
- On failure, stay on the current step, resolve the cause, and retry (do not proceed). Report failures or unexpected states (branch divergence, conflict, CI failure, etc.) to the user.
- Always check the output after running commands and mark success explicitly before checking.
- Replace `X.Y.Z` with the actual version. Replace `<PR#>` with the obtained PR number after creation.

## Task List (All steps must be performed in order)

### Phase 1: Preparation

- [ ] **Step 1. Prepare release branch** — `git fetch origin && git checkout develop && git pull --ff-only origin develop && git checkout -b release/vX.Y.Z`
  - If `pull --ff-only` fails (local has diverged), reset with `git reset --hard origin/develop` before creating the branch. The release skill assumes no local unique commits on develop/main.
  - Confirm: Check that `git branch --show-current` shows `release/vX.Y.Z` before checking.
- [ ] **Step 2. Version bump (must be done immediately after Step 1, no other commits before this)** — `scripts/bump_version.sh --patch` (or `--minor` / `--major`)
  - Confirm: Check that `grep '"version"' deno.json` and `grep 'VERSION' lib/version.ts` match before checking.
- [ ] **Step 3. Update CHANGELOG.md** — Append this release's contents
  - Confirm: Check differences with `git diff CHANGELOG.md` before checking.
- [ ] **Step 4. Local CI** — `deno task ci`
  - Confirm: Verify all tests pass before checking. Stay on this step if it fails.

### Phase 2: Release Branch → Develop

- [ ] **Step 5. Commit & push** — `git add deno.json lib/version.ts CHANGELOG.md && git commit -m "chore: bump version to X.Y.Z" && git push -u origin release/vX.Y.Z`
  - Confirm: Verify push completion with `git log -1` and `git status` before checking.
- [ ] **Step 6. Create PR: release/* → develop** — `gh pr create --base develop --head release/vX.Y.Z --title "Release vX.Y.Z"`
  - Confirm: Record the returned PR URL/number before checking.
- [ ] **Step 7. Wait CI & merge (release → develop)** — `gh pr checks <PR#> --watch && gh pr merge <PR#> --merge`
  - Confirm: Automatically merge after CI is green. Verify merged status with `gh pr view <PR#>` before checking. Report to user and stop if CI fails.

### Phase 3: Develop → Main

- [ ] **Step 8. Create PR: develop → main** — `gh pr create --base main --head develop --title "Release vX.Y.Z"`
  - Confirm: Record the returned PR URL/number before checking.
- [ ] **Step 9. Wait CI & merge (develop → main)** — `gh pr checks <PR#> --watch && gh pr merge <PR#> --merge`
  - Confirm: Automatically merge after CI is green. Verify merged status with `gh pr view <PR#>` before checking. Report to user and stop if CI fails.

### Phase 4: Tag & Publish

- [ ] **Step 10. Create vtag on main** — `git fetch origin main && git tag vX.Y.Z origin/main && git push origin vX.Y.Z`
  - Confirm: Verify the tag exists remotely with `git ls-remote --tags origin vX.Y.Z` before checking.
- [ ] **Step 11. Trigger JSR publish** — `gh workflow run publish.yml -f tag=vX.Y.Z`
  - Confirm: Verify the run started with `gh run list --workflow=publish.yml` before checking.
- [ ] **Step 12. Verify JSR publication** — Confirm version is reflected on the JSR page
  - Confirm: Check that vX.Y.Z is published at `https://jsr.io/@tettuan/breakdown` before checking.

### Phase 5: Post-release

- [ ] **Step 13. Sync local develop & main to HEAD** — `git fetch origin && git checkout main && git pull --ff-only origin main && git checkout develop && git pull --ff-only origin develop`
  - If `pull --ff-only` fails (local has diverged), reset with `git reset --hard origin/<branch>`. The release skill assumes no local unique commits on develop/main.
  - Confirm: Verify `git log develop..origin/main` and `git log main..origin/develop` are empty before checking.
- [ ] **Step 14. Cleanup release branch** — `git branch -D release/vX.Y.Z && git push origin --delete release/vX.Y.Z`
  - Confirm: Verify `git branch -a | grep release/vX.Y.Z` is empty before checking.
- [ ] **Step 15. Start next feature branch** — Explicitly call `/create-feature-branch` to create the next development branch
  - Do not complete this within the release skill; always delegate to the `/create-feature-branch` skill (to maintain branch naming conventions and Git Flow consistency).
  - **Default behavior**: If the user does not explicitly specify (issue number, feature name, etc.), derive the next patch version release branch from `develop`. For example, if the previous release was `vX.Y.Z`, create `release/vX.Y.(Z+1)` from `develop`.
  - Confirm: Verify the new branch is shown by `git branch --show-current` and is derived from `develop` before checking.

Refer to `/branch-management` for branch strategy and `/local-ci` `/ci-troubleshooting` for CI.

## Notes

- Never push directly to `main` or `develop`
- Version in `deno.json` must match `lib/version.ts` and tag
- Flow: `release/* → develop → main` (direct PR to main is prohibited)
- vtag is created manually (auto-release.yml only works if the head branch is `release/*`)
- JSR publish requires manual trigger after vtag
- **After creating the release branch, the first commit must always be the version bump. Do not commit other changes first.** This causes GitHub Actions Version Consistency Check to fail.