メニュー
複数の PR learning（docs/harness/learnings/*.md）の未処理ハーネス改善提案を集約 parse し、採用 / 見送り / 撤去 を判定して rule・skill・template の改修 PR や ADR 起票へ書き戻す。「learning を集約して」 「ハーネス改善提案をまとめて」「溜まった learning を処理して」「どの改善を採用すべき?」「ハーネスへ 書き戻して」と言われたときに使う。1 PR から learning を生成するのは pr-retrospective 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 | harness-meta |
| description | 複数の PR learning（docs/harness/learnings/*.md）の未処理ハーネス改善提案を集約 parse し、採用 / 見送り / 撤去 を判定して rule・skill・template の改修 PR や ADR 起票へ書き戻す。「learning を集約して」 「ハーネス改善提案をまとめて」「溜まった learning を処理して」「どの改善を採用すべき?」「ハーネスへ 書き戻して」と言われたときに使う。1 PR から learning を生成するのは pr-retrospective skill を使う。 |
| allowed-tools | Bash(gh *) Bash(git *) Read Write Edit Grep |
pr-retrospective が溜めた learning 群の 🤖 ハーネス改善提案（未処理 [ ]） を集約し、
採用 / 見送り / 撤去 を判定して、ハーネス（rule / skill /
template / ADR）へ書き戻す。これがループの二段目。改修 PR は作るが merge は人間 approve。
1 件の learning だけでは「たまたまの気づき」か「反復する構造的課題」か判別できない。複数 PR を横断して 反復シグナル（同種 Problem / Try が ≥2 PR で再出）を数えると、効果の高い改善だけをハーネスに昇格できる。 人手で全 learning を読み比べるのは高コストなので、parse → 判定 → 書き戻しを定型化する。
harness-meta-criteria.md。retrospective-format.md。[rule] / [skill] / [template] / [adr] / [remove] で改修先を分類する。skill-creator 経由（手書きで SKILL.md を起こさない・SoT は [[skill-authoring]]）。ADR が要る決定は adr-new で起票する。🤖 ハーネス改善提案 セクションから未処理（[ ]）のみを抽出する。[x] 済は skip:
grep -rn "^- \[ \] \`\[" docs/harness/learnings/
[rule] 等）と対象資産でグルーピングし、同種提案が何 PR で出たかを数える
（採用基準①「複数 PR ≥2 で反復」の判定材料）。harness-meta-criteria.md（判定基準の SoT）に照らして各提案を
採用 / 見送り / 撤去へ振り分ける。迷ったら見送りを既定にする（撤去は全基準充足 + 2 段階必須）。
採用区分ごとに処理する（プレフィックス別の処理先は criteria rule が SoT）:
harness/<purpose> ブランチで改修 PR を作る。[skill] は skill-creator 経由で canonical +
.agents/skills symlink パリティを維持、[adr] は adr-new で ADR 化。📝 harness-meta フィードバック > 見送り に理由を追記（Edit）。status: removed + cooldown / 段階2: cooldown 後に dangling ゼロ再確認して物理削除）。
1 段階での即削除は禁止。[ ]→[x] に更新し、📝 feedback > 採用 に採用先 PR リンクを追記。status を actioned に更新。.github/PULL_REQUEST_TEMPLATE/harness.md を複写してカスタマイズ:
gh pr create --base main --title "<title>" --body-file /tmp/<branch-slug>-pr.md
[x] 済を再処理しない（手順 1 で除外）。pnpm verify の責務。skill-creator 経由: 手書きで SKILL.md を起こさない。pr-retrospective — 1 PR から learning を生成する（一段目）。harness-meta-criteria.md — 採用 / 見送り / 撤去 判定基準。retrospective-format.md — learning 構造の SoT。docs/harness/README.md — ループ全体像。