issue-fields-migration

Issue Fields の移行

Issue fields は、ラベルを使った回避策に代わる、組織レベルの型付きメタデータ（単一選択、テキスト、数値、日付）です。構造化され、検索可能で、複数のリポジトリで共通して使えます。すべての組織には、Priority、Effort、Start date、Target date があらかじめ設定されており、最大 25 個のカスタムフィールドをサポートします。

このスキルでは、次の 2 つのソースから既存のメタデータを Issue fields に一括移行します。

• リポジトリのラベル：p0、p1、priority/high などのラベルを、構造化された Issue field の値（例：Priority フィールド）に変換します。複数のラベルをまとめて移行でき、移行後にラベルを削除することもできます。
• Project V2 のフィールド：GitHub Project から同等の組織レベルの Issue fields に、フィールドの値（単一選択、テキスト、数値、日付、イテレーション）をコピーします。

使用するタイミング

• ユーザーが、既存の Project フィールドと重複する組織レベルの Issue fields を追加した場合
• 古い Project フィールドを削除する前に、その値を Issue fields にコピーしたい場合
• ユーザーが Project フィールドのデータを Issue fields に「移行」「転送」「コピー」する方法について尋ねた場合
• リポジトリのラベル（例：p0、p1、p2、p3）を Issue field の値（例：Priority フィールド）に変換したい場合
• Issue fields の導入後に、ラベルを Issue fields に置き換えたり、ラベルを整理したりしたい場合

前提条件

• 対象の組織で Issue fields が有効になっている必要があります
• Issue fields が組織レベルですでに作成されている必要があります
• Project フィールドを移行する場合：Issue fields を Project に追加しておく必要があります
• ラベルを移行する場合：対象のリポジトリにラベルが存在する必要があります
• ユーザーにリポジトリへの書き込みアクセス権が必要です（Project フィールドを移行する場合は、Project へのアクセス権も必要です）
• gh CLI が適切なスコープで認証されている必要があります

利用可能なツール

MCP ツール（読み取り操作）

ツール	目的
mcp__github__projects_list	Project のフィールドを一覧表示（list_project_fields）、値を含む Project のアイテムを一覧表示（list_project_items）
mcp__github__projects_get	特定の Project フィールドまたはアイテムの詳細を取得

CLI / REST API

操作	コマンド
組織の Issue fields を一覧表示	gh api /orgs/{org}/issue-fields -H "X-GitHub-Api-Version: 2026-03-10"
Issue field の値を読み取る	gh api /repos/{owner}/{repo}/issues/{number}/issue-field-values -H "X-GitHub-Api-Version: 2026-03-10"
Issue field の値を書き込む	gh api /repositories/{repo_id}/issues/{number}/issue-field-values -X POST -H "X-GitHub-Api-Version: 2026-03-10" --input -
リポジトリ ID を取得	gh api /repos/{owner}/{repo} --jq .id
リポジトリのラベルを一覧表示	gh label list -R {owner}/{repo} --limit 1000 --json name,color,description
ラベルで Issue を一覧表示	gh issue list -R {owner}/{repo} --label "{name}" --state all --json number,title,labels --limit 1000
Issue からラベルを削除	gh api /repos/{owner}/{repo}/issues/{number}/labels/{label_name} -X DELETE

API の詳細については、references/issue-fields-api.md、references/projects-api.md、references/labels-api.md を参照してください。

ワークフロー

ステップ 0：移行元

何を移行するのか、ユーザーに尋ねます。

1. 「ラベルと Project フィールドのどちらを移行しますか？」

   • ラベル：以下のラベル移行フローに進みます。
   • Project フィールド：以下のProject フィールド移行フローに進みます。

2. ユーザーがラベルと答えた場合：

   • 質問：「ラベルが含まれる組織とリポジトリを教えてください。」
   • 質問：「移行するラベルを教えてください。」（ラベル名を指定するか、「まずラベルを見せて」と答えることができます）

