القائمة
Detect review findings that belong in CI/lint/formatter rather than human review.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/s977043/river-review --skill review-automation-boundary-guardيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
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 間の整合性をチェックし、実装着手前の仕様漏れを検知する
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| id | review-automation-boundary |
| name | Review Automation Boundary Guard |
| description | Detect review findings that belong in CI/lint/formatter rather than human review. |
| version | 0.1.0 |
| category | midstream |
| phase | midstream |
| applyTo | ["**/*"] |
| tags | ["review-process","automation","ci","meta-review","midstream"] |
| severity | minor |
| inputContext | ["diff"] |
| outputKind | ["findings","actions","metrics"] |
| modelHint | balanced |
Primary pattern: Reviewer Secondary patterns: Inversion Why: 自動化可能なレビュー指摘を検出しCI/lint委譲を提案するが、コード変更を含まない差分では実行不要
外部実証: 「コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった」（井本 賢, 2026-07-04）は、実際に効果があった指摘は Bug/Spec 系のみだったと報告する。Style/Naming/Refactor/Arch 系は効果が低く自動化・前倒しに適するという結果は、本スキルの方針を裏付ける一次データとして参照できる。
外部実証（続報）: 「AIレビューのブロックを100PRで測ったら、70PRはno-verifyで通り抜けていた」（井本 賢, 2026-07-23）は、100 PR の実測で pre-commit hook のブロックのうち 70% が --no-verify で回避されていたと報告します。強制ゲートの守備範囲を「壊れて動かないコード」（構文エラー・smoke test 失敗）へ絞り、lint / 型 / スタイルの判定を AI レビュー側へ移したところ、ブロック後の修正率は 30% から 83% へ改善しました。この前後比較も、本スキルの方針を裏付ける一次データとして参照できます。
このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。
.eslintrc, .prettierrc, tsconfig.json等）のみの変更ではないゲート不成立時の出力: NO_REVIEW: review-automation-boundary — 自動化境界レビューの対象となるソースコード変更が検出されない
console.log の残留、コメントアウトコード等）が含まれる場合、対応する lint ルールの追加を促す。naming-convention ルール等）の追加を促す。<file>:<line> で追える内容）。<file>:<line>: <message> 形式。コメントは日本語で返す。
自動化カテゴリごとに集約して出力する（同じパターンが複数箇所にある場合は件数を添える）。
例:
src/api.ts:23: console.log が 3 箇所残留。レビューでの指摘は属人的。Fix: ESLint no-console: error を追加し CI で強制prettier / gofmt / black 等のフォーマッタで自動修正可能なものconsole.log / console.error のまま残ったデバッグ出力（no-console ルール）no-unused-vars, @typescript-eslint/no-unused-vars）no-magic-numbers ルール）max-depth ルール）注: このレベルではanyや!のコード品質上の問題を指摘しない（それはtypescript-strict / typescript-nullcheckのスコープ）。ここでは「そのルールがCIで強制されていない」というプロセスの不備のみを指摘し、ツール設定の追加を提案する。
any の使用（@typescript-eslint/no-explicit-any でゼロトレランスにできる）! の使用（@typescript-eslint/no-non-null-assertion）import/order, simple-import-sort ルール）Bad（人間レビューで指摘）: 「インデントが 2 スペースではなく 4 スペースになっています」
Good（自動化）: prettier --write . を CI に組み込み、フォーマット差分は PR マージブロックにする。
Bad（人間レビューで指摘）: 「console.log が残っています」
Good（自動化）: ESLint の no-console ルールを error にし、CI で強制する。
Bad（人間レビューで指摘）: 「any を使っています」
Good（自動化）: @typescript-eslint/no-explicit-any: error と tsconfig.json の strict: true を CI で強制する。
.prettierrc / .editorconfig の導入と CI への format:check ステップ追加を提案する。tsconfig.json の strict オプション名と対応する ESLint ルール名を提示する。automation_debtメトリクスとして出力する。{ "automation_debt": <integer> }をメトリクスブロックのトップレベルキーとして返す。値は検出パターン数の合計。console.log を消してください」と言うだけで自動化の提案がない）、ツールが存在しない自動化の提案。