pokeform

reg 非依存の**全件名辞書**（`data/languages/*.yaml`）を PokeAPI 由来の全件名（ja/en）で満たす手順 skill。 「全件名を languages へ入れて」「名前辞書を埋めて」「ja/en 名が欠けている種族 / 持ち物 / 技 / 特性 / タイプ / メガを 埋めて」「PokeAPI の names / form_names を全件取り込んで」「pokeapi-names workflow を回して languages を更新して」 「languages の空骨格を scaffold して」「メガ名を PokeAPI で埋めて」「author-static-data <id...>」と言われた とき、または showdown 経路で解禁データを入れた後に名前が空のエントリを補うときに使う。取得 + 整形 + 書き込み + PR は **GitHub Actions `pokeapi-names.yml`**（全件列挙）が行い、本 skill はその dispatch → 生成 PR のドライブ → PokeAPI 非存在分の手作業著述（メガストーン名は命名慣例 / **Champions オリジナル特性・技名は Bulbapedia** 出典）→ verify → merge をドライブする。メガ名は PokeAPI `pokemon-form` の form_names（is_mega 判別）から取る 6 種目（ADR 0043）。構造データ（種族値 / タイプ / 特性 id / 図鑑番号 / category）の取得は pokemon-showdown 経路（`showdown:*`）、Champions 解禁データ（roster / 技 / メガ構造）の取得は Serebii 速報 / showdown 経路の責務で、こちらは **reg 非依存の名前辞書**のみを担う。生成 / 検証は `generate:data` / `verify` に委譲し機械ゲートは再実装しない。

指定レギュレーション <reg> の解禁データ（roster / 技 / 持ち物 / メガ）を pokemon-showdown 経路から取得して 全量投入する per-reg オーケストレーション skill。「レギュレーション <reg> の解禁データを取得して」 「M-A / M-B を全量投入して」「per-reg 解禁データを埋めて」「author-regulation-data <reg>」「data/ を削除した 状態から reg を復元して」「showdown-sync を回して解禁データを入れて」と言われたとき、または reg 単位の解禁 データを完全削除・部分欠損・完成済みのいずれからでも冪等に収束させたいときに使う。前提ゲート （author-static-data の全件名辞書 + rules.yaml / type-specs.yaml 存在）→ per-reg reset → showdown-sync.yml dispatch → verify-showdown-pr 照合 → check:regulation → generate:data → pokemon-data-reviewer 依頼 → per-reg 静的著述（index.yaml の period + languages/regulations.yaml エントリ）を既存経路へ委譲してオーケストレーション する。取得実体・機械ゲートは再実装しない。新規 id の名前欠落は author-static-data へ委譲し、reg 非依存の全件名 辞書そのものは author-static-data の責務。

pokemon-showdown 経路（authoritative）が自動作成した `data:authoritative` ラベルの data 更新 PR の正確性を、 Serebii 速報スクレイパーを流用して照合し PR コメント + exit code（0=一致 / 1=差異）で返す手順 skill。 「showdown の PR を Serebii で照合して」「`data:authoritative` の data 更新 PR を確認して」「この showdown-sync の PR は正しい?」「verify-showdown-pr <PR>」「showdown 経路の YAML 差分を Serebii で裏取りして」と言われたとき、 または showdown-sync.yml が立てた解禁データ PR をマージ前に検証したいときに使う。WebFetch は使わず Serebii スクレイパー（`node scripts/scrape-serebii.ts`）の中間 JSON で照合する。レビュー観点・出力は code-review / redaction に準拠し、機械ゲート（型 / カバレッジ / Biome）は再実装しない。構造データ取得は showdown 経路、 全件名（ja/en）の取り込みは author-static-data の責務で、本 skill は照合専任。

`src/**`・`scripts/**` 等のライブラリ本体・データパイプラインを変更した PR / diff を、マージ前に 意味的レビューする。「コードをレビューして」「この PR を見て」「diff をレビュー」「マージ前に確認して」 「src の変更をレビュー」と言われたとき、または PR open 後にソース変更が含まれるときに使う。Google 12 観点 + AI 生成コード固有観点 + pokeform 規約で指摘する。機械ゲート（型 / カバレッジ / Biome）は再実行しない。 `.claude/rules`・`.claude/skills`・`AGENTS.md`・`CLAUDE.md`・`.githooks`・`docs/` 等のハーネス資産の 変更は `harness-review` を使う（こちらは src/scripts 専用）。

