メニュー
検証ゲート（`pnpm verify` = 型 / テスト / カバレッジ / Lint）を実行し、結果を要約して返す。 「検証して」「ゲートを通したい」「型 / テスト / カバレッジ / Lint を確認したい」「verify を回して」 「緑か確認して」と言われたとき、コミット / PR 前に変更が壊れていないか確かめたいとき、 あるいは finish-phase など他 skill から検証が必要なときに使う。失敗時は最初の失敗箇所を指摘する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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` を使う。
| name | verify |
| description | 検証ゲート（`pnpm verify` = 型 / テスト / カバレッジ / Lint）を実行し、結果を要約して返す。 「検証して」「ゲートを通したい」「型 / テスト / カバレッジ / Lint を確認したい」「verify を回して」 「緑か確認して」と言われたとき、コミット / PR 前に変更が壊れていないか確かめたいとき、 あるいは finish-phase など他 skill から検証が必要なときに使う。失敗時は最初の失敗箇所を指摘する。 |
| allowed-tools | Bash(pnpm *) |
pnpm verify を実行し、型 / テスト / カバレッジ / Lint の 4 ゲートの結果を人間が一目で分かる形に
要約して返す手順 skill。判定ロジック（しきい値・対象）の正本は package.json / vitest.config.ts /
biome.jsonc 側にあり、この skill はゲートを再実装せず、pnpm verify の結果を写して要約するだけ。
pnpm verify の生ログは長く、どこで落ちたか毎回読み解くのは負担になる。「緑か / 赤か」「赤ならどこか」を
即座に判断できるよう出力を定型化し、コミット前・PR 前・他 skill からの呼び出しで繰り返し使えるようにする。
pnpm verify を実行する。pnpm install を先に促す（自動実行はしない。判断はユーザーに委ねる）。pnpm verify
pnpm verify は pnpm typecheck（tsc --noEmit）→ pnpm test:cov（vitest run --coverage・しきい値 100%）
→ pnpm lint（biome check .）をこの順で直列実行する。前段が落ちると後段は走らないため、落ちたゲートより
後ろは「未実行」となる点に注意する。
ログを次の観点で読み、各ゲートの PASS / FAIL を判定する:
tsc がエラー 0 で終了したか。エラーは path(line,col): error TSxxxx 形式。Test Files / Tests が全 pass か。失敗は FAIL 行とテスト名で分かる。ERROR: Coverage ... does not meet threshold とカバレッジ表の Uncovered 行に出る。biome check . が No fixes applied 等で 0 件か。指摘は path:line:col 付きで出る。直列実行なので最初に落ちたゲートが根本原因。そのゲートの先頭の失敗 1 件をファイルパス付きで示し、 「ここを直してから再 verify」と促す。後段ゲートは未実行である旨も添える（直しても別の赤が残る可能性に注意）。
package.json /
vitest.config.ts / Biome 設定が正本。この skill は結果を写すだけで、独自にしきい値を持たない。Unsupported engine 等の [WARN] は verify の成否に影響しない。
終了コードと各ゲートの実体ログで PASS/FAIL を判定する。biome check --write（pnpm format）はこの skill の責務外。指摘の提示までに留める。package.json（verify script）/ vitest.config.ts（カバレッジしきい値）。.githooks/（pre-commit / pre-push）— ツール非依存の Git hooks ゲート。finish-phase がフェーズ完了時にこの skill を使う。