القائمة
実装計画(plan.md)とチェックリストの影響範囲・カバレッジを独立した視点で検証し、見落としを修正必須 / 任意改善として差し戻す。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | review-plan |
| description | 実装計画(plan.md)とチェックリストの影響範囲・カバレッジを独立した視点で検証し、見落としを修正必須 / 任意改善として差し戻す。 |
| allowed-tools | Bash, Read, Glob, Grep, Write, Edit |
/plan が作成した tmp/issues/<issue番号>/plan.md と checklist.html を独立視点でレビューし、影響範囲の見積もり漏れを検出する。$ARGUMENTS は issue 番号(123、#123)または URL。
/plan の手戻り原因として最大なのは「影響範囲の見落とし」。特にコードに直接現れない間接依存(DB trigger / イベント subscriber / scheduled job / 暗黙の必須セット等)を見落とすと、/test や /review で発覚して再計画ループになる。本スキルは plan を読むだけでなく 独立にコードベースを grep して検証 し、見落としがあれば差し戻す。
独立性について: 本スキルは /dev からはサブエージェント(plan 作成の文脈を持たない別コンテキスト)として実行される。それ自体が独立性の担保になっている。単独で(同一会話内で)実行される場合も、plan の主張を鵜呑みにせず必ず一次情報(コード)で検証すること。ユーザーへの質問はできない前提で動作し、判断に迷う場合は保守的(修正必須)に倒してその根拠を成果物に明記する。
このスキルのディレクトリにある config.json を読み込み、attentions 配列に記載されたプロジェクト固有の注意点を把握する。レビュー時にこれらの注意点が plan に反映されているか照合する。
tmp/issues/<issue番号>/plan.md と checklist.html を読み込む(md が無ければ plan.html。以降も同様)。plan が存在しない場合は呼び出し元にエラーを報告して終了。
tmp/issues/<issue番号>/research.md も読み込む(受け入れ条件・未確認の仮定・盲点候補の照合に使う。無ければ plan の「受け入れ条件カバレッジ」セクションから AC を取得)。
plan から以下を抽出する:
research.md の AC(または plan のカバレッジ表)に対して、以下を確認:
さらに checklist.html のカバレッジ も検証する:
カバーされていない AC や、明らかに検証不能なマッピング・項目は 修正必須 として扱う。
step 2 で抽出した各 identifier について、コードベース全体に対して文字列 grep を実行する。
検出した参照箇所が plan の影響範囲に含まれているか照合。
step 1 で読み込んだ各 attention について、plan の変更対象が該当するか判定する。
plan が変更対象として挙げた関数・型・コンポーネントについて、grep で参照元を確認し、plan が参照元の修正を漏らしていないか確認(既存の plan で大半はカバーされる想定)。
4-1〜4-3 の機械的検証は 既知の identifier・シンボルしか辿れない。それでは拾えない unknown unknowns を、観点チェックリストで plan を走査して探す:
research.md の「盲点候補」「未確認の仮定」が plan で対処・言及されているかも照合する。該当する懸念が実際にコード上の根拠を持つ場合のみ指摘する(観点を機械的に全部挙げない)。
検証結果を tmp/issues/<issue番号>/review-plan.md に書き出す(md が正。/dev と /plan はこちらを読む)。続けて同じ内容を人間用に review-plan.html としてレンダリングする(must / should / OK の色分け・<details> での検証根拠の折りたたみなどはこちらに)。
レイアウトや図表は内容に応じて自由に設計してよい(テンプレートは置かない)。ただし /dev や /plan がレビュー結果を判定できるよう、以下のセクションは md の見出し(##)として含めること(html も同構成にする)。
波及関係や影響範囲を図で示すと理解が早い場合は、Mermaid で依存グラフを追加してよい。
各指摘は以下のいずれかに分類:
/plan への差し戻し対象/plan への差し戻しが必要」と判定サブエージェントとして実行されている場合は、最終メッセージとして次を返す: 判定(OK / 差し戻し)、must / should / OK の件数、must の要旨(1 行ずつ)。詳細は review-plan.md / review-plan.html を参照するよう添える。
config.json の attentions は LLM が解釈する自然言語のメモ。形式判定せず、関連しそうなら積極的に照合するCodex CLI にコードレビューを依頼する。PR が存在する場合は PR を、ローカルブランチの場合はメインブランチとの差分をレビューする。
GitHub issue から PR のタイトルと説明文を作成する。
GitHub issue から計画・実装・テスト・レビュー・PR テキスト・理解確認まで一気通貫で行う。
GitHub issue と実装計画をもとにコードを実装する。計画からの逸脱は implementation-notes.md に記録しながら進める。
research の結果と受け入れ条件をもとに、実装方法を選択し TDD ベースの実装計画と動作確認チェックリストを作成する。
変更内容の解説(explainer)と理解確認クイズを生成する。マージ前に変更を理解しているか確かめたいとき、「この変更を説明して」「クイズを出して」「変更内容を理解したい」などの依頼で使う。