---
name: version-bump
description: Cargo.tomlのバージョンをセマンティックバージョニングに従ってバンプアップし、git tagを作成する。前回のgit tagからの差分を分析してバージョン種別（major/minor/patch）を自動判定する。「バージョンを上げて」「リリースして」「version bump」「バージョンアップ」などのリクエストで起動。
---

# Version Bump

Cargo.tomlのバージョンをバンプアップし、git tagを作成する。

## ワークフロー

### 1. 現在の状態を分析

```bash
# 最新のバージョンタグを取得
git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0"

# 前回タグからの差分を取得
git diff <前回タグ>..HEAD --stat
git diff <前回タグ>..HEAD
```

### 2. バージョン種別を判定

差分の内容を分析し、以下の基準でバージョン種別を判定：

| 種別      | 判定基準                                                                   |
| --------- | -------------------------------------------------------------------------- |
| **major** | 破壊的変更：パブリックAPIのシグネチャ変更、削除、互換性のない変更          |
| **minor** | 機能追加：新しいパブリック関数/構造体/モジュールの追加、新機能             |
| **patch** | バグ修正：既存機能の修正、リファクタリング、ドキュメント更新、依存関係更新 |

### 3. ユーザーに提案

判定結果をユーザーに提示し、AskUserQuestionで確認：

```
現在のバージョン: X.Y.Z
提案バージョン: X.Y.Z+1 (patch)

主な変更点:
- [変更内容のサマリー]

このバージョンでよろしいですか？
```

選択肢：
- 提案通り (patch/minor/major)
- 別のバージョン種別を選択

### 4. バージョンを更新

ユーザー承認後：

1. Cargo.tomlの`version`フィールドを更新
2. `cargo check`で検証
3. `cargo test`で全テスト通過を確認（**必須**: バージョン文字列がテストの期待値に含まれている場合の不整合をここで検出する）
4. 変更をコミット: `chore: bump version to X.Y.Z`
5. git tagを作成: `vX.Y.Z`

テストが失敗した場合は、コミットせずにユーザーに報告して原因を特定する。バージョン文字列由来の失敗であれば、テスト側を動的化（例: `env!("CARGO_PKG_VERSION")`）するか期待値ファイルを更新する。

### 5. 完了報告

```
バージョンを v{新バージョン} に更新しました。

git push && git push --tags でリモートに反映してください。
```

## 注意事項

- タグは`v`プレフィックス付き（例: v1.2.3）
- Cargo.lockが存在する場合は自動更新される
- ワークスペースの場合はルートのCargo.tomlのみ更新