Pokemon Team Builder

6体構築のシングル（3体選出）/ダブル（4体選出）対戦構築支援スキル。

パス定義

スキルファイルの位置からリポジトリルートを算出する。CLIツール pkdx を使用する。

SKILL_DIR=（このSKILL.mdが置かれたディレクトリ）
REPO_ROOT=$SKILL_DIR/../../../..  （.claude/skills/team-builder/ → repo root）
PKDX=$REPO_ROOT/bin/pkdx

キャッシュファイル

各Phase完了時に、構築中のデータをJSONファイルとして $REPO_ROOT/box/cache/team_cache_<axis_name>.json に書き出す。

目的

• コンテキスト圧縮後の状態復元
• Phase 8 で cat cache.json | pkdx write teams に直接渡す（JSON→マークダウン変換はCLI側で行う）
• Team State Block テキストの代替

ファイルパス

$REPO_ROOT/box/cache/team_cache_<axis_name>_<timestamp>.json

<timestamp> はスキル開始時（Phase 0）に date +%s で取得した UNIX タイムスタンプ。以降のフェーズでは $CACHE_FILE 変数でパスを参照する。

CACHE_FILE="$REPO_ROOT/box/cache/team_cache_<axis_name>_$(date +%s).json"

axis_name 解決と init-cache のタイミング

<axis_name> は Phase 1 で軸ポケモンが確定するまで決まらない。Phase 0 完了時点ではまだ軸が無いため、次の手順で扱う:

1. Phase 0 完了時: プレースホルダ名で初期化し、battle_format / mechanics / version / regulation を書き込む

   CACHE_TS=$(date +%s)
   CACHE_FILE="$REPO_ROOT/box/cache/team_cache_pending_${CACHE_TS}.json"
   bin/pkdx init-cache team > "$CACHE_FILE"
   # battle_format / mechanics / version / regulation を jq 等でマージ
   

2. Phase 1 軸確定後: ファイルを <axis_name> 入りの正式名にリネームし、$CACHE_FILE を更新

   NEW_FILE="$REPO_ROOT/box/cache/team_cache_<axis_name>_${CACHE_TS}.json"
   mv "$CACHE_FILE" "$NEW_FILE"
   CACHE_FILE="$NEW_FILE"
   

3. Phase 1-Team-Vision 経路: 取り込み完了後の最初のメンバーを軸とみなして同じく rename する。Phase 1-Team-Vision 内に init-cache team の重複指示があるが、Phase 0 で初期化済みなら再実行は不要（rename のみ行う）

キャッシュの初期化

スキーマ定義は src/writer/schema.mbt の team_schema() がSSoT。初期JSONは以下のコマンドで生成する:

bin/pkdx init-cache team > "$CACHE_FILE"

生成されるJSONの特徴:

• nullableフィールド（battle_format, mechanics, version）は null
• 数値フィールド（phase）は 0
• 配列（members, coverage, defense_matrix, matchup_plans）は []、concept は空文字

Phase 0でユーザー選択値（battle_format, mechanics, version, regulation）をマージし、以降のPhaseで members を段階的に追加していく。

更新タイミング

各Phaseの「Team State 出力」の直後にキャッシュファイルを書き出す:

Phase	書き込む内容
0	battle_format + mechanics + version + regulation
1	+ members[0]（軸ポケモン: name/types/base_stats、role は空文字でも可）
2	+ members[0].ability + coverage初期値 + members[0].role（ポケモンメモ） + members[0] 育成データ（nature / stat_points / actual_stats） + damage_calcs
3	+ members[1-2]（攻め補完メンバー） + coverage更新 + 各 role（ポケモンメモ） + 育成データ + damage_calcs
4	+ members[3-4]（受け補完メンバー） + defense_matrix + 各 role（ポケモンメモ） + 育成データ + damage_calcs
5	+ 全メンバーの moves 確定 + members[5]（素早さ枠等） + 各 role（ポケモンメモ） + 育成データ + damage_calcs
6	+ matchup_plans（仮想敵分析結果）
7	+ 全メンバーの item 確定 + 残スロットの role（ポケモンメモ） + 未確定メンバーの育成データ最終確定 + damage_calcs + concept (構築コンセプト)

メモ: role フィールドはスキーマ上は文字列だが、SKILL では役割（物理アタッカー / 受け / サポート 等）に限定せず、採用理由・型名・対面時の注意点などを自由に書けるポケモンメモ欄として扱う（空文字可）。詳細は メンバー確定共通: ポケモンメモ入力 を参照。

育成データ: members[i].nature / members[i].stat_points / members[i].actual_stats の 3 フィールド。pkdx select / pkdx nash graph がこれらを読んで damage 計算の実数値を確定させる。未設定のまま Phase 8 まで進むと select は「攻撃側 SP=32 +性格補正 / 防御側 SP=0 無補正」の固定デフォルトで計算してしまい、実戦値とずれる。詳細は メンバー確定共通: 育成データ入力 を参照。