3. ユーザーがProject フィールドと答えた場合：

   • 質問：「Project のリンクを共有するか、組織名と Project 番号を教えてください。」
   • 質問：「移行するフィールドを教えてください。」

---

ラベル移行フロー

ユーザーがリポジトリのラベルをイシューのフィールド値に変換したい場合は、このフローを使用します。ラベルをマッピングできるのは single_select イシューのフィールドのみです（各ラベル名は1つのオプション値に対応します）。

フェーズ L1：入力とラベルの検出

1. ユーザーに、移行する 組織名 と リポジトリ を尋ねます。
2. 各リポジトリからラベルを取得します。

gh label list -R {owner}/{repo} --limit 1000 --json name,color,description

3. 組織のイシューのフィールドを取得します。

gh api /orgs/{org}/issue-fields \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  --jq '.[] | {id, name, content_type, options: [.options[]?.name]}'

4. フィルタリング（ラベルが多いリポジトリの場合）：リポジトリに50個以上のラベルがある場合は、共通の接頭辞（例：priority-*、team-*、type-*）または色でグループ化します。マッピングを始める前に、「priority に一致するラベルを表示」や「青いラベルを表示」のようにユーザーが絞り込めるようにします。100個以上のラベルを一度にすべて表示してはいけません。

5. どのラベルをどのイシューのフィールドとオプションに対応させるか、ユーザーに尋ねます。次のパターンに対応します。

   • 1つのラベルを1つのフィールドに対応：例：ラベル「bug」→ Type フィールドの「Bug」オプション
   • 複数のラベルを1つのフィールドに対応（一括）：例：ラベル p0、p1、p2、p3 → 対応するオプションを持つ Priority フィールド
   • 複数のラベルを複数のフィールドに対応：例：p1 → Priority、frontend → Team。それぞれ別のマッピンググループとして処理します。

6. マッピングを自動提案：各ラベルについて、次のパターンを順に使用して、イシューのフィールドのオプションとの一致を試みます。

   • 完全一致（大文字と小文字を区別しない）：ラベル Bug → オプション Bug
   • 接頭辞と数値（{prefix}-{n} → {P}{n}）：ラベル priority-1 → オプション P1
   • 区切り文字を除去（ハイフン、アンダースコア、スペース）：ラベル good_first_issue → オプション Good First Issue
   • 部分文字列の包含：ラベル type: bug → オプション Bug

   すべての候補を一度に提示し、ユーザーが確認、修正、またはスキップできるようにします。

出力例：

Labels in github/my-repo (showing relevant ones):
  p0, p1, p2, p3, bug, enhancement, frontend, backend

Org issue fields (single_select):
  Priority: Critical, P0, P1, P2, P3
  Type: Bug, Feature, Task
  Team: Frontend, Backend, Design

Suggested mappings:
  Label "p0" → Priority "P0"
  Label "p1" → Priority "P1"
  Label "p2" → Priority "P2"
  Label "p3" → Priority "P3"
  Label "bug" → Type "Bug"
  Label "frontend" → Team "Frontend"
  Label "backend" → Team "Backend"
  Label "enhancement" → (no auto-match; skip or map manually)

Confirm, adjust, or add more mappings?

フェーズ L2：競合の検出

ラベルとオプションのマッピングを確定したら、競合を確認します。イシューに同じイシューのフィールドへ対応する複数のラベルがある場合、競合が発生します（single_select フィールドに設定できる値は1つだけです）。

1. 対象となるイシューのフィールドごとに、ラベルのマッピングをグループ化します。
2. 複数のラベルが対応するフィールドについて、競合の可能性を記録します。
3. 競合の解決方法をユーザーに尋ねます。
   • 最初の一致：最初に見つかった一致ラベルを使用します（ラベルのマッピングリストの順序に従います）。
   • スキップ：ラベルが競合するイシューをスキップし、その内容を報告します。
   • 手動：競合ごとにユーザーに判断を求めます。

