# Balance Milestones

> マイルストーン未割り当ての Issue にマイルストーンを紐づけ、1マイルストーンあたりの Issue 数を平準化する。マイルストーンの整理・調整・割り当てが必要なときに使う。「マイルストーン整理して」「Issue にマイルストーンを割り当てて」のようなリクエストで使う。

- Skill: `majiayu000/balance-milestones` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/balance-milestones`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/balance-milestones/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/balance-milestones

---


# Balance Milestones Skill

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

## 前提条件

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

## 手順

### 1. 現状の把握

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

```bash
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 を上げる）:**
後方互換性を保つバグ修正やドキュメントの誤り修正など、既存の動作を壊さない修正が対象。

| ラベル | パッチに該当するケース |
|--------|----------------------|
| `Type: Bug` | 常にパッチ対象。バグ修正は最も直近のパッチマイルストーンに配置する |
| `Type: Document` | 誤り・不整合の修正（例: バージョン記載の乖離、サンプルコードのバグ）はパッチ対象 |

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

| ラベル | マイナーに該当するケース |
|--------|------------------------|
| `Type: Feature` | 機能の規模に応じて適切なマイナーマイルストーンに配置 |
| `Type: Enhancement` | 機能の規模に応じて適切なマイナーマイルストーンに配置 |
| `Type: Refactoring` | 大きなリリースの前に配置 |
| `Type: Document` | 新機能に伴うドキュメント追加はマイナーマイルストーンに配置 |
| `Type: Test` | 関連する機能と同じマイナーマイルストーン |
| `Type: Publishing` | リリース作業用のマイルストーン |

### 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）
- マイルストーンの作成:
  ```bash
  gh api repos/{owner}/{repo}/milestones --method POST --field title="vX.Y.Z"
  ```

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

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

### 7. 平準化

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

### 8. 結果の報告

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

**割り当て・移動した Issue:**

| # | タイトル | 変更前 | 変更後 |
|---|---------|--------|--------|
| #XX | <タイトル> | <旧マイルストーン or なし> | <新マイルストーン> |

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

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

| マイルストーン | Open | Closed | 合計 |
|--------------|------|--------|------|
| vX.Y.Z | N | N | N |

## 注意事項

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