Issue Fields Migration

Issue fields は、org レベルの型付きメタデータ（単一選択、テキスト、数値、日付）であり、ラベルベースの回避策を構造化された検索可能なクロスリポジトリフィールドに置き換えます。すべての組織には、Priority、Effort、Start date、Target date が事前に設定されており、最大 25 個のカスタムフィールドに対応しています。

このスキルは、既存のメタデータを 2 つのソースからイシューフィールドに一括移行します：

• リポラベル: p0、p1、priority/high のようなラベルを構造化されたイシューフィールド値に変換します（例：Priority フィールド）。複数のラベルを同時に移行し、オプションで移行後にラベルを削除できます。
• Project V2 フィールド: GitHub Project のフィールド値（単一選択、テキスト、数値、日付、iteration）を等価な org レベルのイシューフィールドにコピーします。

使用時期

• ユーザーが既存のプロジェクトフィールドと重複する org レベルのイシューフィールドを追加した場合
• ユーザーが古いプロジェクトフィールドを削除する前に、プロジェクトフィールドの値をイシューフィールドにコピーしたい場合
• ユーザーがプロジェクトフィールドのデータをイシューフィールドに「移行」「転送」「コピー」することについて尋ねている場合
• ユーザーがリポラベル（例：p0、p1、p2、p3）をイシューフィールド値（例：Priority フィールド）に変換したい場合
• ユーザーがラベルをイシューフィールドで置き換えるか、イシューフィールドの採用後にラベルをクリーンアップすることについて尋ねている場合

前提条件

• ターゲット org はイシューフィールドが有効である必要があります
• イシューフィールドは org レベルに既に存在している必要があります
• プロジェクトフィールド移行の場合：イシューフィールドをプロジェクトに追加している必要があります
• ラベル移行の場合：ラベルがターゲットリポに存在している必要があります
• ユーザーはリポへの書き込みアクセス権を持っている必要があります（プロジェクトフィールドを移行する場合はプロジェクトも含む）
• gh CLI は適切なスコープで認証されている必要があります

利用可能なツール

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

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

CLI / REST API

操作	コマンド
Org イシューフィールドの一覧表示	gh api /orgs/{org}/issue-fields -H "X-GitHub-Api-Version: 2026-03-10"
イシューフィールド値を読み取り	gh api /repos/{owner}/{repo}/issues/{number}/issue-field-values -H "X-GitHub-Api-Version: 2026-03-10"
イシューフィールド値を書き込み	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
ラベル別のイシューを一覧表示	gh issue list -R {owner}/{repo} --label "{name}" --state all --json number,title,labels --limit 1000
イシューからラベルを削除	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. 「ラベルを移行していますか、それともプロジェクトフィールドを移行していますか？」

   • ラベル: 以下の ラベル移行フロー に進みます。
   • プロジェクトフィールド: 以下の プロジェクトフィールド移行フロー に進みます。

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

   • 「ラベルを含む組織とリポはどれですか？」と尋ねます
   • 「どのラベルを移行したいですか？」と尋ねます（名前を付けるか「最初にラベルを表示してください」と言うことができます）

3. ユーザーが プロジェクトフィールド と答えた場合：

   • 「プロジェクトへのリンクを共有していただくか、org 名とプロジェクト番号を教えていただけますか？」と尋ねます
   • 「どのフィールドを移行したいですか？」と尋ねます

---

ラベル移行フロー

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

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

1. ユーザーに次を尋ねます：org 名 と移行する リポ。
2. 各リポからラベルを取得します：

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

3. Org イシューフィールドを取得します：

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. ユーザーにどのラベルがどのイシューフィールドとオプションにマップするかを尋ねます。これらのパターンをサポートします：

   • 単一ラベルを単一フィールドに: 例えば、ラベル「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

   すべての提案を一度に提示して、ユーザーに確認、修正、またはスキップさせます。

出力例：

github/my-repo のラベル（関連するもののみを表示）:
  p0, p1, p2, p3, bug, enhancement, frontend, backend

Org イシューフィールド（single_select）:
  Priority: Critical, P0, P1, P2, P3
  Type: Bug, Feature, Task
  Team: Frontend, Backend, Design