例：

Potential conflict: labels "p0" and "p1" both map to the Priority field.
If an issue has both labels, which value should win?

Options:
  1. First match (use "p0" since it appears first in the mapping)
  2. Skip conflicting issues
  3. I'll decide case by case

フェーズ L3：事前確認とデータのスキャン

1. 各リポジトリについて書き込み権限を確認し、repository_id をキャッシュします。

gh api /repos/{owner}/{repo} --jq '{full_name, id, permissions: .permissions}'

2. マッピング内の各ラベルについて、一致するイシューを取得します。

gh issue list -R {owner}/{repo} --label "{label_name}" --state all \
  --json number,title,labels,type --limit 1000

警告：--limit 1000 を指定すると、結果は通知なく切り詰められます。ラベルに一致するイシューが1000件を超える可能性がある場合は、手動でページネーションするか、先に合計件数を確認してください（例：gh issue list --label "X" --state all --json number | jq length）。

PR のフィルタリング：gh issue list はイシューと PR の両方を返します。ユーザーがイシューのみの移行を希望する場合は、--json の出力に type を含め、type == "Issue" でフィルタリングします。

3. 選択したすべてのラベルに一致するイシューが0件の場合は、処理を中止してユーザーに伝えます。別のラベルを試す、スペルを確認する、または別のリポジトリを試すよう提案します。対象が空のまま移行を進めてはいけません。

4. 複数のリポジトリを移行する場合は、指定されたすべてのリポジトリで同じ処理を繰り返します。

5. 見つかった各イシューについて、次の処理を行います。

   • 対象となるイシューのフィールドにすでに値があるか確認します（設定済みの場合はスキップ）。
   • 複数ラベルの競合を検出します（同じフィールドに対応するラベルが2つある場合）。
   • フェーズ L2 で選択した競合解決方法を適用します。
   • 移行、スキップ（設定済み）、スキップ（競合）、**スキップ（一致するラベルなし）**に分類します。

フェーズ L4：プレビュー／ドライラン

書き込みを行う前に、概要を提示します。

プレビュー例：

Label Migration Preview

Source: labels in github/my-repo
Target fields: Priority, Type, Team

| Category                | Count |
|-------------------------|-------|
| Issues to migrate       |   156 |
| Already set (skip)      |    12 |
| Conflicting labels (skip)|    3 |
| Total issues with labels|   171 |

Label breakdown:
  "p1" → Priority "P1": 42 issues
  "p2" → Priority "P2": 67 issues
  "p3" → Priority "P3": 38 issues
  "bug" → Type "Bug": 9 issues

Sample changes (first 5):
  github/my-repo#101: Priority → "P1"
  github/my-repo#203: Priority → "P2", Type → "Bug"
  github/my-repo#44:  Priority → "P3"
  github/my-repo#310: Priority → "P1"
  github/my-repo#7:   Type → "Bug"

After migration, do you also want to remove the migrated labels from issues? (optional)

Estimated time: ~24s (156 API calls at 0.15s each)

Proceed?

フェーズ L5：実行

1. 移行する各 Issue について、Issue フィールドの値を書き込みます（プロジェクトフィールドの移行と同じエンドポイントです）。

echo '{"issue_field_values": [{"field_id": FIELD_ID, "value": "OPTION_NAME"}]}' | \
  gh api /repositories/{repo_id}/issues/{number}/issue-field-values \
    -X POST \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    --input -

FIELD_ID を整数のフィールド ID（例：1）に、OPTION_NAME をオプション名の文字列に置き換えます。

2. ユーザーがラベルの削除を選択した場合は、フィールドへの書き込みが成功した後に、移行した各ラベルを削除します。

gh api /repos/{owner}/{repo}/issues/{number}/labels/{label_name} -X DELETE

