Balance Milestones Skill

マイルストーン未割り当ての Issue にマイルストーンを紐づけ、偏りがあれば調整・新規作成する。

前提条件

• gh CLI が認証済みであること
• Issue にラベルが付与済みであること（ラベルに基づいてマイルストーンを判断するため）

手順

1. 現状の把握

マイルストーンの一覧と各マイルストーンの Issue 数を確認する。

gh api repos/{owner}/{repo}/milestones --jq '.[] | select(.state=="open") | {title, open_issues, closed_issues, due_on}'

2. マイルストーン未割り当て Issue の特定

マイルストーンが未割り当ての Issue（Dependency Dashboard を除く）を特定する。

3. セマンティックバージョニングに基づくマイルストーン分類

マイルストーンを作成・割り当てる際は、Issue の種別に応じて パッチ / マイナー のどちらに該当するかを判断する。

パッチバージョン（vX.Y.Z の Z を上げる）: 後方互換性を保つバグ修正やドキュメントの誤り修正など、既存の動作を壊さない修正が対象。

マイナーバージョン（vX.Y.0 の Y を上げる）: 後方互換性を保つ新機能追加、機能強化、リファクタリングなどが対象。

4. ラベルに基づくマイルストーン割り当てルール

1. Type: Bug → 最も直近のパッチマイルストーンに配置。該当するパッチマイルストーンが存在しない場合は新規作成する（例: 現在の最新リリースが v1.1.0 なら v1.1.1 を作成）
2. Type: Document（誤り修正）→ パッチマイルストーンに配置
3. Type: Feature / Type: Enhancement → 機能の規模に応じてマイナーマイルストーンに配置
4. Type: Refactoring → 大きなリリースの前（v1.0.0 など）のマイナーマイルストーンに配置
5. Type: Document（新規追加）→ 関連する機能と同じマイナーマイルストーン
6. Type: Test → 関連する機能と同じマイルストーン
7. Type: Publishing → リリース作業用のマイルストーン

5. マイルストーンの作成

必要に応じて新しいマイルストーンを作成する。

• マイルストーン名はセマンティックバージョニング形式: vX.Y.Z
• パッチマイルストーン（vX.Y.Z の Z を上げる）: Type: Bug や誤り修正の Type: Document が存在し、対応するパッチマイルストーンがない場合は新規作成する
  • 例: 最新リリースが v1.1.0 でバグ Issue がある場合 → v1.1.1 を作成
  • クローズ済みの同名マイルストーンが存在する場合は、次のパッチ番号を使用する（例: v1.1.1 がクローズ済みなら v1.1.2）
• マイナーマイルストーン（vX.Y.0 の Y を上げる）: 機能追加や改善の Issue が既存マイナーマイルストーンに収まらない場合に新規作成する
• 既存のマイルストーン一覧（クローズ済みを含む）を確認し、次のバージョン番号を決定する
• 1つのマイルストーンに Issue が偏りすぎないようにする（目安: 1マイルストーンあたり 5〜8 Issue）
• マイルストーンの作成:
  bashCopy

  gh api repos/{owner}/{repo}/milestones --method POST --field title="vX.Y.Z"
  

6. Issue のマイルストーン割り当て

gh issue edit <issue-number> --milestone "vX.Y.Z"

7. 平準化

• 1つのマイルストーンに 8 Issue 以上ある場合は、一部を別のマイルストーンに移動する
• ラベルの種類と依存関係を考慮して、論理的にまとまりのあるグループにする
• Type: Publishing（リリース作業）は、そのバージョンのマイルストーンに残す

8. 結果の報告

マイルストーンの変更内容を以下の形式で報告する:

割り当て・移動した Issue:

新規作成したマイルストーン: <あれば記載>

棚卸後のマイルストーン状況:

注意事項

• Renovate が管理する Issue（Dependency Dashboard）は操作しない
• マイルストーンの割り当ては、Issue の内容とラベルを総合的に判断して行う