推奨マッピング:
  ラベル "p0" → Priority "P0"
  ラベル "p1" → Priority "P1"
  ラベル "p2" → Priority "P2"
  ラベル "p3" → Priority "P3"
  ラベル "bug" → Type "Bug"
  ラベル "frontend" → Team "Frontend"
  ラベル "backend" → Team "Backend"
  ラベル "enhancement" → （自動マッチなし。スキップするか手動でマップしてください）

確認、調整、またはマッピングを追加しますか？

フェーズ L2：競合検出

ラベルからオプションへのマッピングを最終化した後、競合をチェックします。競合は、イシューが 同じ イシューフィールドにマップする複数のラベルを持っている場合に発生します（single_select フィールドは 1 つの値のみを保持できるため）。

1. ラベルマッピングをターゲットイシューフィールドでグループ化します。
2. 複数のラベルソースを持つ各フィールドについて、競合の可能性をメモします。
3. ユーザーに競合解決戦略を尋ねます：
   • 最初のマッチ: 見つかった最初のマッチングラベルを使用します（ラベルマッピングリストの順序）
   • スキップ: 競合するラベルを持つイシューをスキップして報告します
   • 手動: 各競合についてユーザーに決定させます

例：

潜在的な競合：ラベル「p0」と「p1」の両方が Priority フィールドにマップされています。
イシューに両方のラベルがある場合、どの値を優先しますか？

オプション:
  1. 最初のマッチ（マッピングに最初に表示される「p0」を使用）
  2. 競合するイシューをスキップ
  3. ケースバイケースで決定します

フェーズ 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：プレビュー / ドライラン

書き込みの前に概要を提示します。

プレビュー例：

ラベル移行プレビュー

ソース: github/my-repo のラベル
ターゲットフィールド: Priority、Type、Team

| カテゴリ | カウント |
|--------|---------|
| 移行するイシュー | 156 |
| 既に設定（スキップ） | 12 |
| 競合するラベル（スキップ） | 3 |
| ラベル付きイシュー合計 | 171 |

ラベルの内訳:
  "p1" → Priority "P1": 42 イシュー
  "p2" → Priority "P2": 67 イシュー
  "p3" → Priority "P3": 38 イシュー
  "bug" → Type "Bug": 9 イシュー

サンプル変更（最初の 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"

移行後、移行されたラベルをイシューから削除しますか？（オプション）

推定時間：約 24 秒（156 API 呼び出し、各 0.15 秒）

続行しますか？

フェーズ L5：実行

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

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 で指数バックオフ（1s、2s、4s、最大 30s）。
4. 進捗: 25 アイテムごとに報告します（例：「175/156 イシューを移行しました...」）。
5. エラーハンドリング: エラーをログに記録し続けます。ラベル削除の失敗は別々に含めます。
6. 最終概要:

ラベル移行完了

| 結果 | カウント |
|------|---------|
| フィールドセット | 153 |
| ラベル削除 | 153 |
| スキップ | 15 |
| 失敗（フィールド書き込み） | 2 |
| 失敗（ラベル削除） | 1 |

失敗したアイテム:
  github/my-repo#501: 403 Forbidden（権限不足）
  github/my-repo#88:  422 Validation failed（フィールドがリポで使用不可）
  github/my-repo#120: ラベル削除失敗（404、ラベルは既に削除済み）

---

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

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

以下の 6 つのフェーズを順番に実行します。常に実行前にプレビューします。

フェーズ P1：入力と検出

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

# MCP ツールを使用
mcp__github__projects_list(owner: "{org}", project_number: {n}, method: "list_project_fields")

3. Org イシューフィールドを取得します：

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

4. プロキシフィールドをフィルタリングします: イシューフィールドがプロジェクトで有効になった後、一部のプロジェクトフィールドは単一選択タイプの options: [] が空の「プロキシ」エントリとして表示されます。これらは実際のイシューフィールドをミラーします。実際のオプション値を持つプロジェクトフィールドに対してのみマッチします。

5. 互換性のある型で名前（大文字小文字区別なし）でフィールドを自動マッチします：

プロジェクトフィールド型	イシューフィールド型	互換性
TEXT	text	はい、直接コピー
SINGLE_SELECT	single_select	はい、オプションマッピング必須
NUMBER	number	はい、直接コピー
DATE	date	はい、直接コピー
ITERATION	（なし）	いいえ、同等物なし；スキップ

6. 提案されたフィールドマッピングをテーブルとして提示します。ユーザーに確認、調整、またはスキップさせます。

出力例：

3 つの可能なフィールドマッピングが見つかりました：