スペースや特殊文字を含むラベル名は URL エンコードしてください。

3. 実行間隔：呼び出しの間に 100ms の遅延を入れます。HTTP 429 が発生した場合は指数バックオフを行います（1 秒、2 秒、4 秒、最大 30 秒）。
4. 進行状況：25 件ごとに報告します（例：「75/156 件の Issue を移行しました...」）。
5. エラー処理：失敗を記録して処理を続行します。ラベルの削除に失敗した場合は、別に記録します。
6. 最終サマリー：

Label Migration Complete

| Result                | Count |
|-----------------------|-------|
| Fields set            |   153 |
| Labels removed        |   153 |
| Skipped               |    15 |
| Failed (field write)  |     2 |
| Failed (label remove) |     1 |

Failed items:
  github/my-repo#501: 403 Forbidden (insufficient permissions)
  github/my-repo#88:  422 Validation failed (field not available on repo)
  github/my-repo#120: label removal failed (404, label already removed)

---

プロジェクトフィールド移行のフロー

ユーザーが GitHub Project V2 のフィールドから、対応する組織レベルの Issue フィールドに値をコピーしたい場合は、このフローを使用します。

以下の 6 つのフェーズを順番に実行します。実行前に必ずプレビューしてください。

フェーズ P1：入力と検出

1. ユーザーに組織名とプロジェクト番号（またはプロジェクト URL）を尋ねます。
2. プロジェクトフィールドを取得します。

# Use MCP tool
mcp__github__projects_list(owner: "{org}", project_number: {n}, method: "list_project_fields")

3. 組織の Issue フィールドを取得します。

gh api /orgs/{org}/issue-fields \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  --jq '.[] | {id, name, content_type, options: [.options[]?.name]}'

4. プロキシフィールドを除外：プロジェクトで Issue フィールドを有効にすると、一部のプロジェクトフィールドが、単一選択タイプでは options: [] が空の「プロキシ」エントリとして表示されます。これらは実際の Issue フィールドを反映しているため、無視してください。実際のオプション値があるプロジェクトフィールドのみを照合してください。

5. 互換性のあるタイプ同士で、フィールド名（大文字と小文字を区別しない）に基づいて自動照合します。

プロジェクトフィールドのタイプ	Issue フィールドのタイプ	互換性あり？
TEXT	text	はい、直接コピー
SINGLE_SELECT	single_select	はい、オプションのマッピングが必要
NUMBER	number	はい、直接コピー
DATE	date	はい、直接コピー
ITERATION	(なし)	対応するフィールドなし。警告してスキップ

6. 提案するフィールドのマッピングを表で提示します。ユーザーが確認、調整、またはスキップできるようにします。

出力例：

Found 3 potential field mappings:

| # | Project Field      | Type          | Issue Field        | Status     |
|---|-------------------|---------------|--------------------|------------|
| 1 | Priority (renamed) | SINGLE_SELECT | Priority           | Auto-match |
| 2 | Due Date           | DATE          | Due Date           | Auto-match |
| 3 | Sprint             | ITERATION     | (no equivalent)    | Skipped    |

Proceed with fields 1 and 2? You can also add manual mappings.

フェーズ P2：オプションのマッピング（単一選択フィールドのみ）

照合された単一選択フィールドのペアごとに、次の手順を実行します。

1. プロジェクトフィールドと Issue フィールドのオプション名を比較します（大文字と小文字を区別しません）。
2. 名前が完全に一致するオプションを自動照合します。
3. マッピングされていないプロジェクトフィールドのオプションがある場合は、マッピングされていないオプションをすべてまとめて提示し、それらすべてのマッピングを一度にユーザーに尋ねます。一つずつ尋ねず、一回のやり取りにまとめてください。
4. 最終的なオプションのマッピング表を提示し、確認を求めます。

出力例：

Option mapping for "Release - Target":