ダメージ計算: 各メンバー確定後に任意で代表技のダメージ計算を cache.damage_calcs に追記する（pkdx damage --attach-team 経由）。該当記事ページには damage_calcs 章として埋め込まれ、FE の DamageCalcTable で描画される。詳細は メンバー確定共通: ダメージ計算入力 を参照。

Phase 8での扱い

• cat cache.json | pkdx write teams で直接マークダウンに変換
• 保存完了後、またはユーザーが保存をスキップした場合、キャッシュファイルを削除する

---

メンバー確定共通: ポケモンメモ入力

各メンバーの特性・持ち物確定後、または Phase 1-Team-Vision でのスクショ取り込み確認後に呼び出す共通サブフロー。role フィールド（スキーマ上は文字列）へ自由メモを記入する。

用途

• 役割表記（例: 「物理アタッカー」「特殊受け」「リダイレクト要員」）
• 採用理由・型名（例: 「スカーフ最速 S189 抜き」「HBD 振り耐久型」）
• 対面時の注意点（例: 「相手スカーフ警戒、初手まもる安定」）
• ダブルでの並びシナジー要点 など

役割と複数情報の併記も可。空文字 "" 許容（無理に埋めない）。

入力フロー

1. ユーザーへ次のテキストを出力（AskUserQuestion ではなくフリー入力依頼）:

   {ポケモン名} のメモを入力してください（役割・採用理由・対面メモなど自由）。
   不要なら「なし」と返答してください。
   

2. ユーザーの次のメッセージ全文を members[i].role に格納する（改行は半角スペース 1 個に正規化、目安 200 文字以内）

3. 「なし」「skip」「省略」「-」等の場合は "" を格納

4. キャッシュファイルへ書き戻し、Team State Block の対応行のメモ表示を更新

呼び出しタイミング

呼び出し元	タイミング
Phase 2-5 後	軸ポケモンの特性・持ち物確定直後
Phase 3-6 後	攻め補完メンバー（2-3 体）の確定直後
Phase 4-5 後	受け補完メンバー（2 体）の確定直後
Phase 5-5 後	素早さ枠の確定直後
Phase 7-1 後	残未確定スロットの確定直後
Phase 1-Team-Vision 確認後	スクショから 6 体確定後、members[0] → members[5] の順に 1 体ずつ本サブフローを呼び出す

---

メンバー確定共通: 育成データ入力

メンバーの特性・持ち物確定後に呼び出す共通サブフロー。性格・SP（Champions）/ EV（deprecated）・実数値を members[i].nature / members[i].stat_points / members[i].actual_stats に格納する。Standard (= EV/IV) 系の version では追加で members[i].ivs も格納する。

なぜ必要か

pkdx select / pkdx nash graph はこの 3 フィールドを読んで DamageCalcInput.atk_nature / def_nature / atk_stat_override / def_stat_override / def_hp_override を設定する。未設定のメンバーは「攻撃側 SP=32 +性格補正 / 防御側 SP=0 無補正」の engine legacy default で計算されるため、実構築の打点・耐久とずれる。未設定のまま Phase 8 に進むと、Phase 6 のマッチアップ分析や pkdx select の選出最適化が実戦と乖離する。

Standard 形式ではメガ進化後の実数値を再計算するときに個体値 (IV) が必要になる。members[i].ivs を設定しないと select は 31 揃い (完璧個体) を仮定するため、0 攻撃の特殊アタッカーや 0 素早さのトリックルーム要員など、非 31 IV を意図的に使った構築は post-mega 実数値がユーザー意図からずれる。Champions はゲーム仕様上 IV が廃止されているため、ivs を設定しても無視される (Standard 構築のみで有効)。

入力フロー

1. 性格: AskUserQuestion で性格名を選択（ようき / ひかえめ / いじっぱり / ずぶとい など）。判断材料として $SKILL_DIR/references/stat_thresholds.md の "素早さティア" / "耐久ベンチマーク" を提示する。

2. SP/EV: 以下のいずれかで確定:

   • 攻撃型: A or C を 32（max）、S を抜き先に応じて調整し、残りを HP/耐久に振る
   • 耐久型: $PKDX hbd "<name>" --nature "<性格>" --fixed-ev "_,0,_,0,_,<S_sp>" で最適配分を取得し、上位候補を AskUserQuestion で提示
   • スカーフ型: S=32、A or C=32、残りを HP に
   • ユーザー直接指定: "H252 A252 S4 余り" のような自由文字列を SP/EV に解釈

   stat_points は {h, a, b, c, d, s} 形式で格納（Champions は各 ≤ 32 合計 ≤ 66、deprecated は各 4 刻み ≤ 252 合計 ≤ 510）。

   Standard (EV/IV) 系 version 限定: ユーザーが IV を指定したら members[i].ivs = {h, a, b, c, d, s} に格納する。特に指定がなければ {h:31, a:31, b:31, c:31, d:31, s:31} を既定とする。ただし 0 攻撃 (特殊アタッカーの混乱自傷ケア) や 0 素早さ (トリックルーム下位行動) のような非 31 IV 運用が明示されたときは、その値を必ず保存する (select のメガ進化後再計算がこの値を使う)。Champions では IV がゲーム仕様上存在しないので ivs は格納しない（null のまま）。

