القائمة
TDD を主張する実装の RED/GREEN/REFACTOR VERIFY 証跡（tdd-ledger）の妥当性を検査し、フェーズ順序・exitCode・test-cases との対応の欠落や偽装を検知する
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
استنادا إلى تصنيف SOC المهني
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/s977043/river-review --skill plangate-tdd-evidence-reviewيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
6つの専門レビュアーロールを並列実行し、consensusLevel（複数ロールの合意度）と Tech Lead レポート（top3指摘・blindSpots・consensusSummary）で結果を統合する マルチエージェントレビュー entry skill。 Parallel multi-role review with consensus scoring (consensusLevel) and Tech Lead report. Use when a major release needs exhaustive multi-angle review, or when a single-perspective review is not enough and you want confidence that no reviewer angle was missed（重要リリース前の網羅レビュー・多視点の確証が 欲しいとき）。
検査器（linter / ガード / CI ゲート / バリデータ / フィルタ）そのものの検出力が差分で静かに落ちていないか、また新設した検査が実際に検出できることが実証されているかを diff-time で検出する。Check 1 unverified detection reduction（検査器の検出ロジック（正規表現・除外パターン・解決集合・allowlist・baseline）を変更して検出件数が減ったのに、減った 1 件ずつが誤検出であった根拠が示されないまま「誤検出を潰した」「N → M 件に減少」と改善として主張している）、Check 2 unproven guard detection power（新しい検査ロジック・CI ゲート・バリデーションを追加・変更したのに、検出すべき入力を注入して検出されること／検出すべきでない入力で黙ることを示す変異注入の証跡が無く、「追加した」「CI が緑」を検出力の証拠として扱っている）、の 2 Check を対象とする report-only。テスト自身のアサーションが実質何も検証していない構造は test-assertion-effectiveness、レビュー基準・品質ゲートの明示的な弱体化（ルールの削除・閾値の引き下げ・suppression entry 追加・lint ルールの無効化）は review-criteria-integrity、リファクタ完了主張一般の検証は refactor-claim-audit、workflow の permissions と action pin は gha-workflow-security、設定ファイルの構文・型の妥当性は config-json へ委譲する
pbi-input, plan, todo, test-cases 間の整合性をチェックし、実装着手前の仕様漏れを検知する
| id | plangate-tdd-evidence |
| name | PlanGate TDD Evidence Review |
| description | TDD を主張する実装の RED/GREEN/REFACTOR VERIFY 証跡（tdd-ledger）の妥当性を検査し、フェーズ順序・exitCode・test-cases との対応の欠落や偽装を検知する |
| version | 0.1.0 |
| category | upstream |
| phase | upstream |
| applyTo | ["**/*"] |
| tags | ["plangate","tdd","evidence","verification","upstream"] |
| severity | major |
| inputContext | ["diff","repoConfig"] |
| outputKind | ["findings","summary","questions"] |
| modelHint | balanced |
Primary pattern: Reviewer
Secondary patterns: Inversion
Why: tdd-ledger のフェーズ別証跡を基準として妥当性を突き合わせる照合型レビューであり、必須 artifact（tdd-ledger）が揃わない場合は実行を止めるゲート（Inversion）も要する。
tdd-ledger に記録された RED/GREEN/REFACTOR VERIFY フェーズの証跡が妥当かを検査する。code-* 系 test scaffold skill の領域）。plangate-exec-conformance の領域）。plangate-verification-audit の領域）。このスキルは、以下の条件のいずれか 1 つでも満たされない場合に NO_REVIEW を返す（すべて満たされたときのみレビューを実行する）。
tdd-ledger が解決できているtdd-ledger に 1 つ以上の phases[] エントリが含まれているdiff が含まれ、レビュー対象の差分が空でないゲート不成立時の出力: NO_REVIEW: plangate-tdd-evidence — tdd-ledger artifact または差分が揃っていない
Gate と抑制条件の違い:
tdd-ledger が欠損していれば一切レビューしない）。refactor_verify は refactor が行われた場合のみ必須。リファクタを伴わない差分での欠如は指摘しない。[q] で確認する（推測で「偽装」と断定しない）。抑制時の出力: 該当する指摘を出力しない（黙る）。
tdd-ledger.json の phases[] を読み、各フェーズの妥当性を次のルールで検査する。
tdd_red フェーズが存在するか確認する。tdd_red は exitCode != 0（テストが先に失敗した）であること。exitCode == 0 は「RED が偶然 pass」= 偽の RED として指摘する。conclusion が、期待された失敗（対象機能の未実装）を説明しているか確認する。無関係なランタイムエラー・import 失敗での失敗は無効な RED として指摘する。tdd_green フェーズが存在し exitCode == 0 であること。tdd_green の対象が tdd_red と同じ挙動（同じ testCaseRefs / コマンド）を指しているか確認する。RED と無関係な GREEN は指摘する。refactor_verify（exitCode == 0）が存在するか確認する。verification フェーズが記録されている場合は exitCode == 0 であることを確認する。exitCode != 0 は最終検証の失敗として指摘する。verification は RED/GREEN を置き換えない。verification のみが存在し tdd_red / tdd_green を欠く場合は missing-tdd-red / missing-tdd-green の対象とする。phases[].testCaseRefs が test-cases artifact のケース ID に対応づくか確認する。対応づかない証跡は tdd-evidence-not-linked-to-test-case として指摘する。test-cases の受入挙動に対し、テストが mock のみを検証してビジネス境界を見ていないと読み取れる場合は指摘する。[q] として質問形式で返す。各指摘には、追跡しやすさのため次の finding-id を [id=...] として付与してよい（任意。出力形式は <file>:<line>: <message> を維持する）。
| finding-id | 意味 | 既定 severity |
|---|---|---|
missing-tdd-red | TDD が要求されるが RED 証跡が無い | warning |
invalid-tdd-red | RED が pass している、または無関係な理由で失敗している | warning |
missing-tdd-green | 実装後に GREEN 証跡が無い | warning |
missing-refactor-verify | リファクタが行われたが refactor 後の検証が無い | nit / warning |
tdd-evidence-not-linked-to-test-case | 証跡を計画した test case に対応づけられない | warning |
test-does-not-cover-acceptance-criteria | テストはあるが約束した受入挙動を検証しない | warning |
各 finding の既定 severity は warning だが、TDD が必須要件として宣言された変更で tdd_red と tdd_green の両証跡が完全に欠落する場合は blocker にエスカレーションする（下記 Output の severity ガイド参照）。
tdd-ledger の該当 phases[] エントリ（phase / exitCode / command）と、対応する test-cases のケース ID をペアで示す。review-core ルール遵守）。<file>:<line>: <message> 形式。ledger を指す場合は tdd-ledger.json:<1 始まりのフェーズ番号>（例: 2 番目のフェーズなら tdd-ledger.json:2）を疑似ロケーションとして用いる。<line> は必ず整数にする（パーサが行番号を整数として解釈するため、フェーズ名などの文字列を入れない）。blocker|warning|nit を使用し、スキーマ側 critical|major|minor|info への変換は review-core ルールに委ねる。分類ガイド:
blocker: TDD が必須要件として宣言された変更で RED/GREEN 証跡が完全に欠落。warning: 偽の RED（pass）、GREEN 欠落、test-case 未対応、受入挙動の未検証。nit: refactor_verify の軽微な欠如など。(summary):1: RED <件数> / GREEN <件数> / refactor <件数> / test対応 <件数> / 質問 <件数>[id=<finding-id>] を付ける。tdd-ledger: <phase>(exitCode=...) と test-cases: <ケース ID>。(questions):1: [q] <確認したいこと> 形式で 1 件 1 行。tdd-ledger の契約plangate-exec-conformance（plan/todo/test-cases と差分の整合）plangate-verification-audit（既存レビュー文書の W チェック）tdd-ledger の生成元（producer）についてtdd-ledger artifact は River Review が読み取る consumer 入力であり、River Review 自身は生成しない（findings-pool と同じ consumer-first パターン）。生成は PlanGate などの上流ワークフロー（例: PlanGate の evidence-ledger）が exec 中に担う想定である。
したがって PlanGate 等の producer を併用しない River Review 単体の adopter では、tdd-ledger が供給されないため本スキルは常に NO_REVIEW を返す（Pre-execution Gate 不成立）。これは設計上の意図であり欠陥ではない。producer を実装・接続する際は、書き出す tdd-ledger.json の形式を本スキルの Gate（phases[] ≥ 1）および pages/reference/artifact-input-contract.md の tdd-ledger 節と必ず突き合わせること。