Auto-matched (case-insensitive):
  "GA" → "GA"
  "Private Preview" → "Private Preview"
  "Public Preview" → "Public Preview"

Unmapped project options (need your input):
  1. "Internal Only" → which issue field option? (or skip)
  2. "Retired" → which issue field option? (or skip)
  3. "Beta" → which issue field option? (or skip)
  4. "Deprecated" → which issue field option? (or skip)

Available issue field options not yet mapped: "Internal", "Sunset", "Beta Testing", "End of Life"

Please provide mappings for all 4 options above (e.g., "1→Internal, 2→Sunset, 3→Beta Testing, 4→skip").

フェーズ P3：事前確認

項目をスキャンする前に、変更する可能性のある各リポジトリへの書き込み権限を確認します。

1. プロジェクト項目（最初のページ）から、重複しない {owner}/{repo} の値を収集します。
2. リポジトリごとに、認証済みユーザーが Issue の書き込み権限を持っていることを確認します。

gh api /repos/{owner}/{repo} --jq '{full_name, permissions: .permissions}'

3. いずれかのリポジトリで push: false または triage: false が示された場合は、続行前にユーザーに警告します。これらのリポジトリ内の項目は、書き込み時に失敗します。
4. 各リポジトリの repository_id（整数）をこの時点でキャッシュします。フェーズ 6 で必要になります。

gh api /repos/{owner}/{repo} --jq .id

フェーズ P4：データのスキャン

1. MCP を使用して、プロジェクトの全アイテムを取得します。重要：アイテム数が約 200 件を超えるプロジェクトでは、gh api graphql --paginate は信頼性に欠けます（JSON レスポンスを適切な区切りなしで連結し、タイムアウトすることがあります）。ページネーションを内部で処理する MCP ツールを使用するか、カーソルベースのページネーションを明示的に使用してください。

# Preferred: use MCP tool (handles pagination automatically)
mcp__github__projects_list(owner: "{org}", project_number: {n}, method: "list_project_items")

# Fallback for large projects: manual cursor-based pagination
# Fetch 100 items per page, advancing the cursor each time.
# Process each page before fetching the next to avoid memory issues.
# Save progress (page number or last cursor) so you can resume if interrupted.

2. 各アイテムについて：
   • 下書きアイテム（実際のイシューではない場合）はスキップします。
   • 元のプロジェクトフィールドの値を抽出します。
   • 元の値が空の場合はスキップします。
   • イシューに対象のイシューフィールドの値がすでに設定されているか確認します。

gh api /repos/{owner}/{repo}/issues/{number}/issue-field-values \
  -H "X-GitHub-Api-Version: 2026-03-10"

• イシューフィールドにすでに値が設定されている場合は、スキップします（既存データを保持します）。

3. 各アイテムを次のいずれかに分類します：
   • 移行：元の値があり、対象の値は未設定
   • スキップ（設定済み）：対象のイシューフィールドにすでに値が設定されている
   • スキップ（元の値なし）：このアイテムのプロジェクトフィールドが空
   • スキップ（下書き）：アイテムが下書きで、実際のイシューではない
   • スキップ（マッピングされていない選択肢）：単一選択の値がマッピングされていない

フェーズ P5：プレビュー／ドライラン

書き込みを行う前に、概要を提示します。

ユーザーがドライランをリクエストした場合：詳細なレポート（各イシュー、現在の値、変更後の値、スキップ理由）をすべて表示して終了します。実行しないでください。

それ以外（プレビューモード）：件数の概要と変更例を表示してから、確認を求めます。

プレビューの例：

Migration Preview for Project #42

Fields to migrate: Priority, Due Date

| Category               | Count |
|------------------------|-------|
| Items to migrate       |   847 |
| Already set (skip)     |    23 |
| No source value (skip) |   130 |
| Draft items (skip)     |    12 |
| Total project items    | 1,012 |