3. 実数値の算出: SP/EV 確定後、$PKDX stat-calc で実数値を出す:

   $PKDX stat-calc "<ポケモン名>" \
     --ev "H,A,B,C,D,S" \
     --nature "<性格>" \
     --version "<version>" \
     --format json
   

   JSON の stats (または実数値フィールド) を取り出して members[i].actual_stats = {h,a,b,c,d,s} に格納。手計算に頼らず CLI 出力を SSoT とする。

4. キャッシュ書き戻し + Team State Block 更新: members[i] の 3 フィールドを埋めてキャッシュ JSON を再保存し、Team State Block の該当行に「性格: / SP: / 実数値:」を反映する。

Champions Vision 取り込み時の扱い

Phase 1-Team-Vision で vision 抽出 + pkdx stat-reverse 検証済みの SP / 実数値 / 性格は、本サブフローを経由せず直接 members[i] に書き込む（既に値が揃っているため再質問は冗長）。vision 検証で矛盾が出た個体のみ、AskUserQuestion で修正を受け付ける。

呼び出しタイミング

呼び出し元	タイミング
Phase 2-5 後	軸ポケモンの特性・持ち物確定直後（ポケモンメモ入力の後）
Phase 3-6 後	攻め補完メンバー（2-3 体）の確定直後
Phase 4-5 後	受け補完メンバー（2 体）の確定直後
Phase 5-5 後	素早さ枠の確定直後
Phase 7-1 後	残未確定スロットの確定直後

ポケモンメモ入力と本サブフローは連続して呼び出す（メモ → 育成データ → ダメージ計算入力 → 次のメンバーへ）。

---

メンバー確定共通: ダメージ計算入力

各メンバーの育成データ確定直後に呼び出す共通サブフロー。そのメンバーのデータを用いて仮想敵ダメージ計算を実行し、cache の damage_calcs[] に追記する。Phase 8 で pkdx write teams が cache → meta.json serialize するとき、そのまま meta.json の damage_calcs[] として FE に渡り記事に反映される。

入力フロー

1. 実行可否判定: AskUserQuestion:

   #	質問	header	オプション
   1	{ポケモン名} のダメージ計算を入力しますか?	ダメ計	はい(desc: 次メッセージで計算対象を複数行入力), いいえ(desc: スキップ)

   「いいえ」なら即次のメンバーへ。

2. 対象入力: 「はい」の場合、以下のテキストをユーザーへ出力（AskUserQuestion ではなくフリー入力依頼）:

   {ポケモン名} のダメージ計算対象を、以下のいずれかのフォーマットで 1 行 1 エントリで入力してください（複数可）。
   攻め (current member が攻撃): {技名}->{SP振り},{性格補正},{ポケモン名},{天候などの条件}
   受け (current member が防御): {SP振り},{性格補正},{ポケモン名},{技名},{天候などの条件}
   
   不要なら「なし」と返答してください。
   
   例:
     じしん->H32,無補正,ドドゲザン         # カバルドンのじしんで H32無補正のドドゲザンを攻撃
     逆鱗->H1,無補正,カイリュー
     アイアンヘッド->H32B32,補正あり,メガピクシー
     C32,補正あり,メガゲンガー,シャドーボール   # メガゲンガー(C32補正あり)のシャドーボールでカバルドンが受ける
     A32,無補正,ガブリアス,じしん
   

3. フォーマット判定:

   • 行に -> が含まれる → 攻め (current member = attacker, listed pokemon = defender)
   • 行に -> が含まれない → 受け (current member = defender, listed pokemon = attacker)
   • どちらの format でも {SP振り},{性格補正},{ポケモン名} の 3 要素は常に "相手 (= opponent)" のもの。current member の SP/性格/実数値は members[i] から暗黙取得し、入力で渡さない (重複入力で計算が食い違うのを防ぐため)。

