用 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 を消してください」と言うだけで自動化の提案がない）、ツールが存在しない自動化の提案。