Sample changes (first 5):
  github/repo-a#101: Priority → "High"
  github/repo-a#203: Priority → "Medium", Due Date → "2025-03-15"
  github/repo-b#44:  Priority → "Low"
  github/repo-a#310: Due Date → "2025-04-01"
  github/repo-c#7:   Priority → "Critical"

Estimated time: ~127s (847 API calls at 0.15s each)

Proceed with migration? This will update 847 issues across 3 repositories.

フェーズ P6：実行

1. フェーズ 3 でキャッシュした repository_id の値を使用します。

2. 移行対象の各アイテムについて、イシューフィールドの値を書き込みます。

echo '{"issue_field_values": [{"field_id": FIELD_ID, "value": "VALUE"}]}' | \
  gh api /repositories/{repo_id}/issues/{number}/issue-field-values \
    -X POST \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    --input -

FIELD_ID を整数のフィールド ID（例：1）に、VALUE を値の文字列に置き換えます。

3. 実行間隔：API 呼び出しの間に 100ms の遅延を入れます。HTTP 429 レスポンスを受け取った場合は、指数バックオフ（1s、2s、4s、最大 30s）を使用します。
4. 進捗状況：25 件ごとに状況を報告します（例：「75/847 件のアイテムを移行しました…」）。
5. エラー処理：失敗を記録しつつ、残りのアイテムの処理を続けます。
6. 最終概要：

Migration Complete

| Result  | Count |
|---------|-------|
| Success |   842 |
| Skipped |   165 |
| Failed  |     5 |

Failed items:
  github/repo-a#501: 403 Forbidden (insufficient permissions)
  github/repo-b#88:  422 Validation failed (field not available on repo)
  ...

重要な注意事項

• 書き込みエンドポイントの注意点：課題のフィールド値を書き込む REST API では、owner/repo ではなく repository_id（整数）を使用します。まず gh api /repos/{owner}/{repo} --jq .id でリポジトリ ID を必ず取得してください。
• 単一選択の値：REST API では、オプション ID ではなくオプションの名前を文字列として受け付けます。そのため、プロジェクトフィールドとラベルのどちらも簡単にマッピングできます。
• 値の読み戻し：API レスポンスから課題のフィールド値を読み取るときは、人が読める値として .single_select_option.name を使用してください。.value プロパティが返すのは表示名ではなく、内部オプション ID（1201 のような整数）です。
• API バージョンヘッダー：すべての課題フィールドエンドポイントで X-GitHub-Api-Version: 2026-03-10 が必要です。
• 複数リポジトリにまたがるアイテム：1 つのプロジェクトに、複数のリポジトリの課題を含めることができます。重複した検索を避けるため、リポジトリごとにリポジトリ ID をキャッシュしてください。
• 既存の値を保持する：すでに設定されている課題フィールド値を上書きしないでください。該当するアイテムはスキップしてください。
• イテレーションフィールド：課題フィールドに相当するものはありません。必ずユーザーに警告し、スキップしてください。
• 下書きアイテム：実際の課題にリンクされていないプロジェクトアイテムには、課題フィールド値を設定できません。注記を添えてスキップしてください。
• ラベルはリポジトリごとに設定される：プロジェクトフィールドとは異なり、ラベルはリポジトリごとに存在します。同じラベル名が複数のリポジトリに存在する場合もあります。移行はそれぞれのリポジトリで個別に適用されます。
• ラベルの競合：1 つの課題に、同じ単一選択フィールドにマッピングされる複数のラベルが付いていることがあります。実行前に必ずこれらを検出し、解決してください。
• ラベルの削除は任意：移行後、ユーザーはバックアップとしてラベルを残すか、削除するかを選択できます。削除する前に必ず確認してください。
• ラベル名の URL エンコード：スペースや特殊文字を含むラベルを REST API のパスで使用する場合は、URL エンコードしてください（例：good%20first%20issue）。
• 大規模移行でのスクリプト生成：100 件以上の課題を移行する場合は、エージェント経由で API 呼び出しを 1 件ずつ実行するのではなく、単独で実行できるシェルスクリプトを生成してください。処理が速く、中断後に再開でき、エージェントのタイムアウトも回避できます。
• べき等な移行：移行は安全に再実行できます。対象フィールド値がすでに設定されている課題はスキップされます。そのため、作業を重複させることなく、中断した移行を安全に再開できます。
• --limit 1000 による切り捨て：gh issue list --limit 1000 は、1000 件でサイレントに処理を停止します。該当するラベルの課題がそれ以上ある場合は、--jq とカーソルベースのページネーションを使用するか、日付範囲などで複数の絞り込みクエリを実行してください。
• macOS の bash バージョン：macOS に付属する bash 3.x は、連想配列を扱う declare -A をサポートしていません。生成するスクリプトでは POSIX 互換の構文を使うか、この非互換性について説明して brew install bash を提案してください。
• 課題と PR：gh issue list は課題とプルリクエストの両方を返します。課題のみを移行する場合は、--json の出力に type を含め、type == "Issue" で絞り込んでください。