4. 各フィールドの解釈ルール:

   • 技名: 攻めなら members[i].moves[].name に含まれること。受けなら pkdx moves "<opponent>" --version champions で習得確認
   • SP振り: {stat letter}{数値} の連結（大文字 H/A/B/C/D/S）。未指定 stat は 0（例: H32 → {h:32,a:0,b:0,c:0,d:0,s:0}、H32B32 → {h:32,a:0,b:32,c:0,d:0,s:0}）。Champions 制約: 各 ≤ 32、合計 ≤ 66
   • 性格補正:
     • 無補正 → opponent の nature を 省略 (CLI default: 攻撃側=攻撃stat特化相当 +10% / 防御側=無補正)
     • 補正あり → 技の category に応じて opponent の nature を決定:
       • 攻め format (opponent = defender): 物理技なら ずぶとい (B↑), 特殊技なら しんちょう (D↑)
       • 受け format (opponent = attacker): 物理技なら いじっぱり (A↑), 特殊技なら ひかえめ (C↑)
   • ポケモン名: pkdx query "<name>" --version champions --format json で存在確認。メガX は DB 上のメガフォーム名に正規化（M-C で X メガ進化形 や メガ<X> の綴り揺れを吸収）

5. ステージング meta.json: pkdx damage --attach-team は .meta.json が box/teams/ 配下に実在している必要があるため、Phase 1-Team-Vision step 6 終了直後 / Phase 7-1 完了直後 に最終出力パスと同じ名前でステージング meta.json を pre-create する:

   STAGING="box/teams/<axis>-build-<YYYY-MM-DD>.meta.json"
   [ ! -f "$STAGING" ] && echo '{"damage_calcs":[]}' > "$STAGING"
   

   既存ファイルがあれば上書きせずそのまま使う（冪等）。

6. 計算実行 + attach: 重要 — pkdx damage には --atk-ev / --def-ev オプションは存在しない。実数値は --atk-stat / --def-stat / --def-hp で直接渡す（pre-rank の生stat値）。実数値は pkdx stat-calc の出力を SSoT とし、手計算しない。

   rev2 フラグ (威力可変 / 壁 / 連続技 / 状態): 以下は該当する技 / 状況でのみ追加する。指定しなければ既定値 (威力素点・壁なし・状態なし・連続技=auto) でそのまま計算される。

   • --wall reflect|light-screen|aurora-veil (または リフレクター/ひかりのかべ/オーロラベール) … 守り側の壁が場にある想定
   • --atk-status yakedo|mahi|doku|... (または やけど/まひ/...) … からげんき の威力 2x 判定 (まひ/やけど/どく/もうどく で発動、ねむり/あくびは行動不能扱いで発動しない)
   • --def-status ... … たたりめ の威力 2x 判定
   • --atk-rank-up-count N … アシストパワー の威力 = 20 + 20N
   • --def-rank-up-count N … つけあがる の威力 = 20 + 20N
   • --atk-hp 1/2 (または 50%) … やけっぱち の HP 半分以下判定
   • --def-item-removable … はたきおとす の 1.5x 判定 (奪える持ち物のときのみ)
   • --multi-hit 5 … Skill Link 技で 5 発固定 / auto は DB 参照 (ロックブラスト等 2-5 乱数は中央値 3)
   • --disguise-active … ミミッキュの初撃 (ダメージ 0 + disguise_blocked=true)

   damage_calcs ブログ埋め込みでは hits_dealt と disguise_blocked も meta.json に記録される。連続技は 1 発ぶんを element-wise で n 倍して 16 段テーブルに反映される。

   共通: opponent の実数値計算 (両 format で必要):

   # opponent の SP振りと性格補正から HP/A/B/C/D/S を取得
   OPP_STATS=$($PKDX stat-calc "<opponent_name>" --ev "<H>,<A>,<B>,<C>,<D>,<S>" \
       ${OPP_NATURE:+--nature "$OPP_NATURE"} --version champions --format json)
   # → 必要 stat (HP / 物理技なら A or B / 特殊技なら C or D) を jq で抽出
   

   攻め format の damage call (current member が攻撃、opponent が defender):

   # 技 category に応じて current member の攻撃 stat を members[i].actual_stats から取得
   # 物理技 → members[i].actual_stats.a / 特殊技 → members[i].actual_stats.c
   ATK_STAT=$( jq -r --arg key "<a or c>" '.members[i].actual_stats[$key]' "$CACHE_FILE" )
   # opponent の防御 stat を OPP_STATS から取得 (物理技 → b / 特殊技 → d) と HP
   DEF_STAT=$( echo "$OPP_STATS" | jq -r '.def or .spd' )
   DEF_HP=$( echo "$OPP_STATS" | jq -r '.hp' )
   
   $PKDX damage "<members[i].name>" "<opponent_name>" "<move_name>" \
     --atk-ability "<members[i].ability>" \
     --atk-item "<members[i].item>" \
     --atk-nature "<members[i].nature>" \
     --atk-stat $ATK_STAT \
     --def-stat $DEF_STAT \
     --def-hp $DEF_HP \
     ${OPP_NATURE:+--def-nature "$OPP_NATURE"} \
     --version champions \
     --attach-team "$STAGING" \
     --attach-title "<auto-generated, 例: '{move_name} vs {opp_sp}{opp_nature}{opp_name}'>"
   

   受け format の damage call (opponent が攻撃、current member が defender):

   # opponent の攻撃 stat を OPP_STATS から取得 (物理技 → atk / 特殊技 → spa)
   ATK_STAT=$( echo "$OPP_STATS" | jq -r '.atk or .spa' )
   # current member の防御 stat を members[i].actual_stats から取得 と HP
   # 物理技 → members[i].actual_stats.b / 特殊技 → members[i].actual_stats.d
   DEF_STAT=$( jq -r --arg key "<b or d>" '.members[i].actual_stats[$key]' "$CACHE_FILE" )
   DEF_HP=$( jq -r '.members[i].actual_stats.h' "$CACHE_FILE" )
   
   $PKDX damage "<opponent_name>" "<members[i].name>" "<move_name>" \
     --atk-stat $ATK_STAT \
     ${OPP_NATURE:+--atk-nature "$OPP_NATURE"} \
     --def-ability "<members[i].ability>" \
     --def-item "<members[i].item>" \
     --def-nature "<members[i].nature>" \
     --def-stat $DEF_STAT \
     --def-hp $DEF_HP \
     --version champions \
     --attach-team "$STAGING" \
     --attach-title "<auto-generated, 例: '{opp_name} {move_name} ({opp_sp}{opp_nature}) → {member_name}'>"
   

   フォーム揺れ注意: ギルガルドのような「攻撃時はブレード形態 / 防御時はシールド形態」のフォーム切り替え系は pkdx DB に攻撃時 base が登録されていない場合がある (シールド base spa=50 / ブレード base spa=140 等)。受け format でこれらを攻撃側に指定する場合、ユーザーに「pkdx 上はシールド形態のみ登録のため、攻撃時 base spa=140 から SP振りを反映した実数値を override します」と一行警告を出した上で手動 base から計算した値を --atk-stat で渡す。