| # | プロジェクトフィールド | 型 | イシューフィールド | ステータス |
|---|---------------------|----|--------------------|----------|
| 1 | Priority (renamed) | SINGLE_SELECT | Priority | 自動マッチ |
| 2 | Due Date | DATE | Due Date | 自動マッチ |
| 3 | Sprint | ITERATION | （同等物なし） | スキップ |

フィールド 1 と 2 で続行しますか？手動マッピングを追加することもできます。

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

マッチされた単一選択ペアごと：

1. プロジェクトフィールドとイシューフィールド間のオプション名を比較します（大文字小文字区別なし）。
2. 同一の名前を持つオプションを自動マッチさせます。
3. マッピングされていないプロジェクトフィールドオプションについて、すべての マッピングされていないオプションを 1 つの概要で提示し、ユーザーにすべてのマッピングを一度に提供するよう尋ねます。1 つずつプロンプトを出さないでください。すべてを 1 つの交換にバッチしてください。
4. 最終的なオプションマッピングテーブルを確認用に表示します。

出力例：

「Release - Target」のオプションマッピング：

自動マッチ（大文字小文字区別なし）:
  "GA" → "GA"
  "Private Preview" → "Private Preview"
  "Public Preview" → "Public Preview"

マッピングされていないプロジェクトオプション（入力が必要）:
  1. "Internal Only" → どのイシューフィールドオプション？（またはスキップ）
  2. "Retired" → どのイシューフィールドオプション？（またはスキップ）
  3. "Beta" → どのイシューフィールドオプション？（またはスキップ）
  4. "Deprecated" → どのイシューフィールドオプション？（またはスキップ）

まだマッピングされていない利用可能なイシューフィールドオプション："Internal"、"Sunset"、"Beta Testing"、"End of Life"

上記の 4 つのオプションすべてのマッピングを指定してください（例：「1→Internal, 2→Sunset, 3→Beta Testing, 4→skip」）。

フェーズ P3：プリフライトチェック

アイテムをスキャンする前に、タッチされる可能性のある各リポジトリへの書き込みアクセスを確認します：

1. プロジェクトアイテム（最初のページ）から、一意の {owner}/{repo} 値セットを収集します。
2. 各一意のリポについて、認証されたユーザーが Issues 書き込み権限を持っているかを確認します：

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 ツール（ページネーションを内部で処理）を使用するか、明示的なカーソルベースのページネーションを使用します：

# 推奨：MCP ツール（ページネーションを自動的に処理）
mcp__github__projects_list(owner: "{org}", project_number: {n}, method: "list_project_items")

# 大規模プロジェクトのフォールバック：手動カーソルベースのページネーション
# 1 ページあたり 100 アイテムを取得し、毎回カーソルを進めます。
# 次のページをフェッチする前に各ページを処理してメモリ問題を避けます。
# 進捗を保存（ページ番号または最後のカーソル）して、中断時に再開できます。

2. 各アイテムについて：
   • ドラフトアイテムの場合はスキップします（実際のイシューではない）。
   • ソースプロジェクトフィールド値を抽出します。
   • ソース値が空の場合はスキップします。
   • ターゲットイシューフィールドに値が既に存在するかを確認します：

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

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

3. 各アイテムを以下のいずれかに分類します：
   • 移行: ソース値がある、ターゲット値がない
   • スキップ（既に設定）: ターゲットイシューフィールドが既に値を持っている
   • スキップ（ソースなし）: このアイテムのプロジェクトフィールドが空
   • スキップ（ドラフト）: アイテムはドラフト、実際のイシューではない
   • スキップ（マッピングされていないオプション）: 単一選択値がマッピングされていない

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

書き込みの前に概要を提示します。

ユーザーがドライランをリクエストした場合: 完全な詳細レポート（すべてのイシュー、現在の値、提案される新しい値、スキップ理由）を表示して停止します。実行しないでください。

それ以外（プレビューモード）: 概要カウントと変更のサンプルを表示し、確認を求めます。

プレビュー例：

プロジェクト #42 の移行プレビュー

移行するフィールド: Priority、Due Date

| カテゴリ | カウント |
|---------|---------|
| 移行するアイテム | 847 |
| 既に設定（スキップ） | 23 |
| ソース値なし（スキップ） | 130 |
| ドラフトアイテム（スキップ） | 12 |
| プロジェクトアイテム合計 | 1,012 |