`.claude/rules`・`.claude/skills`・`.agents/skills`・`AGENTS.md`・`CLAUDE.md`・`.githooks`・ `.claude/settings.json`・`docs/roadmap`・`docs/adr`・`docs/harness` 等のハーネス資産（エージェント指示）を 変更した PR をマージ前にレビューする。「ハーネスの変更をレビューして」「rule / skill を見て」「AGENTS.md を レビュー」「この skill の trigger は妥当?」と言われたとき、または PR open 後にハーネス資産の変更が含まれる ときに使う。description trigger 精度 / クロスエージェント整合 / SoT 一貫性 / paths スコープ / redaction / ゲート二重化を指摘する。`src/**`・`scripts/**` のソース変更は `code-review` を使う（こちらはハーネス専用）。

育成済み個体の YAML を雛形から起こし、`check:individual`（覚えない技 / 使えない特性 / 性格 up=down / ポイント 66・各32）で tsc 検証して仕上げる手順 skill。「個体を作りたい」「ポケモンの育成データを書いて」 「この個体 YAML を検証して」「author-individual <species>」「team/individuals に個体を追加して」 「覚えない技が無いか確認して」と言われたとき、または個体ファイルを新規作成 / 修正してブラッシュアップ したいときに使う。対象レギュレーションを `regulations: [<id>...]` で宣言し、種族に応じて特性・技・持ち物を per-reg 種族 dex の許容値に絞り、合計66 を満たす雛形を提示してから `check:individual` で弾く。パーティ全体の 整合・弱点点検は `review-party` を使う。

指定したフェーズの phase doc を読み、依存・必要な rule / skill・受け入れ基準を整理して着手準備を整える（準備のみで実装はしない）。 「フェーズ N に着手する」「Phase N を始めたい」「次のフェーズの準備をして」「start-phase N」 「このフェーズの前提と受け入れ基準を教えて」と言われたとき、新しい実装単位に取りかかる最初に使う。 worktree 作成〜実装〜検証〜PR〜マージ〜レトロまで端から端まで駆動したいときは implementation-workflow を使う （本 skill はそのワークフローの着手準備ステップに相当する単発用途で、駆動は implementation-workflow の責務）。 実装の入口を定型化し、依存漏れ・受け入れ基準の見落としを防ぐ。

新しい ADR（アーキテクチャ決定記録）を docs/adr/ に採番して作成する。技術選定・パターン採用・不可逆なトレードオフを伴う決定をしたとき、あるいは既存 ADR を覆す（supersede する）ときに使う。ユーザーが「ADR を書きたい / 残したい」「この決定を記録して」「○○の ADR を起こして」と言ったり、明示せずともアーキ決定を確定させた文脈で必ず使う。

指定したフェーズを締める。`verify` で検証ゲートを通し、受け入れ基準を照合し、計画 README の進捗チェックを 更新し、確定した rule / skill の追従漏れを点検し、アーキ決定があれば `adr-new` を、関連 PR が merge 済なら `pr-retrospective` を促す。「フェーズ N を終わらせる」「Phase N 完了にして」「finish-phase N」 「このフェーズの締めをして」「受け入れ基準を満たしたか確認して進捗を更新して」と言われたとき、 実装が一段落して完了処理に入るときに使う。着手側は start-phase が担う。

Plan / Phase 確定後の 1 本の PR の実装ライフサイクル（worktree 作成 → 着手 → 実装+検証 → セルフ検証 → Draft PR → 独立レビュー → マージ → レトロ → worktree 削除）を Phase 0〜9 の多段で統合管理する オーケストレーター。「フェーズを最初から最後まで回して」「実装ワークフローを開始」「worktree から PR・マージ・レトロ・後片付けまで通して」「implementation-workflow で phase N を実装して」と言われたとき、 あるいは確定済み phase / plan の実装を端から端まで定型的に駆動したいときに使う。既存 skill（start-phase / verify / code-review / harness-review / finish-phase / pr-retrospective）を再利用して束ねるのが主眼で、 機械ゲートやレビュー観点は再実装しない。単発の着手のみは start-phase、完了のみは finish-phase を使う。