7. cache への書き戻し: バッチ終了後、ステージング meta.json を読み、その damage_calcs 配列全体を cache.damage_calcs に上書き（staging は Phase 1-7 を通じて累積、cache は常にその snapshot を保持する single source）。

8. Phase 8 での扱い: Phase 8-2 の pkdx write teams は cache をそのまま使うので、staging に溜まった damage_calcs はそのまま meta.json に serialize される。staging ファイルは Phase 8 の cache 削除タイミングで同時削除する。

呼び出しタイミング

呼び出し元	タイミング
Phase 2-7 後	軸ポケモンの育成データ確定直後
Phase 3-6 後	攻め補完メンバーの育成データ確定直後
Phase 4-5 後	受け補完メンバーの育成データ確定直後
Phase 5-5 後	素早さ枠の育成データ確定直後
Phase 7-1 後	残未確定スロットの育成データ確定直後
Phase 1-Team-Vision step 4-b 後	各メンバーのメモ入力直後（vision 経由で育成データは既に埋まっているためメモ → ダメ計 の順で連続呼び出し）

---

Phase 0: 初期化

0-1: DB存在確認

$PKDX query "ピカチュウ" --format json >/dev/null 2>&1 && echo "OK" || echo "NOT_FOUND"

NOT_FOUNDの場合、以下を案内してスキルを終了:

pkdx CLI または pokedex.db / champions.db が見つかりません。リポジトリルートで以下を実行してください:
  ./setup.sh

0-2: 参照データ読み込み

以下を並列でReadする:

• $SKILL_DIR/references/stat_thresholds.md → 種族値ベンチマーク
• $SKILL_DIR/references/format_rules.md → メカニクスルール
• $SKILL_DIR/references/items_abilities.md → 持ち物・特性リファレンス

Note: タイプ相性は $PKDX type-chart および $PKDX coverage で計算可能。type.json の直接読み込みは不要。

0-3: バトル形式選択

AskUserQuestionでバトル形式を質問:

• singles: シングルバトル（3体選出）
• doubles: ダブルバトル（4体選出）

選択結果を battleFormat として以降のフェーズで使用。

0-4: メカニクス選択

AskUserQuestionで有効メカニクスを質問（multiSelect: true）:

• mega: メガシンカ
• gigantamax: キョダイマックス
• zmove: Zワザ
• terastal: テラスタル

未選択の場合はバニラルール（メカニクスなし）として動作。

0-5: バージョン確認

AskUserQuestion でゲームバージョンを質問:

• champions（デフォルト / 推奨）
• scarlet_violet（deprecated: 旧 EV/IV 制。SP 制の champions が現行推奨）
• legendsza（deprecated: 同上）
• その他（ユーザー入力）

推奨の理由: Champions 以降は SP (Stat Points) 制に一本化されており、damage 計算・実数値算出・select のメガ進化後再計算ともに SP 前提で最適化されている。旧 EV/IV 制 (scarlet_violet / legendsza 等) は後方互換のために残しているが、新規構築は champions を選択すること。

champions 選択時は続けてレギュレーションを質問:

• M-C（current）