例

例 1：完全な移行

ユーザー：「プロジェクトの Priority 値を、新しい組織の Priority 課題フィールドに移行する必要があります」

アクション：フェーズ P1～P6 に従います。フィールドを検出し、オプションをマッピングし、権限を確認し、アイテムをスキャンして、プレビューを表示した後、実行します。

例 2：ドライランのみ

ユーザー：「プロジェクト #42 のフィールドを移行するとどうなるか確認したいですが、実際には実行しないでください」

アクション：フェーズ P1～P5 のみを実施します。すべてのアイテムを列挙した完全なドライランレポートを提示します。実行はしません。

例 3：複数のフィールド

ユーザー：「プロジェクト #15 の Priority と Due Date を課題フィールドに移行してください」

アクション：同じワークフローを使いますが、両方のフィールドをまとめて処理します。データのスキャン時に、アイテムごとにマッピング対象のすべてのフィールドの値を収集します。課題ごとに 1 回の API 呼び出しで、すべてのフィールド値を書き込みます。

例 4：単一ラベルからイシューフィールドへの移行

ユーザー：「「bug」ラベルを Type イシューフィールドに移行したいです」

アクション：ラベル移行フローに進みます。組織／リポジトリを尋ね、ラベルを一覧表示し、マッピングを確認します。ラベル「bug」→ Type フィールドの「Bug」オプション。該当ラベルが付いたイシューをスキャンし、プレビューを表示して実行します。移行後にラベルを削除するかどうかを尋ねます。

例 5：複数のラベルを 1 つのフィールドに移行（一括）

ユーザー：「p0、p1、p2、p3 のラベルを Priority イシューフィールドに変換したいです」

アクション：ラベル移行フローに進みます。4 つのラベルすべてを Priority フィールドのオプションにマッピングします（p0→P0、p1→P1、p2→P2、p3→P3）。競合（複数の Priority ラベルが付いたイシュー）がないか確認します。すべての変更を 1 つの概要にまとめてプレビューします。まとめて実行します。必要に応じて、移行したイシューから 4 つのラベルすべてを削除します。

例 6：ラベルの削除を伴うリポジトリ間のラベル移行

ユーザー：「github/issues、github/memex、github/mobile 全体で、「frontend」と「backend」ラベルを Team イシューフィールドに移行し、古いラベルを削除してください」

アクション：ラベル移行フローに進みます。リポジトリとラベルのマッピングを確認します。「frontend」→ Team の「Frontend」、「backend」→ Team の「Backend」。3 つすべてのリポジトリで、これらのラベルが付いたイシューをスキャンします。競合（両方のラベルが付いたイシュー）を検出します。リポジトリ全体のプレビューを表示します。フィールドへの書き込みを実行してから、移行したイシューからラベルを削除します。リポジトリごとの統計を報告します。