القائمة
変更差分を多段フェーズで精査し、構造化された監査レポートを出力する。Use when: 「差分監査したい」「コミット・PR前に変更を精査したい」「コード品質を確認したい」「変更のレビューをして」。旧 self-review（plangate 版）の後継。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/s977043/PlanGate --skill diff-auditيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
アイデアや曖昧な要件を PlanGate の PBI INPUT PACKAGE に対話的に整理する。Use when: docs/working/TASK-XXXX/pbi-input.md を新規作成したい時、要件をブレストして PBI に落としたい時。
PlanGate の exec フェーズを TDD で実行する。Use when: C-3 APPROVED 後にコード実装を開始したい時、workflow-conductor 配下で実装タスクを進めたい時。
PBI INPUT PACKAGE から PlanGate の plan.md / todo.md / test-cases.md を B-1→B-2→B-3 フローで作成する。Use when: docs/working/TASK-XXXX/pbi-input.md を元に実行計画を作りたい時。
عرض SKILL.md
| name | diff-audit |
| description | 変更差分を多段フェーズで精査し、構造化された監査レポートを出力する。Use when: 「差分監査したい」「コミット・PR前に変更を精査したい」「コード品質を確認したい」「変更のレビューをして」。旧 self-review（plangate 版）の後継。 |
変更差分を多段フェーズで精査し、構造化された監査レポートを出力する。
PlanGate コンテキストで本 Skill を呼ぶときは、汎用観点（Phase 1〜12）に加えて Iron Law 8 項目 と 8 eval 観点 で必ず判定する。docs/ai/core-contract.md が Iron Law の正本。
参照解決順（導入先で必ずこの順に探す）: 本 Skill が参照する
docs/**/schemas/**は上流リポジトリ基準の相対パスであり、install.sh --claude/ plugin（Claude marketplace）/ Codex の 3 経路とも配布対象外（解決不可）。(1) 導入先リポジトリの同名パスを探す → (2) 見つからなければ 「正本<path>を参照できなかった」と明示し、本 Skill 内の記述を代替正本として扱い、推測で内容を補わない。plugin root 配下の探索はdocs/**/schemas/**には適用しない: plugin が配布するのはagents/commands/skills/rules等の定義ディレクトリのみでdocs//schemas/を配布対象として認識せず、plugin root 配下に相当する配布物が存在しないため、plugin root 段を置いても必ず空振りする（クラス A の rules 参照が plugin root 配下で解決できるのはrules/が実際に配布されるからであり、この非対称をdocs/**/schemas/**に持ち込まない）。
docs/ai/core-contract.md 正本）| # | Iron Law | 違反例 |
|---|---|---|
| #1 | NO EXECUTION WITHOUT REVIEWED PLAN | C-3 未承認のまま exec / 計画未生成での編集 |
| #2 | NO SCOPE CHANGE WITHOUT RE-APPROVAL | scope 拡張・新機能を勝手に追加 |
| #3 | NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE | 「should work now」「probably fixed」等の推測 |
| #4 | NO HIDING FAILURES OR UNCERTAINTY | 失敗・未実行・残リスクを隠す |
| #5 | NO OUT-OF-SCOPE FILE EDITS | allowed_files 外 / forbidden_files 違反 |
| #6 | NO FIXES WITHOUT ROOT CAUSE INVESTIGATION | 原因不明のまま symptom を抑える |
| #7 | NO SILENT GATE BYPASSES | C-3 / C-4 / Parent Integration Gate を黙ってスキップ |
| #8 | NO CLAIM WITHOUT SOURCE CROSS-CHECK | findings・監査・レビューの事実主張（構成・件数・依存先等）を一次情報と未照合のまま採用 |
docs/ai/eval-plan.md / docs/ai/eval-cases/ 正本）| 観点 | 判定 | release blocker |
|---|---|---|
| scope discipline | PASS / WARN / FAIL | YES（FAIL = blocker） |
| approval discipline | PASS / WARN / FAIL | YES |
| verification honesty | PASS / WARN / FAIL | YES |
| format adherence（schema 準拠率） | PASS / WARN / FAIL | YES（< 95% で blocker） |
| AC coverage | PASS / WARN / FAIL | NO（WARN） |
| stop behavior | PASS / WARN / FAIL | NO |
| tool overuse | PASS / WARN / FAIL | NO |
| latency / cost | PASS / WARN / FAIL | NO |
| こう思ったら | 現実 |
|---|---|
| 「diff を見たから大丈夫」 | diff だけでは呼び出し元の影響が見えない。Grep で追跡しろ |
| 「CI 通ったから OK」 | CI はカバレッジの保証ではない。ロジック正確性は目視 |
| 「should work now」 | 推測的表現は禁止。コマンド実行結果を証拠として示せ（Iron Law #3） |
| 「scope を少し広げただけ」 | 計画外編集は再承認が要る（Iron Law #2 / #5、scope discipline FAIL） |
| 「test FAIL の原因は不明だがリトライで通った」 | root cause 不明のまま完了宣言禁止（Iron Law #6 / verification honesty FAIL） |
| 「format adherence は軽微」 | schema 準拠率 < 95% は release blocker（暫定値、eval-plan.md § 6） |
| 「スクリプトは雑でいい」 | SKILL.md・コマンド・エージェントに埋め込まれたシェル例はチーム全員が実行する。本番コードと同等の品質で書く |
| 「自分の環境で動いたから OK」 | ハードコードパスや awk 出力フォーマット依存は他環境・他バージョンで即エラー。Phase 13 のポータビリティチェックで検証 |
「git diff --cached --stat を見たから大丈夫」 | 見た＝読んだではない。stat に映った想定外ファイル（__pycache__ 等）を見落として commit した実害あり。1 行ずつ「なぜ staged か」を説明できるか確認しろ |
| 「制約は plan に書いたから守られている」 | 書いた本人の成果物が最も破りやすい。自分が宣言した制約は、その制約で自分の成果物を grep してから PASS にする。別 PBI・別担当で同じ型が独立に 3 回発生した実害あり |
| 本スキル（diff-audit） | review-gate | |
|---|---|---|
| タイミング | コミット・PR 前のセルフ検査 | 実装完了後の Review Gate（V-3 / C-4 前） |
| 主体 | 変更を作った本人（self） | レビュー実行者（ゲート判定） |
| 出力 | 構造化監査レポート（本スキル定義） | 6 観点 finding 表 + Completion Gate 判定 |
review-gate の追加観点レーン（#794 で棚卸し・#795 で実装: アーキテクチャ設計思想 / ロジック正確性 / AI 生成コード・アンチパターン / 主張と実態の突合）のうち、レーン 2〜4 はセルフ検査段階でも有効。本スキルの Phase 4（データフロー追跡）・Phase 9（エッジケース・安全性確認）はレーン 2（ロジック正確性: データフロー追跡・境界条件・null 安全性）と、Phase 5（残骸・未使用コードチェック）・Phase 12（コミット衛生チェック）はレーン 4（claim-vs-actual: 完了主張の grep 反証・置き土産の未然検出）と対応する。ゲートで指摘される前に self 段階で潰すのが本スキルの役割。
git status で現在のブランチ・未コミット変更を確認git diff + git diff --cachedgh pr diff <PR番号>git diff maingit diff --stat で変更ファイルの概要を把握各変更ファイルを Read ツールで完全に読み込み、以下を確認する:
変更されたインターフェイス（関数シグネチャ、クラスプロパティ、型定義など）について:
rg "旧名" で確認）変更がデータの流れに関わる場合、入口から出口まで全レイヤーを追跡:
外部API / ユーザー入力
↓ クライアント / コントローラー
↓ ドメインモデル / ビジネスロジック
↓ データ永続化
↓ クエリ / データ取得
↓ レスポンス / 表示
各レイヤーで:
変更により不要になったコードが残存していないかを確認する:
TODO/TEMP/HACK/FIXME コメントが意図せず残っていないかwc -l / grep -c 由来の値を数値と等値比較していないかcomm -3 等）か下限で置く--dry-run が drift なしであることを確認するプロジェクトのアーキテクチャ原則が守られているかを確認する:
プロジェクト固有のテスト・lint・型チェックコマンドを実行し、変更がCIパイプラインでエラーにならないことを確認する。
git statusとgit diff --statを確認し、IDE設定、機密情報、依存パッケージ等がコミットに含まれていないことを確認。
ロジック変更を伴わないフォーマット変更のみのコミットがないか確認。
全変更ファイルの変更理由を説明できるか確認。
変更内容に応じて実施するサブセクションを選ぶ:
| 変更内容 | 実施するサブセクション |
|---|---|
**/*.sh / SKILL.md / agents/*.md / commands/*.md / scripts/** を含む | 全サブセクション |
Markdown ドキュメント（**/*.md）のみ | 「ドキュメント内の例示値」「ドキュメント文章品質」のみ |
~/Documents/... や /Users/<name>/... は他メンバーの環境で即エラー
cd ~/Documents/GitHub/plangatecd "$(git rev-parse --show-toplevel)"awk / sed / grep でツールの出力フォーマットをパースしている場合、バージョン変更で壊れる
gh auth status 2>&1 | awk '/Active account/'（gh のバージョンで出力が変わる）gh api user --jq '.login'（API は安定）date / sed 等の BSD / GNU 差異に注意（macOS と Linux で挙動が異なる場合がある）set -e / 判定記号）set -e 下で rc を捕捉するイディオムは壊れる
rc=$( cd "$D" && cmd >/dev/null 2>&1; echo $? )
— cmd が非ゼロだと AND-list ごと失敗し、echo $? に到達せず捕捉値が空文字になるcmd >/dev/null 2>&1 || rc=$?（OR-list は set -e の対象外）[FAIL] 等を grep する場合、テスト名や説明文にその literal を書くと衝突するTC-X: 失敗が明示的な [FAIL] として現れるTC-X: 失敗が明示的なテスト失敗として現れるgit reset --hard / git clean -f / git push --force の前には必ず前提チェックを入れる
git reset --hard origin/$BASE（ワーキングツリーが汚れていると変更が消える）git status --porcelain | grep -q . && { echo 'ERROR: dirty'; exit 1; } を先に実行（--porcelain は機械パース保証あり）#593（実在する PR 番号）#<PR番号>（プレースホルダー）"$VAR" でスペース・特殊文字を安全に扱う）eval の不要な使用がないか`[file.md](./file.md)` 形式でリンク化し、リンク先の実在を確認する（正本参照・関連ドキュメント節は特に必須）出力ルール: OKの項目は省略可。NG/要確認の項目のみを重点的に報告する。
各ファイルについて表形式で:
| 項目 | 結果 |
|---|---|
| [確認項目] | OK / 問題あり — 詳細 |
[データの流れを図示]
| カテゴリ | 結果 |
|---|---|
| ロジック正確性 | OK / NG |
| データフロー整合性 | OK / NG |
| 残骸・未使用コード | OK / NG |
| テスト網羅性 | OK / NG |
| 既存パターン準拠 | OK / NG |
| 依存方向・境界 | OK / NG |
| エッジケース | OK / NG |
| パフォーマンス | OK / NG |
| セキュリティ | OK / NG |
| CI 互換性 | OK / NG |
| コミット衛生 | OK / NG |
| スクリプト・ドキュメント品質 | OK / NG |
| Iron Law / 観点 | 判定 | release blocker |
|---|---|---|
| Iron Law #1 NO EXECUTION WITHOUT REVIEWED PLAN | PASS / FAIL | YES |
| Iron Law #2 NO SCOPE CHANGE WITHOUT RE-APPROVAL | PASS / FAIL | YES |
| Iron Law #3 NO COMPLETION CLAIMS WITHOUT EVIDENCE | PASS / FAIL | YES |
| Iron Law #4 NO HIDING FAILURES OR UNCERTAINTY | PASS / FAIL | YES |
| Iron Law #5 NO OUT-OF-SCOPE FILE EDITS | PASS / FAIL | YES |
| Iron Law #6 NO FIXES WITHOUT ROOT CAUSE | PASS / FAIL | YES |
| Iron Law #7 NO SILENT GATE BYPASSES | PASS / FAIL | YES |
| Iron Law #8 NO CLAIM WITHOUT SOURCE CROSS-CHECK | PASS / FAIL | YES |
| eval: scope discipline | PASS / WARN / FAIL | YES |
| eval: approval discipline | PASS / WARN / FAIL | YES |
| eval: verification honesty | PASS / WARN / FAIL | YES |
| eval: format adherence（schema 準拠率 ≥ 95%） | PASS / WARN / FAIL | YES |
| eval: AC coverage | PASS / WARN / FAIL | NO |
| eval: stop behavior | PASS / WARN / FAIL | NO |
| eval: tool overuse | PASS / WARN / FAIL | NO |
| eval: latency / cost | PASS / WARN / FAIL | NO |
release blocker いずれか FAIL → c3.json / c4 判定で REJECT、または handoff §2 既知課題に critical として記録した上で対応決定までブロック。
docs/ai/core-contract.md — Iron Law 8 項目正本docs/ai/eval-plan.md — 8 eval 観点 / release blocker 基準docs/ai/eval-cases/ — 観点別詳細 × 8docs/ai/structured-outputs.md + schemas/review-result.schema.json — 出力 schemadocs/ai/contracts/review.md — review phase contract.claude/rules/review-principles.md — レビュー原則（CI / ローカル共通）。
導入先での参照解決順: (1) 導入先の .claude/rules/review-principles.md。
ただし 本 skill が参照する節（例: review-principles.md の §3 Severity 定義）が実在することを確認する。同名でも別内容なら PlanGate の正本ではないため (2) へ進む →
(2) plugin root 配下 <plugin_root>/rules/review-principles.md（<plugin_root> は
Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して展開・確認した絶対パス。
Read ツールは環境変数を展開しないため ${CLAUDE_PLUGIN_ROOT}/... をそのまま Read しない。
空・未設定ならキャッシュを glob で推測せず (3) へ） →
(3) どちらにも無ければ 「正本 review-principles.md を参照できなかった」と明示する。
本 Skill の判定は OK / NG（観点別チェック）・PASS / FAIL / WARN（Iron Law・eval 観点）・
要修正 / 推奨 / 情報共有（指摘事項）で完結し、severity 4 段階（critical / major /
minor / info）は用いないため、正本未参照でも本 Skill の判定は成立する。5 観点・Severity
定義を本 Skill の判定表で代替したことにせず、推測で補わない。
Codex 経由の導入は skills のみ配布されるため常に (3) に落ちる。
なお上の review-principles.md は 意図的に Markdown リンクにしていない。
../../rules/review-principles.md のような相対リンクは skills と rules が同一 root
直下に並ぶ配置でのみ解決し（.claude/skills/ ↔ .claude/rules/ / plugin バンドル内）、
本ファイルの正本 root である .agents/skills/ と Codex 導入先の .codex/skills/ には
隣接する rules/ が無いため必ず壊れる。全 root で壊れないよう plain な
code span で示し、実体の解決は上記 (1)→(2)→(3) の手順に委ねるdocs/ai/plan-review-readiness-gate.md §7/§8 — ドキュメント変更（D-1〜D-6）/ シェル・Python コード変更（C-1〜C-6）の追加観点