キャッシュに version と regulation を記録。regulation は champions 以外では空文字。

これ以降、スクリプトに渡す --version / --regulation 引数として使用。

---

Phase 1: 軸ポケモン決定

version=champions の場合: チーム入力方式分岐

Phase 0 で version=champions を選択した場合、Phase 1 の冒頭で入力方式を質問する。それ以外の version では、直接「Phase 1 対話モード」に進む。

AskUserQuestion（1問）:

#	質問	header	オプション	multiSelect
1	チーム入力方式を選んでください	入力方式	対話で 1 体ずつ構築(desc: 従来通り Phase 1-5), ゲームのスクショから一括取り込み(desc: チーム画面の「能力」+「ステータス」2 枚から 6 体を OCR)	false

• 対話で 1 体ずつ構築 → 下記「Phase 1 対話モード」へ
• ゲームのスクショから一括取り込み → Phase 1-Team-Vision へ

Phase 1 対話モード

AskUserQuestionで軸ポケモンを聞く:

軸とするポケモンを1匹教えてください。
（日本語名・英語名どちらでもOK）

取得したポケモン名で以下を実行:

$PKDX query "<ポケモン名>" --version "<version>" --format json

フォーム違いポケモンの扱い

手順:

1. ユーザー入力名をそのまま pkdx query "<名前>" --version "<version>" --format json に渡す。以下は直接引ける:
   • 原種名に form 名を接頭/接尾した一意名: ウォッシュロトム / ヒートロトム / メガガブリアス / メガリザードンX 等
   • 合成された一意名: キュウコン（アローラ） / ランドロス（れいじゅう） / ガーディ（ヒスイ） / バクフーン（ヒスイ） 等
   • 英語名: Wash Rotom / Ninetales (Alolan) 等
2. 見つからない場合 (Error: Pokemon not found) は原種名で再 query し、返り値の forms[] を確認:
   • forms[] はその version に実在するフォームの一意名配列。原種引き時のみ列挙され、フォーム直引き時や形態無しの場合は JSON キーごと省略 される
   • 例: pkdx query ロトム --version champions → "forms":["ヒートロトム","ウォッシュロトム","フロストロトム","スピンロトム","カットロトム"]
   • 例: pkdx query キュウコン --version scarlet_violet → "forms":["キュウコン（アローラ）"]
3. ユーザー意図に合う一意名を選び、その名前で再度 query して該当フォームの type1 / type2 / ability1 / ability2 / dream_ability / 種族値を取得

注意点:

• 戦闘面で base と完全に同じフォーム (トリミアン毛型・ビビヨン模様・フラベベ花色・Unown 文字・マホイップ flavor 等) は forms[] に現れない。これらは原種として扱って問題ない
• 該当 version にそのフォームが実在しない場合は forms[] からも除外される (例: Champions にはランドロス（れいじゅう）未収録)
• メガシンカも form の一種として forms[] に含まれる (メガガブリアス 等)。メガ名で query するとメガ進化後の type/ability/stats が得られる

結果が空の場合:

• 名前の確認を再度AskUserQuestionで依頼
• メガシンカポケモンの場合: 以下のAskUserQuestionで案内:

AskUserQuestion（1問）:

#	質問	header	オプション
1	メガシンカポケモンのデータが見つかりませんでした。最新のメガシンカデータをDBに取り込みますか？（⚠ 実験的機能: マスターデータの更新時に再実行が必要になる場合があります）	メガデータ	はい(desc: メガシンカ64体のデータを取り込む), いいえ(desc: 通常フォームで続ける)

「はい」の場合:

"$REPO_ROOT/bin/pkdx" migrate --repo-root "$REPO_ROOT"

実行後、元のクエリを再実行してデータを取得する。取得できた場合はそのまま続行。 取得できなかった場合は「パッチ対象に含まれていないポケモンです」と案内する。

結果からglobalNoを取得し、以降のフェーズで使用。

---

Phase 1-Team-Vision: Champions チーム一括取り込み

Champions のチーム画面スクショ 2 枚 (能力 + ステータス) から 6 体分の team cache を冪等に構築する。1 枚に 6 体が並ぶ UI のため、12 枚や 1 体ずつのループは不要。

1. スクショ添付依頼

ユーザーへ以下のメッセージを出力し、次のメッセージで 2 枚の画像を会話に添付してもらう (AskUserQuestion ではファイル添付できないためテキスト指示):

Champions のチーム画面スクショ 2 枚を、次のメッセージにまとめて貼ってください:
 - 「能力」画面 (特性・持ち物・技 4 つ が 6 体分見えるもの)
 - 「ステータス」画面 (SP・実数値・性格 ↑↓ が 6 体分見えるもの)

ユーザーからの次のメッセージに添付された画像 path (会話履歴に残る一時パス、例: /var/folders/.../Image.png 等) を Read ツールで読み込んで vision 抽出に進む。画像が 1 枚しか無い / 関係ない画像の場合はもう一度添付を依頼する。

