菜单
指定したフェーズを締める。`verify` で検証ゲートを通し、受け入れ基準を照合し、計画 README の進捗チェックを 更新し、確定した rule / skill の追従漏れを点検し、アーキ決定があれば `adr-new` を、関連 PR が merge 済なら `pr-retrospective` を促す。「フェーズ N を終わらせる」「Phase N 完了にして」「finish-phase N」 「このフェーズの締めをして」「受け入れ基準を満たしたか確認して進捗を更新して」と言われたとき、 実装が一段落して完了処理に入るときに使う。着手側は start-phase が担う。
用 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 | finish-phase |
| description | 指定したフェーズを締める。`verify` で検証ゲートを通し、受け入れ基準を照合し、計画 README の進捗チェックを 更新し、確定した rule / skill の追従漏れを点検し、アーキ決定があれば `adr-new` を、関連 PR が merge 済なら `pr-retrospective` を促す。「フェーズ N を終わらせる」「Phase N 完了にして」「finish-phase N」 「このフェーズの締めをして」「受け入れ基準を満たしたか確認して進捗を更新して」と言われたとき、 実装が一段落して完了処理に入るときに使う。着手側は start-phase が担う。 |
| allowed-tools | Read Edit Glob Grep Bash(pnpm *) Bash(gh *) |
引数で受け取ったフェーズを締めるための手順 skill。検証 → 受け入れ基準照合 → 進捗更新 → 追従点検 →
ADR / レトロの促しを一連で行い、完了の取りこぼし（ゲート未通過・基準未達・進捗未更新・記録漏れ）を防ぐ。
着手側は start-phase が担う。検証は verify に委譲する。
完了時のタスク（ゲート緑・基準照合・進捗更新・rule/skill 追従点検・ADR/レトロ記録）は多く、手動だと 抜ける。定型化して取りこぼしを防ぎ、機械ゲート・ADR 採番・レトロ生成は既存 skill に委譲する。
8 / phase-08 / Phase 8 等。start-phase と同じ正規化で対象 doc を特定する。verify の結果サマリ（緑 / 赤）。pr-retrospective を促すべき merge 済 PR の有無。start-phase 手順 1 と同じく docs/roadmap/**/phase-*.md を Glob で特定する。受け入れ基準 / 検証手順 /
タスクを Read で押さえる（以降の照合に使う）。
verify skill を使って pnpm verify を実行し、型 / テスト / カバレッジ / Lint が
緑であることを確認する。赤なら完了にしない。最初の失敗箇所を提示し、修正してから再度この手順に戻る。
機械ゲートの判定はここで verify に一任し、独自に再実装しない。
phase doc の「受け入れ基準」を 1 項目ずつ、リポジトリの現状（ファイルの実在・参照解決・記述整合・
verify 結果）と突き合わせて 充足 / 未充足 を判定する。未充足があれば列挙し、完了をブロックする。
判断に迷う項目は「検証手順」節の手順を実際に踏んで確認する。
進捗は二層で更新する（この手順 4 が二層更新の SoT）:
docs/roadmap/<NN>-*/README.md）のフェーズ一覧で、
対象フェーズの 1 行だけを - [ ]→- [x] に Edit する（per-phase 進捗の SoT）。他行・無関係記述に触れない。
phase doc が役割分担表等の追記を明示要求するときのみ追記する（重複させない）。docs/roadmap/README.md の status ロールアップ: 計画の状況が変わったときだけ
（最初の着手で ⬜→🚧、最終 phase 完了で 🚧→✅）該当行の status のみ更新する（n/n の分数は付けない）。
🚧→✅ に上げる前に、サブ README の phase 一覧が全て - [x] であることを確認する（(a) の per-phase 進捗と
ロールアップの乖離・更新漏れを防ぐ・learning #165 / #166。並行 phase は順序前後の [x]/[ ] 混在を許容するが
✅ 化は全 [x] が前提）。completed/ へ集約する: ✅ 化した計画ディレクトリを
git mv docs/roadmap/<NN>-<slug> docs/roadmap/completed/<NN>-<slug> で集約し、ロールアップ表のリンクを
completed/ パスへ更新する（active と完了を一目で分離）。移動は plan ディレクトリが 1 階層深くなる rename
なので、inbound 参照追従（リポジトリ全体の git grep）と移動 doc 内の相対リンク深度補正を伴う。移動 + 参照追従
チェックリストの SoT は [[planning]] の「計画群完了時の completed/ 集約」（個別 phase 完了では動かさず、
全完了時にまとめて移す）。この skill は移動を促すに留め、機械的追従は当該チェックリストに従う。idempotent: 既に - [x] / 同 status なら触らない。
注: 並走 worktree でオーケストレーターが一括更新する運用なら、この手順は「更新すべき箇所の提示」に留めてよい。
そのフェーズで新設・変更した rule / skill が、参照すべき箇所に反映されているかを点検する:
.claude/skills/<name>/SKILL.md）+ .agents/skills/<name> symlink が揃い、
両者が同一実体を指すか（cross-agent パリティ）。docs/harness/rules-index.md 等、存在すれば）や関連 doc から参照されているか。漏れがあれば指摘する（修正は局所なら行い、波及が大きければ別タスクとして提案する）。
このフェーズでアーキ決定（技術選定・パターン採用・不可逆なトレードオフ）を確定したなら
adr-new を促す。いつ ADR を残すかの基準は adr.md が SoT。
この skill は ADR を勝手に書かず起動を促すに留める（採番・雛形展開は adr-new の責務）。
このフェーズの PR が既に merge 済なら、pr-retrospective で KPT learning を
生成するよう促す。検出は次の要領:
gh pr list --state merged --limit 20 --json number,title,mergedAt
docs/harness/learnings/*-pr-<n>.md）が既にあれば促さない（idempotent）。pr-retrospective の起動を促すに留める（生成は当該 skill の責務）。bootstrap 注記: マージは別運用（オーケストレーター / auto-merge）が担うことがある。その場合この手順は 「merge 後に
pr-retrospectiveを回す」リマインドに留め、merge 前に無理に起動しない。
出力の形で、verify 結果・受け入れ基準の充足状況・進捗更新箇所・追従点検結果・ADR / レトロの要否を まとめる。未充足やブロッカーがあれば、それを最上段に明示する。
verify が緑でなければ未完了。基準照合より前にゲートを通す。verify、ADR は adr-new、レトロは
pr-retrospective。勝手に ADR 採番や learning 生成をしない（各 skill の採番 / idempotent を壊さない）。- [x]・learning 有り・ADR 有りなら二重実行しない。start-phase。verify。adr-new / 方針 .claude/rules/adr.md。pr-retrospective / docs/harness/README.md。code-review（ソース）/ harness-review（ハーネス資産）で意味的レビューしてから merge する（CI 緑 + ブロッキング指摘なしで auto-merge）。docs/roadmap/completed/00-harness-setup/README.md。