生の実装指示・機能要望・「〜を実装したい」「次はこれを作る」「この機能を追加して」を受けたら、着手の前に必ず最初に通す計画化の入口スキル。指示をブラッシュアップして `docs/roadmap/NN-{slug}/OVERVIEW.md` にまとめ、6 基準（意思決定の数 / 不可逆性 / スコープの広さ / 技術的難易度 / 想定 diff / 並行実装のしやすさ）で 1 phase = 1 PR に分割し、1 PR 妥当なら GitHub issue + implementation-workflow へ、複数 phase なら NN-{slug} 計画群を起こして start-phase / implementation-workflow へ繋ぐ。start-phase や implementation-workflow を直接呼ぶ前の前段として使い、いきなりコードを書き始めないこと。新規計画を起こす・テーマを phase 分割する・実装に取りかかる文脈で広く発火させる（under-trigger を避ける）。手動で OVERVIEW や phase doc を書かずにこのスキルを使う。ただし既に確定済みの phase doc（`docs/roadmap/NN-{slug}/phase-*.md`）に着手するだけなら本スキルは不要で start-phase / implementation-workflow を使う。

パーティ（個体 YAML + パーティ MD）の整合性と技範囲・防御弱点を CLI で一括チェックして要約する。 「パーティを見て」「この構築をチェック」「パーティの弱点を分析して」「review-party <path>」 「team/ のパーティをレビュー」「弱点集中や技範囲の穴を確認して」と言われたとき、または個体 / パーティファイルを編集してブラッシュアップしたいときに使う。`check:party`（参照切れ / 同種族重複 / 未解禁 / 体数）と `analyze:coverage`（弱点集中 / 技範囲の穴）を実行し、終了コードと指摘を要約する。 生成データ自体の妥当性レビューは `pokemon-data-reviewer` agent を使う（こちらは利用者向けパーティ点検）。

Dependabot などが作る依存更新 PR を、リリースノート・影響範囲・`pnpm verify`・CI を確認して マージ可否を判断し、安全なものだけ自動マージする手順 skill。「依存更新 PR を見て」「この Dependabot PR をマージしていい?」「dep-update <PR番号>」「<パッケージ名> の更新を確認して」 「依存のバージョン上げ PR をレビューして」と言われたとき、または依存追従 PR が来たときに使う。 引数は PR 番号 または 依存パッケージ名。マージは不可逆ゆえ〈可〉基準を全て満たす場合のみ実行する。

育成済み個体のステータス調整を壁打ちする手順 skill。`pokeform stat` で実数値・性格補正・耐久 / 火力 指数を確認し、「素早さ □□ 抜き」「攻撃 ○○ の技を確定耐え」等の目標から能力ポイント配分を逆算 （合計66 / 各≤32 制約・実現不能は報告）して調整案を提案する。「ステータスを調整したい」「耐久ラインを 逆算して」「素早さ○○抜きの振り方は?」「この技を確定耐えする配分は?」「火力と耐久どっちに振る?」 「stat-tuning <path>」「実数値を見せて」と言われたとき、または個体の振り直しをブラッシュアップしたい ときに使う。実数値計算・逆算は domain 純関数に委譲する。個体の技 / 特性 / 合計66 の妥当性検証は `author-individual`、パーティ全体の弱点 / 技範囲は `review-party` を使う。

複数の PR learning（docs/harness/learnings/*.md）の未処理ハーネス改善提案を集約 parse し、採用 / 見送り / 撤去 を判定して rule・skill・template の改修 PR や ADR 起票へ書き戻す。「learning を集約して」 「ハーネス改善提案をまとめて」「溜まった learning を処理して」「どの改善を採用すべき?」「ハーネスへ 書き戻して」と言われたときに使う。1 PR から learning を生成するのは pr-retrospective skill を使う。

マージ済の 1 Pull Request から KPT（Keep / Problem / Try）レトロの learning ファイルを生成し、 ハーネス改善提案を起票する。「PR のレトロ」「KPT 振り返り」「PR #NNN の learning を作って」 「マージした PR を振り返って」と言われたとき、または finish-phase 後に PR が merge 済みのときに使う。 複数 PR を集約してハーネスへ書き戻すのは harness-meta skill を使う。

検証ゲート（`pnpm verify` = 型 / テスト / カバレッジ / Lint）を実行し、結果を要約して返す。 「検証して」「ゲートを通したい」「型 / テスト / カバレッジ / Lint を確認したい」「verify を回して」 「緑か確認して」と言われたとき、コミット / PR 前に変更が壊れていないか確かめたいとき、 あるいは finish-phase など他 skill から検証が必要なときに使う。失敗時は最初の失敗箇所を指摘する。