2. Vision 抽出 (6 体一括)

2 枚の画像から、6 体それぞれについて以下を一度に vision で抽出する:

• ポケモン名 (日本語カタカナ)、性別マーク (♂/♀/無性別)
• 特性、持ち物 (能力画面)
• 技 4 つ (能力画面、名前のみ)
• SP 配分 (ステータス画面、各 ≤ 32、合計 ≤ 66)
• 実数値 (ステータス画面、検算用)
• 性格 ↑↓ マーカー (ステータス画面、ステータス名右の↑/↓記号)

中間結果は 6 体分まとめて表示する (体ごとに分割表示しない)。

3. 各体ごとの DB 照合 / SP 逆算 / 性格確定 / 技補完

抽出した 6 体について、ポケモンごとに以下を順次実行する。ユーザー対話は発生させず一括で進める (性格が一意に決まらない個体だけ、後段の確認時にまとめて選ばせる):

1. DB 照合: pkdx query "<name>" --version champions --format json で種族値・タイプ・特性候補を取得。Champions 側で未登録なら --version scarlet_violet で fallback

   • 性別でステータス・タイプ・特性が異なる種 (イダイトウ / イエッサン / パフュートン / ニャオニクス) を引く際は性別を明示する: イダイトウ（オス） / イダイトウ（メス） / 英名なら Basculegion (Male) / Basculegion (Female)。性別未指定の イダイトウ は M base を返すため F 個体を扱う際は必ず （メス） 付きで照合する
   • vision 抽出の性別マーク (♂ / ♀) は DB 照合直前に ♂ → （オス） / ♀ → （メス） へ正規化して pkdx query に渡す。イダイトウ♂ / イダイトウ♀ のままでは "Pokemon not found" になる

2. SP 逆算検証: pkdx stat-reverse "<name>" --stats "<HP>,<A>,<B>,<C>,<D>,<S>" --version champions --format json の出力 SP と vision 抽出 SP を比較。複数解は「いずれかと一致」で OK

3. 性格確定: ↑↓マーカーが読めていれば性格テーブルから直接特定。読めない場合は SP + 実数値の整合性で候補を絞る (team-builder/references/champions_sp.md 参照)。候補 1 つなら自動確定、複数候補は後段で AskUserQuestion

