メニュー
対戦用ポケモン構築支援（シングル/ダブル対応）。軸ポケモンからタイプ補完・メタ分析・選出パターンまでガイドする。構築したい・パーティを組みたい・チーム作成時に使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | team-builder |
| description | 対戦用ポケモン構築支援（シングル/ダブル対応）。軸ポケモンからタイプ補完・メタ分析・選出パターンまでガイドする。構築したい・パーティを組みたい・チーム作成時に使用。 |
| allowed-tools | Bash, WebFetch, Read, Write, AskUserQuestion |
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 に書き出す。
cat cache.json | pkdx write teams に直接渡す（JSON→マークダウン変換はCLI側で行う）$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> は Phase 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 等でマージ
<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"
init-cache team の重複指示があるが、Phase 0 で初期化済みなら再実行は不要（rename のみ行う）スキーマ定義は src/writer/schema.mbt の team_schema() がSSoT。初期JSONは以下のコマンドで生成する:
bin/pkdx init-cache team > "$CACHE_FILE"
生成されるJSONの特徴:
null0[]、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 で描画される。詳細は メンバー確定共通: ダメージ計算入力 を参照。
cat cache.json | pkdx write teams で直接マークダウンに変換各メンバーの特性・持ち物確定後、または Phase 1-Team-Vision でのスクショ取り込み確認後に呼び出す共通サブフロー。role フィールド（スキーマ上は文字列）へ自由メモを記入する。
役割と複数情報の併記も可。空文字 "" 許容（無理に埋めない）。
ユーザーへ次のテキストを出力（AskUserQuestion ではなくフリー入力依頼）:
{ポケモン名} のメモを入力してください（役割・採用理由・対面メモなど自由）。
不要なら「なし」と返答してください。
ユーザーの次のメッセージ全文を members[i].role に格納する（改行は半角スペース 1 個に正規化、目安 200 文字以内）
「なし」「skip」「省略」「-」等の場合は "" を格納
キャッシュファイルへ書き戻し、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 構築のみで有効)。
性格: AskUserQuestion で性格名を選択（ようき / ひかえめ / いじっぱり / ずぶとい など）。判断材料として $SKILL_DIR/references/stat_thresholds.md の "素早さティア" / "耐久ベンチマーク" を提示する。
SP/EV: 以下のいずれかで確定:
$PKDX hbd "<name>" --nature "<性格>" --fixed-ev "_,0,_,0,_,<S_sp>" で最適配分を取得し、上位候補を AskUserQuestion で提示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 のまま）。
実数値の算出: 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 とする。
キャッシュ書き戻し + Team State Block 更新: members[i] の 3 フィールドを埋めてキャッシュ JSON を再保存し、Team State Block の該当行に「性格: / SP: / 実数値:」を反映する。
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 に渡り記事に反映される。
実行可否判定: AskUserQuestion:
| # | 質問 | header | オプション |
|---|---|---|---|
| 1 | {ポケモン名} のダメージ計算を入力しますか? | ダメ計 | はい(desc: 次メッセージで計算対象を複数行入力), いいえ(desc: スキップ) |
「いいえ」なら即次のメンバーへ。
対象入力: 「はい」の場合、以下のテキストをユーザーへ出力（AskUserQuestion ではなくフリー入力依頼）:
{ポケモン名} のダメージ計算対象を、以下のいずれかのフォーマットで 1 行 1 エントリで入力してください（複数可）。
攻め (current member が攻撃): {技名}->{SP振り},{性格補正},{ポケモン名},{天候などの条件}
受け (current member が防御): {SP振り},{性格補正},{ポケモン名},{技名},{天候などの条件}
不要なら「なし」と返答してください。
例:
じしん->H32,無補正,ドドゲザン # カバルドンのじしんで H32無補正のドドゲザンを攻撃
逆鱗->H1,無補正,カイリュー
アイアンヘッド->H32B32,補正あり,メガピクシー
C32,補正あり,メガゲンガー,シャドーボール # メガゲンガー(C32補正あり)のシャドーボールでカバルドンが受ける
A32,無補正,ガブリアス,じしん
フォーマット判定:
-> が含まれる → 攻め (current member = attacker, listed pokemon = defender)-> が含まれない → 受け (current member = defender, listed pokemon = attacker){SP振り},{性格補正},{ポケモン名} の 3 要素は常に "相手 (= opponent)" のもの。current member の SP/性格/実数値は members[i] から暗黙取得し、入力で渡さない (重複入力で計算が食い違うのを防ぐため)。各フィールドの解釈ルール:
members[i].moves[].name に含まれること。受けなら pkdx moves "<opponent>" --version champions で習得確認{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 を決定:
ずぶとい (B↑), 特殊技なら しんちょう (D↑)いじっぱり (A↑), 特殊技なら ひかえめ (C↑)pkdx query "<name>" --version champions --format json で存在確認。メガX は DB 上のメガフォーム名に正規化（M-A で X メガ進化形 や メガ<X> の綴り揺れを吸収）ステージング 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"
既存ファイルがあれば上書きせずそのまま使う（冪等）。
計算実行 + 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 で渡す。
cache への書き戻し: バッチ終了後、ステージング meta.json を読み、その damage_calcs 配列全体を cache.damage_calcs に上書き（staging は Phase 1-7 を通じて累積、cache は常にその snapshot を保持する single source）。
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 経由で育成データは既に埋まっているためメモ → ダメ計 の順で連続呼び出し） |
$PKDX query "ピカチュウ" --format json >/dev/null 2>&1 && echo "OK" || echo "NOT_FOUND"
NOT_FOUNDの場合、以下を案内してスキルを終了:
pkdx CLI または pokedex.db / champions.db が見つかりません。リポジトリルートで以下を実行してください:
./setup.sh
以下を並列で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 の直接読み込みは不要。
AskUserQuestionでバトル形式を質問:
選択結果を battleFormat として以降のフェーズで使用。
AskUserQuestionで有効メカニクスを質問（multiSelect: true）:
未選択の場合はバニラルール（メカニクスなし）として動作。
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-A（current）キャッシュに version と regulation を記録。regulation は champions 以外では空文字。
これ以降、スクリプトに渡す --version / --regulation 引数として使用。
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 へAskUserQuestionで軸ポケモンを聞く:
軸とするポケモンを1匹教えてください。
（日本語名・英語名どちらでもOK）
取得したポケモン名で以下を実行:
$PKDX query "<ポケモン名>" --version "<version>" --format json
手順:
pkdx query "<名前>" --version "<version>" --format json に渡す。以下は直接引ける:
ウォッシュロトム / ヒートロトム / メガガブリアス / メガリザードンX 等キュウコン（アローラ） / ランドロス（れいじゅう） / ガーディ（ヒスイ） / バクフーン（ヒスイ） 等Wash Rotom / Ninetales (Alolan) 等Error: Pokemon not found) は原種名で再 query し、返り値の forms[] を確認:
forms[] はその version に実在するフォームの一意名配列。原種引き時のみ列挙され、フォーム直引き時や形態無しの場合は JSON キーごと省略 されるpkdx query ロトム --version champions → "forms":["ヒートロトム","ウォッシュロトム","フロストロトム","スピンロトム","カットロトム"]pkdx query キュウコン --version scarlet_violet → "forms":["キュウコン（アローラ）"]type1 / type2 / ability1 / ability2 / dream_ability / 種族値を取得注意点:
forms[] に現れない。これらは原種として扱って問題ないforms[] からも除外される (例: Champions にはランドロス（れいじゅう）未収録)forms[] に含まれる (メガガブリアス 等)。メガ名で query するとメガ進化後の type/ability/stats が得られる結果が空の場合:
AskUserQuestion（1問）:
| # | 質問 | header | オプション |
|---|---|---|---|
| 1 | メガシンカポケモンのデータが見つかりませんでした。最新のメガシンカデータをDBに取り込みますか？（⚠ 実験的機能: マスターデータの更新時に再実行が必要になる場合があります） | メガデータ | はい(desc: メガシンカ64体のデータを取り込む), いいえ(desc: 通常フォームで続ける) |
「はい」の場合:
"$REPO_ROOT/bin/pkdx" migrate --repo-root "$REPO_ROOT"
実行後、元のクエリを再実行してデータを取得する。取得できた場合はそのまま続行。 取得できなかった場合は「パッチ対象に含まれていないポケモンです」と案内する。
結果からglobalNoを取得し、以降のフェーズで使用。
Champions のチーム画面スクショ 2 枚 (能力 + ステータス) から 6 体分の team cache を冪等に構築する。1 枚に 6 体が並ぶ UI のため、12 枚や 1 体ずつのループは不要。
ユーザーへ以下のメッセージを出力し、次のメッセージで 2 枚の画像を会話に添付してもらう (AskUserQuestion ではファイル添付できないためテキスト指示):
Champions のチーム画面スクショ 2 枚を、次のメッセージにまとめて貼ってください:
- 「能力」画面 (特性・持ち物・技 4 つ が 6 体分見えるもの)
- 「ステータス」画面 (SP・実数値・性格 ↑↓ が 6 体分見えるもの)
ユーザーからの次のメッセージに添付された画像 path (会話履歴に残る一時パス、例: /var/folders/.../Image.png 等) を Read ツールで読み込んで vision 抽出に進む。画像が 1 枚しか無い / 関係ない画像の場合はもう一度添付を依頼する。
2 枚の画像から、6 体それぞれについて以下を一度に vision で抽出する:
中間結果は 6 体分まとめて表示する (体ごとに分割表示しない)。
抽出した 6 体について、ポケモンごとに以下を順次実行する。ユーザー対話は発生させず一括で進める (性格が一意に決まらない個体だけ、後段の確認時にまとめて選ばせる):
DB 照合: pkdx query "<name>" --version champions --format json で種族値・タイプ・特性候補を取得。Champions 側で未登録なら --version scarlet_violet で fallback
イダイトウ（オス） / イダイトウ（メス） / 英名なら Basculegion (Male) / Basculegion (Female)。性別未指定の イダイトウ は M base を返すため F 個体を扱う際は必ず （メス） 付きで照合する♂ → （オス） / ♀ → （メス） へ正規化して pkdx query に渡す。イダイトウ♂ / イダイトウ♀ のままでは "Pokemon not found" になるSP 逆算検証: pkdx stat-reverse "<name>" --stats "<HP>,<A>,<B>,<C>,<D>,<S>" --version champions --format json の出力 SP と vision 抽出 SP を比較。複数解は「いずれかと一致」で OK
性格確定: ↑↓マーカーが読めていれば性格テーブルから直接特定。読めない場合は SP + 実数値の整合性で候補を絞る (team-builder/references/champions_sp.md 参照)。候補 1 つなら自動確定、複数候補は後段で AskUserQuestion
技詳細補完: 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 も含まれるが、これらはスキーマで拒否されるため抜粋が必要
育成データ格納: 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 により修正を受け付ける。
=== 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 (スクショ添付依頼) から全体リセット確認 OK の後、6 体それぞれについて members[0] から順に以下を直列に実行する:
members[i].role に格納必ず 1 体ずつ のシーケンス（6 体分のメモを 1 メッセージにまとめて受け付ける bulk モードは廃止。理由: 共通サブフローの「次メッセージ全文 = 対象メンバーの入力」という契約を壊さないため）。
全員 なし 回答ならメモ・ダメ計は空のまま。
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 で再開可能」と注記を入れる$PKDX init-cache team > "$CACHE_FILE"
抽出 6 体を members に詰め、version: "champions", regulation: "M-A", battle_format: "singles", mechanics: "メガシンカ" (該当時) を明記
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"} → そのまま次のステップへ$PKDX moves "<globalNo>" --version "<version>" --format json
$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';"
以下の形式で提示:
## 軸ポケモン分析: {名前}
**タイプ**: {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に一致する技を威力順で）
#### 補完技（タイプ不一致の攻撃技）
| 技名 | タイプ | 分類 | 威力 | 命中 |
（STAB以外の攻撃技を威力順で上位10個）
#### 変化技（主要なもの）
| 技名 | タイプ | 効果概要 |
（category=変化の技から対戦で有用なもの）
#### 【doubles時のみ】ダブルバトル向けサポート技
| 技名 | タイプ | 効果概要 | カテゴリ |
（items_abilities.md §8 のダブル向け技リストと照合し、習得可能なものを抽出）
カテゴリ: 味方支援 / リダイレクト / S操作 / 全体防御 / 妨害
AskUserQuestionで採用特性を確定（ability1/ability2/dream_abilityから1つ選択）。 各選択肢のdescriptionに戦闘効果を記載する。
確定した特性と役割分類に基づき、items_abilities.mdから推奨持ち物を2-3個提案:
AskUserQuestionで持ち物を確定（「後で決める」も選択可）。
メンバー確定共通: ポケモンメモ入力 の手順で軸ポケモンのメモを members[0].role に格納する。
メンバー確定共通: 育成データ入力 の手順で軸ポケモンの性格・SP (Champions) or EV (deprecated)・実数値を members[0].nature / members[0].stat_points / members[0].actual_stats に格納する。
メンバー確定共通: ダメージ計算入力 の手順で軸ポケモンを攻撃側とした代表技のダメージ計算を cache.damage_calcs に追記する。「いいえ」ならスキップ。
type.jsonを参照し、以下のアルゴリズムで計算:
## 攻めの相性補完
### STAB技で抜群を取れるタイプ
{type1で抜群: ...}, {type2で抜群: ...}
### 技範囲全体で抜群を取れるタイプ
{全攻撃技で抜群が取れるタイプ一覧}
### 攻めの穴（抜群を取れないタイプ）
{18タイプから攻撃範囲を引いた残り}
### 穴を埋めるタイプ提案
| 攻めの穴 | 抜群を取れるタイプ |
軸の確定特性がスキン系・火力補正系の場合、実質的な攻撃範囲を補正:
攻めの穴を埋めるタイプで候補を検索:
$PKDX search --type "<穴を埋めるタイプ>" --version "<version>" --format json
候補に対して $PKDX query で特性も取得し、特性込みで評価:
ダブルバトルでは軸との「横の並び」（同時に場に出るペア）を重視して評価する。items_abilities.md §8〜§10 を参照し、以下の観点で候補をスコアリング:
AskUserQuestionで:
メンバー確定時:
$PKDX query で特性一覧を取得members[i].role を埋めるmembers[i].nature / stat_points / actual_stats を埋めるtype.jsonおよびitems_abilities.mdを参照し、以下のアルゴリズムで計算:
倍率 = type.json[攻撃タイプ][type1] × type.json[攻撃タイプ][type2]type.json[攻撃タイプ][type1]のみ0（無効）に変更（例: ふゆう → じめん = 0）## 受けの相性補完
### 弱点
| 攻撃タイプ | 倍率 |
（弱点を倍率の高い順に）
### 耐性
| 攻撃タイプ | 倍率 |
（半減以下を）
### 無効
| 攻撃タイプ |
### 弱点を補完するタイプ提案
| 弱点 | 半減以下で受けられるタイプ |
弱点を受けられるタイプで候補を検索:
$PKDX search --type "<弱点を受けるタイプ>" --version "<version>" --format json
候補に対して $PKDX query で特性も取得し、特性による実質耐性で再評価:
相性補完コアの提示: 軸 + 補完で互いの弱点をカバーし合う組み合わせを提案（特性込み）。
ダブルバトルでは隣のポケモンを守る手段も「受けの補完」に含まれる:
AskUserQuestionで:
メンバー確定時:
$PKDX query で特性一覧を取得members[i].role を埋めるmembers[i].nature / stat_points / actual_stats を埋めるstat_thresholds.mdを参照し、確定メンバーの素早さティアを判定。
チーム全体にTier A以上（base 111+）のポケモンが1体もいない場合、以下を警告:
⚠ チームに高速ポケモンがいません。以下のいずれかが必要です:
- base S 111+の高速ポケモンを追加
- こだわりスカーフで中速ポケモンを高速化
- おいかぜ/トリックルームなどのS操作技
Tier B-C帯のポケモンでも、こだわりスカーフ持ちなら高速ポケモンを抜ける場合がある。
計算: スカーフ最速 = (base S × 2 + 52) × 1.1 × 1.5（小数点切り捨て）
既にチームにスカーフ持ちが確定していない場合、スカーフ枠の候補も提示。
ダブルバトルではS操作技がシングル以上に重要。チーム内のS操作手段を棚卸し:
| S操作手段 | 効果 | 持続 | 評価基準 |
|---|---|---|---|
| おいかぜ | 味方全体S2倍 | 4ターン | 中速チーム向き。始動役の耐久が重要 |
| トリックルーム | S逆転 | 5ターン | 低速エース軸。始動役が倒されないよう保護が必要 |
| こごえるかぜ / エレキネット | 相手S1段階↓ | 永続 | 控えめだが全体技で両方に入る |
| ねこだまし | 相手1体ひるみ | 1ターン | S操作の始動ターンを確保する補助 |
チーム内にS操作手段が0個の場合は警告し、おいかぜ/トリックルーム始動役の追加を提案。
Phase 3-4で決めた補完タイプと両立する高速ポケモンを検索:
$PKDX search --type "<補完タイプ>" --min-speed 100 --version "<version>" --format json
AskUserQuestionで素早さ枠の方針を確認。
メンバー確定時:
$PKDX query で特性一覧を取得members[i].role を埋めるmembers[i].nature / stat_points / actual_stats を埋める耐久寄りのポケモン（HP/防御型アタッカー、壁役、受けポケ等）にSPを振る際は、pkdx hbd で総合耐久指数 HBD/(B+D) を最大化する配分を自動算出できる。S振りを固定して残りを H/B/D に最適配分:
# デフォルト (Champions SP): 予算66、各上限32
$PKDX hbd "<name>" --nature "<nature>" --fixed-ev "_,0,_,0,_,<S_sp>"
# Deprecated版: --version scarlet_violet 指定時は EV として解釈（予算508、各上限252）
$PKDX hbd "<name>" --nature "<nature>" --fixed-ev "_,0,_,0,_,<S_ev>" --version scarlet_violet
--hp-snap leftovers: たべのこし持ちは 16n+1（H ≡ 1 mod 16）--hp-snap residual: 定数ダメ耐性重視は 16n-1--phys-weight P --spec-weight S: 物理/特殊のメタを反映した非対称重み（例: 物理多なら --phys-weight 2）--top N: 上位 N 候補を比較（微差の配分を選択）アルゴリズムの詳細・H=B+D の導出・11n調整との関係は .claude/skills/team-builder/references/bulk_theory.md を参照。SP システムの詳細は .claude/skills/team-builder/references/champions_sp.md を参照。
ユーザーに想定する仮想敵6体を直接指定してもらう（手動入力）。AskUserQuestionで以下を確認:
ユーザー提示のリストから6体を選出する基準:
各仮想敵のデータ取得:
$PKDX query "<仮想敵名>" --version "<version>" --format json
AskUserQuestionで仮想敵リストを提示し、入れ替えを受付。
ここまでのフェーズで集まった情報を統合し、6体の構築を確定する。
| Slot | 役割 | 決定元 |
|---|---|---|
| 1 | 軸 | Phase 1 |
| 2 | 攻め補完 | Phase 3 |
| 3 | 受け補完 | Phase 4 |
| 4 | 素早さ枠 | Phase 5 |
| 5 | メタ対策枠 | Phase 6 |
| 6 | 汎用/糊枠 | 残りの弱点を埋める |
未確定のスロットがある場合、Phase 3-5の候補リストから提案し、AskUserQuestionで決定。 各未確定メンバーの確定時にも特性選択 + 持ち物提案 + ポケモンメモ入力 + 育成データ入力 + ダメージ計算入力 を行う（Phase 3-5と同様のフロー）。共通サブフロー: ポケモンメモ入力 / 育成データ入力 / ダメージ計算入力 を参照。
6体全員の持ち物を一覧し、重複がないことを確認。 重複がある場合はAskUserQuestionで代替を提案。
6 体の nature / stat_points / actual_stats が全員分揃っていることを確認する。未設定のメンバーがいれば メンバー確定共通: 育成データ入力 を個別に呼び、最終的に全員 3 フィールドが埋まった状態で Phase 7-2 以降（カバー率計算 / 選出パターン決定）に進む。
理由: Phase 7-3 の選出パターン決定は ダメージ計算 (pkdx damage) を前提としており、また Phase 8 で保存された box/teams/*.meta.json が pkdx select への入力になる。ここで未設定のまま進むと、後段の分析結果が実構築と乖離する。
埋まっていない場合の Team State Block の確定メンバー行例:
2. ガブリアス (攻め補完) 特性:さめはだ 持ち物:こだわりハチマキ メモ: 性格:未設定 SP:未設定 実数値:未設定
このような「未設定」表記が 1 件でも残っている場合、本ステップで必ず埋めてから次に進む。
type.jsonを参照し、チーム全体の攻撃・防御カバー率を計算:
攻撃カバー率:
防御カバー率:
仮想敵ごとの 6 枚カードではなく、**このチームの「基本選出」と「サブプラン」**の 2 つを決める。
それぞれ {members: string[], note: string} を cache の primary_selection / alternate_selection に格納する (両方 optional、片方だけ入力して Phase 8 に進んでもよい)。
重要: AI が note を勝手に書かない。タイプ相性・特性・技の通り具合の推定で誤情報（特に タイプ相性の読み違い）が混入しやすい。note はユーザーからのフリー入力 or 空文字のみ。
以下の 2 サイクルを実行する:
members の確定:
pkdx type-chart "<仮想敵の type1>[,<仮想敵の type2>]" --move-type <技タイプ> で実倍率取得pkdx query で特性・種族値取得note のフリー入力: 以下のテキストを出力してユーザーの次メッセージ全文を note に格納する (改行は半角スペース 1 つに正規化):
{表選出 or 裏選出} の狙い・立ち回り・想定ターン・注意点などを入力してください。
不要なら「なし」と返答してください。
「なし」「skip」「省略」「-」→ 空文字格納。
同じ手順で 裏選出 を確定。AskUserQuestion で「裏選出を設定しますか？」を 1 問入れて、「いいえ」なら裏選出を未設定のまま Phase 7-4 へ進む。
{
"primary_selection": {
"members": ["エンニュート", "ギャラドス", "ピクシー"],
"note": "表選出の狙い..."
},
"alternate_selection": {
"members": ["ハッサム", "ピクシー", "ブリジュラス"],
"note": "裏選出の狙い..."
}
}
members / note 未入力なら空配列 / 空文字を格納。
旧 matchup_plans[] は 新規構築では作らない（writer schema には互換目的で残っているが emit しない）。既存 meta.json に matchup_plans が残っている場合、FE は primary/alternate が未設定のときのみフォールバック描画する。
terastalメカニクスが有効な場合、AskUserQuestionで:
megaメカニクスが有効な場合:
構築コンセプト（構築の狙い・勝ち筋・想定した立ち回り）を team cache の concept フィールドに書き込む。記事冒頭のチャプター「構築コンセプト」として掲載される。
要約の材料は members[].role（各メンバーのポケモンメモ） のみ を使う。Phase 7-3 の matchup_plans は typing 誤認の危険があるため要約材料にしない。Phase 7-4/5 (テラス / メガ枠) の 事実情報 (どのポケモンにメガ石が乗っているか等) は補足として含めてよいが、AI による戦術評価・タイプ相性判定は含めない。
要約生成: 6 体の role フィールドを材料に、200〜400 文字で「軸は何で、どうやって勝つか」を日本語で要約する。以下のガードレールを守る:
members[].item / mechanics 設定から確認してから書く（記憶に頼らない）ユーザーへフィードバック: 生成した要約を提示してから AskUserQuestion:
| # | 質問 | header | オプション |
|---|---|---|---|
| 1 | この要約を構築コンセプトとして採用しますか? | コンセプト確定 | このまま採用(desc: 要約をそのまま concept に格納), 追記したい(desc: 次メッセージで追記内容を受け付け), 書き直す(desc: 次メッセージでユーザー自身が全文を書き直す), 空のまま進む(desc: concept = 空文字。記事にコンセプト章は出ない) |
追記/書き直し の場合: 次メッセージのユーザー入力全文を採用（追記なら生成要約 + ユーザー追記、書き直しなら完全置換）
cache の concept に格納
ダメージ計算結果は Phase 2-8 / 3-6(8) / 4-5(7) / 5-5(7) / 7-1(damage) / Phase 1-Team-Vision step 4-b の メンバー確定共通: ダメージ計算入力 で都度累積されている想定。追加の計算が必要なら calc スキル側で pkdx damage --attach-team を実行できる。concept はそれら計算を前提にした勝ち筋の言語化として使う。
AskUserQuestion（3問）:
| # | 質問 | header | オプション | multiSelect |
|---|---|---|---|---|
| 1 | ポケソル形式のテキストも出力しますか？ | ポケソル出力 | はい(desc: ダメージ計算SV等で読み込めるテキストも出力), いいえ(desc: mdレポートのみ) | false |
| 2 | この構築データをバージョン管理の対象にしますか？ | バージョン管理 | はい(desc: gitで変更履歴を残す。GitHubアカウントがあればクラウドにもバックアップ可能), いいえ(desc: 手元にのみ保存。gitには記録しない) | false |
| 3 | この構築を構築ブログで公開しますか？ | ブログ公開 | いいえ(default, desc: 下書き状態で保存。ブログには掲載されない), はい(desc: 公開状態で保存。fork で構築ブログを有効化済みなら push 時に掲載される) | false |
質問2の回答に基づきファイル名を決定:
{軸ポケモン名}-build-{YYYY-MM-DD} （通常のファイル名）__no_save.{軸ポケモン名}-build-{YYYY-MM-DD} （gitignore対象）質問3の回答は md の frontmatter published: を決める:
published: false (ブログ非掲載)。後から公開したくなったら md の published: を true に書き換えるか、同じ引数で --publish を付けて pkdx write teams を再実行するpublished: true (ブログ掲載)。既存 md の edit-lock はそのまま有効構築ブログのメンバーカードは site/public/pokemons/<member.name>.{png,jpg} を自動的に右上に表示する。Phase 8-2 で md を書き出す前に、6 体分の画像をチャットへ添付することで一括登録できる。手動で site/public/pokemons/ にファイルを置く必要はない。
外部 runtime 不要: 画像配置は agent (Claude) が file で形式・寸法を判定し、cp で site/public/pokemons/ へ直接保存する。Bun / Node 等の追加 runtime は不要。
スキップ可: 画像が要らない / 後で blog skill の Phase H から登録する場合は、この 8-1.5 を丸ごと skip して 8-2 に進む。
AskUserQuestion (1問):
| # | 質問 | header | オプション | multiSelect |
|---|---|---|---|---|
| 1 | このタイミングでメンバー画像を添付しますか？ | 画像添付 | 後で(default, desc: 8-2 へ進む。後から blog skill の Phase H で追加可能), 今添付する(desc: 6 体分の画像を順番に添付) | false |
「後で」なら 8-1.5 を終了し 8-2 に進む。
「今添付する」が選ばれた場合、cache の members[].name を全件列挙して、各メンバーの画像配置状況を表示する:
for name in $(キャッシュから member.name を順番に取得); do
if [ -f "$REPO_ROOT/site/public/pokemons/${name}.png" ]; then
echo "${name} ✓ (png)"
elif [ -f "$REPO_ROOT/site/public/pokemons/${name}.jpg" ]; then
echo "${name} ✓ (jpg)"
else
echo "${name} ✗ (未配置)"
fi
done
通常メッセージとして一覧を表示。
AskUserQuestion (multiSelect):
| # | 質問 | header | オプション | multiSelect |
|---|---|---|---|---|
| 1 | どのメンバーの画像を添付しますか？ | 対象 | members[] 各エントリ (各 desc に 「未配置 / 既存あり (差し替え)」を表示) | true |
選択 0 件なら 8-1.5 を終了し 8-2 へ。
選択リストを順番に処理する。各メンバーごとに通常メッセージで以下を提示:
[1/3] カバルドン の画像を添付してください
仕様: 340×340 以上の正方形、PNG または JPEG
(skip する場合は「skip」と入力)
ユーザーが画像を添付すると agent にローカルファイルパスが渡される。以下をこの順序で実行する (詳細は blog skill Phase H-4 と同一)。
SRC="<添付ファイルの絶対パス>"
[ -L "$SRC" ] && echo "REJECT_SYMLINK"
REJECT_SYMLINK が出たら「symlink は受け付けません」を提示し再添付要求 (skip なら次へ)。
file で取得 + 判定file "$SRC"
agent が出力をパース (BSD/GNU 共通フォーマット PNG image data, W x H / JPEG image data, …, WxH):
reject なら理由提示 + 再添付要求。skip なら次へ。
形式から拡張子を決め (PNG → .png、JPEG → .jpg)、保存先パスを組み立て:
DEST="$REPO_ROOT/site/public/pokemons/<member.name>.<ext>"
既存ファイルがある場合のみ AskUserQuestion (1問):
| # | 質問 | header | オプション | multiSelect |
|---|---|---|---|---|
| 1 | <member.name> の画像 (<DEST>) が既に存在します。どうしますか？ | 上書き | 上書きする(desc: 既存を消して新しい画像で置き換え), skip(desc: 既存を残す), 中断(desc: 8-1.5 を抜けて 8-2 へ) | false |
mkdir -p "$REPO_ROOT/site/public/pokemons"
cp "$SRC" "$DEST"
成功なら通常メッセージで「✓ <member.name>. を保存しました (×)」と報告し次のメンバーへ。
全メンバー処理後、まとめを通常メッセージで出力:
画像添付完了:
✓ カバルドン.png 保存
✓ マンムー.png 保存
- アーマーガア skip
site/public/pokemons/ 配下に作成されています。
構築 md を出力します...
直後に自動で 8-2 へ遷移。site/public/pokemons/* への変更は team-builder からは commit しない (構築 md と一緒に blog skill の Phase G で反映確認するか、ユーザーが手動で commit する)。
キャッシュ JSON はPhase 0-7で段階的に構築済み。CLIがJSON→マークダウンCST→serializeを行うため、マークダウンを直接書く必要はない。
出力先:
box/teams/{軸ポケモン名}-build-{YYYY-MM-DD}.mdbox/teams/__no_save.{軸ポケモン名}-build-{YYYY-MM-DD}.md8-1の回答に基づき --axis の値を決定:
--axis "<軸ポケモン名>"--axis "__no_save.<軸ポケモン名>"# 8-1 の質問3 が「いいえ」: 非公開で保存 (published: false)
cat $CACHE_FILE | $PKDX write teams --date "YYYY-MM-DD" --axis "<軸ポケモン名 or __no_save.軸ポケモン名>"
# 8-1 の質問3 が「はい」: 構築ブログに掲載 (published: true)
cat $CACHE_FILE | $PKDX write teams --date "YYYY-MM-DD" --axis "<軸ポケモン名 or __no_save.軸ポケモン名>" --publish
CLIはキャッシュ JSON のスキーマ（members + coverage + defense_matrix 等）をバリデーションする。
全メンバーの moves が4技埋まっていない場合はバリデーションエラーとなる。
エラー時の再試行: exit code が 0 以外の場合、stderrのエラーメッセージに基づいてキャッシュ JSON を修正し再試行する。最大3回まで。
生成される md の frontmatter: 構築ブログ (site/ の Astro が読む) 用に、以下の YAML frontmatter が自動付与される:
---
title: "<軸ポケモン名> 構築"
axis: "<軸ポケモン名>"
date: YYYY-MM-DD
battle_format: "singles" | "doubles"
mechanics: "..."
version: "..."
regulation: "..." # nullable
members: ["...", ...] # 名前フロー配列
tags: []
edited: false # ユーザーが手編集した場合に true に書き換える
published: false # `--publish` 指定時だけ true。構築ブログ掲載可否を決める (falsy = 非公開)
generated_by: "pkdx"
schema_version: 1
---
edit-lock (edited: true): ブログ向けに手編集した md は edited: true に書き換えておくと、次回以降の pkdx write teams 実行時に md を上書きしない (.meta.json は毎回更新される)。強制上書きしたい場合は --force を付ける:
cat $CACHE_FILE | $PKDX write teams --date "YYYY-MM-DD" --axis "..." --force
skip 時は stderr に Preserved hand-edited box/teams/<slug>.md と出るので、ユーザーには「前回の手編集を保持した。上書きしたい場合は再実行時に『--force で上書き』と伝えて」と案内する。
レポート出力後、ファイルパスをユーザーに通知。キャッシュファイルを削除する。
8-1で「はい」の場合のみ、Writeツールで以下の形式のテキストファイルを書き出す。
出力先: mdレポートと同じ prefix ルールを適用（バージョン管理なしの場合は __no_save. 付与）
box/teams/{軸ポケモン名}-build-{YYYY-MM-DD}.txtbox/teams/__no_save.{軸ポケモン名}-build-{YYYY-MM-DD}.txt各ポケモンのブロックを空行区切りで並べる:
{ポケモン名} / {特性} / {持ち物}
{技1} / {技2} / {技3} / {技4}
実数値: {HP}-{攻撃}-{防御}-{特攻}-{特防}-{素早さ}
SP: {HP}-{攻撃}-{防御}-{特攻}-{特防}-{素早さ}
性格: {性格名}
注意事項:
members[i].actual_stats / members[i].stat_points / members[i].nature から読み取る。未設定のまま Phase 8 に到達することは 7-1c でブロックしているため通常は発生しないが、例外的に未設定があれば 実数値: 未設定 / SP: 未設定 / 性格: 未設定 と記載してユーザーに警告するbox/pokemons/<name>/ 配下に breed 出力がある場合は breed 側 meta.json を fallback source として利用可能（同一ポケモン・同一性格の場合のみ）。新 schema では breed の build セクションの nature / stat_points / actual_stats / moves はそのまま members[i] に転写できる (キー互換)。各フェーズ終了時に以下を出力し、会話内の状態を管理する。contextが圧縮された場合も、最新のTeam Stateから状態を復元可能。また、キャッシュファイルからも読み出すことができる。
=== Team State (Phase N完了) ===
バトル形式: {singles or doubles}
メカニクス: {有効メカニクス}
バージョン: {version}
軸: {名前} ({type1}/{type2}) [{H}/{A}/{B}/{C}/{D}/{S}] globalNo:{globalNo}
攻めカバー: {タイプ一覧} → {X}/18タイプ
攻めの穴: {タイプ一覧}
弱点: {タイプ(倍率)}（特性補正込み）
耐性: {タイプ(倍率)}（特性補正込み）
素早さ: Tier {X} (base {S})
確定メンバー:
1. {名前} (軸) 特性:{特性名} 持ち物:{持ち物名} メモ:{role or 未記入} 性格:{nature or 未設定} SP:{HABCDS or 未設定} 実数値:{HABCDS or 未設定}
2. {名前 or 検討中} (攻め補完) 特性:{特性名} 持ち物:{持ち物名} メモ:{role or 未記入} 性格:{nature or 未設定} SP:{HABCDS or 未設定} 実数値:{HABCDS or 未設定}
3. {名前 or 検討中} (受け補完) 特性:{特性名} 持ち物:{持ち物名} メモ:{role or 未記入} 性格:{nature or 未設定} SP:{HABCDS or 未設定} 実数値:{HABCDS or 未設定}
4. {名前 or 検討中} (素早さ枠) 特性:{特性名} 持ち物:{持ち物名} メモ:{role or 未記入} 性格:{nature or 未設定} SP:{HABCDS or 未設定} 実数値:{HABCDS or 未設定}
5. {名前 or 検討中} (メタ対策) 特性:{特性名} 持ち物:{持ち物名} メモ:{role or 未記入} 性格:{nature or 未設定} SP:{HABCDS or 未設定} 実数値:{HABCDS or 未設定}
6. {名前 or 検討中} (汎用) 特性:{特性名} 持ち物:{持ち物名} メモ:{role or 未記入} 性格:{nature or 未設定} SP:{HABCDS or 未設定} 実数値:{HABCDS or 未設定}
使用済み持ち物: [{持ち物1}, {持ち物2}, ...]
【doubles時のみ】S操作手段: {おいかぜ/トリックルーム/ねこだまし等}
【doubles時のみ】横の並びペア: {主要な先発ペアとそのシナジー}
仮想敵: {6体のリスト or Phase 6で決定}
| 状況 | 対応 |
|---|---|
| pkdx / pokedex.db が見つからない | Phase 0でセットアップ手順を案内し終了 |
| pkdx query の結果が空 | ポケモン名の確認を再度依頼。リージョンフォームの可能性を案内。メガシンカの場合はパッチ実行を提案 |
| pkdx moves の結果が空 | version値の不一致の可能性を案内 |
| DB未収録のポケモン | AskUserQuestionでタイプ・種族値・主要技を手動入力してもらう |
pkdx write teams が legacy schema detected エラー | 該当 meta.json は旧 schema (hp/atk/... 長キー等)。bin/pkdx convert meta --in <path> --in-place で新 schema に変換してから再実行する |
ダメージ計算。攻撃側・防御側・技名を指定し、特性・持ち物・天候込みのダメージ乱数表を出力する。ダメージ計算・ダメ計・何発で落ちる等の質問時に使用。
ナッシュ均衡ソルバー。零和対戦 (ポケモン選出、構築マッチアップ、じゃんけん型メタ) の最適混合戦略、選出最適化 (pkdx select)、メタ乖離分析 (pkdx meta-divergence) を提供。「最適選出」「選出分布」「構築メタ」「対面ジャンケン」「使用率 vs 最適」等の質問時に使用。
ポケモン育成シミュレーション。性格・特性・持ち物・技・努力値を対話的に設定し、Lv50実数値を算出する。育成したい・実数値計算・努力値配分等の質問時に使用。
対戦中の高速応答モード。calc skillを事前ロードし、ダメ計とメモのラベル付き入力のみを最短で処理する。対戦中・バトル中・実戦中・対戦が始まる等の発話時に使用。