サンプル変更（最初の 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"

推定時間：約 127 秒（847 API 呼び出し、各 0.15 秒）

847 個のイシューを 3 つのリポにわたって更新して移行を続行しますか？

フェーズ 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. 最終概要:

移行完了

| 結果 | カウント |
|------|---------|
| 成功 | 842 |
| スキップ | 165 |
| 失敗 | 5 |

失敗したアイテム:
  github/repo-a#501: 403 Forbidden（権限不足）
  github/repo-b#88:  422 Validation failed（フィールドがリポで使用不可）
  ...

重要な注記

• 書き込みエンドポイントの注意点: イシューフィールド値を書き込むための REST API は repository_id（整数）を使用します。owner/repo ではありません。常に最初に 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 が必要です。
• クロスリポアイテム: プロジェクトは複数のリポからのイシューを含むことができます。リポあたりのリポ ID をキャッシュして、冗長な検索を避けます。
• 既存の値を保持: 既に設定されているイシューフィールド値を上書きしないでください。これらのアイテムをスキップします。
• Iteration フィールド: イシューフィールドの同等物がありません。常にユーザーに警告してスキップします。
• ドラフトアイテム: 実際のイシューにリンクされていないプロジェクトアイテムはイシューフィールド値を持つことができません。メモ付きでスキップします。
• ラベルはリポスコープ: プロジェクトフィールドとは異なり、ラベルはリポごとに存在します。同じラベル名が複数のリポに存在する可能性があります。移行は各リポに別々に適用されます。
• ラベル競合: イシューは同じ単一選択フィールドにマップする複数のラベルを持つことができます。実行前に常にこれらを検出して解決します。
• ラベル削除はオプション: 移行後、ユーザーはバックアップとしてラベルを保持するか削除するかを選択します。削除前に常にユーザーに尋ねます。
• ラベル名を URL エンコード: スペースまたは特殊文字を含むラベルは、REST API パスで使用する場合に URL エンコードされる必要があります（例：good%20first%20issue）。
• スケール用のスクリプト生成: 100 以上のイシューの移行の場合、エージェント経由で 1 つずつ API 呼び出しを実行する代わりに、スタンドアロンシェルスクリプトを生成します。これはより高速で再開可能で、エージェントタイムアウト問題を回避します。
• べき等な移行: 移行の再実行は安全です。ターゲットフィールド値が既に設定されているイシューはスキップされます。これは、重複を発生させることなく部分的な移行を安全に再開できることを意味します。
• --limit 1000 切り詰め: gh issue list --limit 1000 は 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 値を新しい org Priority イシューフィールドに移行する必要があります」

アクション: フェーズ P1-P6 に従います。フィールドを検出し、オプションをマップし、権限をチェックし、アイテムをスキャンし、プレビューし、実行します。

例 2：ドライランのみ

ユーザー: 「プロジェクト #42 からフィールドを移行した場合の結果を表示してください、ただし実際には実行しないでください」

アクション: フェーズ P1-P5 のみに従います。完全なドライランレポートをすべてのアイテムで提示します。実行しないでください。

例 3：複数フィールド

ユーザー: 「プロジェクト #15 から Priority と Due Date をイシューフィールドに移行します」

アクション: 同じワークフロー、ただし両方のフィールドを単一パスで処理します。データスキャン中に、アイテムごとにマッピングされたすべてのフィールドの値を収集します。すべてのフィールド値をイシューごとの 1 つの API 呼び出しで書き込みます。

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

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

アクション: ラベル移行フローにルーティングします。org/リポを尋ねます、ラベルを一覧表示します、マッピングを確認します：ラベル「bug」→ Type フィールド「Bug」オプション。そのラベルを持つイシューをスキャンし、プレビューし、実行します。移行後にラベルを削除するかを尋ねます。

例 5：複数ラベルから 1 つのフィールド（バルク）

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

アクション: ラベル移行フローにルーティングします。すべての 4 つのラベルを Priority フィールドオプションにマップします（p0→P0、p1→P1、p2→P2、p3→P3）。複合優先度ラベルのあるイシュー（複数の優先度ラベルを持つイシュー）の競合をチェックします。1 つの概要ですべての変更をプレビューします。1 つのパスで実行します。オプションで移行されたイシューからすべての 4 つのラベルを削除します。

例 6：リポを横断するラベル移行とラベル削除

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

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