4. 技詳細補完: pkdx moves "<name>" --version champions --format json で抽出した 4 つの技名を DB 照合し、{name, type, category, power, accuracy} の 5 フィールドを members[i].moves[j] に格納する (issue #68 以降 accuracy も許容されるため手動で剥がす必要はない)。pkdx moves 出力には pp / learn_method / priority / stat_effects も含まれるが、これらはスキーマで拒否されるため抜粋が必要

5. 育成データ格納: 1-3 で検証済みの性格・SP・実数値を直接 members[i] に書き込む:

   • members[i].nature = "<性格名 JP>" (例: "ようき")
   • members[i].stat_points = {h, a, b, c, d, s} (vision 抽出 SP、stat-reverse と一致するもの)
   • members[i].actual_stats = {h, a, b, c, d, s} (vision 抽出の Lv50 実数値)

   本サブフローは メンバー確定共通: 育成データ入力 を経由しない（既に 3 種すべてが vision から取得済みで、再質問は冗長）。vision 検証で矛盾が出た個体のみ、手順 4 の確認画面で AskUserQuestion により修正を受け付ける。

4. 6 体分まとめて表示 + 一括確認

=== Champions チーム抽出結果 (6/6 体) ===
[1] マンムー (ようき / こだわりスカーフ / あついしぼう)
    SP: H20 A32 B0 C0 D0 S14  技: じしん / つららおとし / つららばり / ばかぢから
[2] アシレーヌ (れいせい / しんぴのしずく / げきりゅう)
    SP: ...
...
[6] ヌメルゴン(ヒスイ) (ずぶとい / たべのこし / シェルアーマー)
    SP: ...

メガ石 (「〇〇ナイト」) を検出した体があれば末尾に警告:

⚠ 次のポケモンはメガ石を所持しています: ハッサム, キュウコン
   メガ進化の戦闘評価は task B 実装後に有効になります。

AskUserQuestion（1問）:

#	質問	header	オプション	multiSelect
1	このチーム構成でよいですか?	確認	はい(desc: team cache 組み立てに進む), 修正する(desc: 特定のポケモンの項目を個別修正), やり直す(desc: スクショ添付から再実行)	false

• 修正する → どのポケモン (1-6) のどの項目 (技 / 持ち物 / 性格 / SP 等) を上書きするか AskUserQuestion で選び、個別に修正
• やり直す → 手順 1 (スクショ添付依頼) から全体リセット

4-b. ポケモンメモ + ダメージ計算入力（任意）

確認 OK の後、6 体それぞれについて members[0] から順に以下を直列に実行する:

1. メンバー確定共通: ポケモンメモ入力 — フリー入力で次メッセージ全文を members[i].role に格納
2. メンバー確定共通: ダメージ計算入力 — AskUserQuestion で可否を聞き、「はい」の場合フォーマット入力を受け付けて cache.damage_calcs に追記

必ず 1 体ずつ のシーケンス（6 体分のメモを 1 メッセージにまとめて受け付ける bulk モードは廃止。理由: 共通サブフローの「次メッセージ全文 = 対象メンバーの入力」という契約を壊さないため）。

全員 なし 回答ならメモ・ダメ計は空のまま。

5. 取り込み後の動線を選択

AskUserQuestion（1問）:

#	質問	header	オプション	multiSelect
1	この後どうしますか?	動線	メタ分析・選出方針も対話で構築(desc: Phase 6 (仮想敵分析) に進む), 保存のみ(desc: Phase 8 に直行。メタ分析は空欄)	false

• メタ分析・選出方針も対話で構築 → Phase 6 に進む。team cache の members[0..5] は埋まっているので Phase 2-5 (軸分析・補完・素早さ・耐久) は skip
• 保存のみ → team cache の matchup_plans を空配列、concept を空文字のまま Phase 8 に直行。出力 md の冒頭に「⚠ メタ分析セクションは未記入。/team-builder で再開可能」と注記を入れる

6. team cache 組み立て + 冪等性判定

1. cache スケルトン生成:

$PKDX init-cache team > "$CACHE_FILE"

2. 抽出 6 体を members に詰め、version: "champions", regulation: "M-C", battle_format: "singles", mechanics: "メガシンカ" (該当時) を明記

3. pkdx import-check で冪等性判定:

EXISTING_DIR="$REPO_ROOT/box/teams"
if [ -d "$EXISTING_DIR" ]; then
  EXISTING=$(for f in "$EXISTING_DIR"/*.meta.json; do
    [ -f "$f" ] && jq --arg p "$f" '{path: $p, content: .}' "$f"
  done | jq -s '.')
else
  EXISTING='[]'
fi

jq -n \
  --slurpfile cache "$CACHE_FILE" \
  --argjson existing "$EXISTING" \
  '{kind: "team", cache: $cache[0], existing: $existing}' | \
  $PKDX import-check

出力に応じて分岐:

• {"status":"skip", "matched_file": "..."} → 既に同一データあり。AskUserQuestion: 保存せず終了 / 別名で保存する / やり直す
• {"status":"diff", "matched_file": "...", "differing_fields": [...]} → 差分を表示し、AskUserQuestion: 新規ファイルとして保存 / 既存を上書き / 保存せず終了
• {"status":"new"} → そのまま次のステップへ

4. ユーザー承認後、選んだ動線 (Phase 6 or Phase 8) に進む

---

Phase 2: 軸ポケモン分析

2-1: 技一覧取得

$PKDX moves "<globalNo>" --version "<version>" --format json

2-2: 特性の説明取得

$PKDX query のJSON出力から ability1, ability2, dream_ability を取得済み。特性の詳細説明が必要な場合は DB を直接クエリする:

sqlite3 "$REPO_ROOT/pokedex/pokedex.db" \
  "SELECT name, description FROM ability_language WHERE ability IN ('<ability1>', '<ability2>', '<dream_ability>') AND version='<version>' AND language='jpn';"

2-3: 分析結果を提示

以下の形式で提示:

## 軸ポケモン分析: {名前}

**タイプ**: {type1}/{type2}
**種族値**: H{hp} A{atk} B{def} C{spa} D{spd} S{spe} (合計: {bst})
**役割分類**: {stat_thresholds.mdから判定}

### 特性
- {ability1}: {説明}
  → 戦闘効果: {items_abilities.mdから該当する効果を分類表示}
- {ability2}: {説明}（あれば）
  → 戦闘効果: {同上}
- {dream_ability}: {説明}（夢特性）
  → 戦闘効果: {同上}

特性効果の分類:
  - 耐性付与: 「ふゆう → じめん無効」
  - 耐性変化: 「あついしぼう → ほのお/こおり半減」
  - 火力補正: 「ちからもち → 物理火力2倍」
  - 防御補正: 「マルチスケイル → HP満タン時ダメージ半減」
  - フィールド/天候: 「ひひいろのこどう → 晴れ展開+攻撃強化」
  - わざわい系: 「わざわいのつるぎ → 相手防御0.75x」

### 実質タイプ耐性（特性考慮）
| 攻撃タイプ | タイプ相性 | ability1考慮 | ability2考慮 | dream考慮 |
（免疫特性で弱点が消える場合や耐性変化がある場合のみ差分を表示）

### 主要技
#### STAB技（タイプ一致）
| 技名 | タイプ | 分類 | 威力 | 命中 |
（type1/type2に一致する技を威力順で）