create-release

Note：ローカルに mcporter がインストールされている場合は、MCP ツールを直接呼び出すのではなく、mcporter を使って呼び出してください。mcporter CLI は、より便利なインターフェースと優れたエラー処理を提供します。

Gitee MCP によるリリースの作成

マージ済み PR の履歴から変更履歴を自動生成し、Gitee で適切に構成されたリリースを公開します。

前提条件

• Gitee MCP サーバーが設定済みであること（ツール：list_releases、list_repo_pulls、create_release）
• ユーザーがリポジトリのオーナー、リポジトリ名、バージョン番号を指定すること
• 任意：前のバージョン番号（変更履歴の範囲を決定するため）

手順

ステップ 1：バージョン番号を確認する

セマンティックバージョニングに従って、ユーザーにバージョン番号を確認します。

vMAJOR.MINOR.PATCH

- MAJOR: incompatible API changes
- MINOR: backward-compatible new features
- PATCH: backward-compatible bug fixes

ユーザーがバージョン番号を指定していない場合は、変更内容に応じた適切なバージョンを提案します。

ステップ 2：リリース履歴を確認する

list_releases を使って既存のリリースを取得します。

• 前のバージョン番号を確認する
• バージョンの命名規則を把握する（例：v 接頭辞を使っているかどうか）
• バージョン番号が重複しないようにする

ステップ 3：PR の変更内容を収集する

list_repo_pulls を使って、前回のリリース以降にマージされた PR を取得します。

• state：merged
• マージ時刻で並べ替え、前回のリリース以降の PR に絞り込む

各 PR を分類します。

• feat / feature：新機能
• fix / bugfix：バグ修正
• refactor：コードのリファクタリング
• perf：パフォーマンスの改善
• docs：ドキュメントの更新
• chore：依存関係／ビルド／ツールチェーンの変更
• breaking：破壊的変更（タイトルに breaking または !: を含む）

ステップ 4：コードの変更内容を分析する

PR のタイトルを補足するため、compare_branches_tags を使って、より詳細な差分分析を行います。

compare_branches_tags(owner="[owner]", repo="[repo]", target="[current_branch]", base="[previous_version_tag]")

次の情報が返されます。

• 変更されたファイル（追加、変更、削除）
• バージョン間のコミット履歴
• コードの統計（追加、削除）

これを使って、各 PR の背後にある実際のコード変更を把握します。PR のタイトルが不明瞭な場合に特に役立ちます。

ステップ 5：変更履歴を生成する

次のテンプレートを使って変更履歴を生成します。

## [v{version}] - YYYY-MM-DD

### ⚠️ Breaking Changes
- [PR title] (#PR number) @author

### ✨ New Features
- [PR title] (#PR number) @author
- [PR title] (#PR number) @author

### 🐛 Bug Fixes
- [PR title] (#PR number) @author

### ⚡ Performance
- [PR title] (#PR number) @author

### 📖 Documentation
- [PR title] (#PR number) @author

### 🔧 Other
- [PR title] (#PR number) @author

---

**Full changelog**: [link comparing previous version...current version]

変更のないセクションは省略します。

ステップ 6：確認してリリースを作成する

生成した変更履歴をユーザーに提示し、確認してもらいます。確認後、次のパラメーターを指定して create_release を使います。

• tag_name：バージョン番号（例：v1.2.0）
• name：リリースタイトル（例：Release v1.2.0）
• body：ステップ 4 で生成した変更履歴
• prerelease：プレリリース版（alpha / beta / rc）の場合は true に設定

作成に成功したら、リリースページへのリンクを出力します。

注意事項

• 一般的なプロジェクトの慣例に合わせ、バージョン番号には v 接頭辞を使用します（例：v1.2.0）
• 破壊的変更は、アップグレードするユーザーへの警告として目立つように記載する必要があります
• PR のタイトルがセマンティックでない場合は、元の意図を保ちながら、変更履歴内で軽く言い換えます
• プレリリース版（alpha / beta / rc）は prerelease=true に設定し、安定版のリリース系列に影響しないようにします