review-automation-boundary-guard

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

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 自動化可能なレビュー指摘を検出しCI/lint委譲を提案するが、コード変更を含まない差分では実行不要

Goal / 目的

• レビュー指摘の中から「自動化できるはずの指摘」を検出し、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% へ改善しました。この前後比較も、本スキルの方針を裏付ける一次データとして参照できます。

Non-goals / 扱わないこと

• 自動化できない判断（設計方針、セキュリティ上のトレードオフ、仕様の解釈）への言及。
• 実際のコード修正の提案（このスキルはツール設定の提案のみを行う）。
• プロジェクトのスタイルガイドや規約そのものの是非を評価すること。
• 既に CI に設定が存在するルールへの重複指摘。

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。

• 差分にソースコード（テスト/フィクスチャのみでない）の変更が含まれている
• 差分がツール設定ファイル（.eslintrc, .prettierrc, tsconfig.json等）のみの変更ではない
• inputContextにdiffが含まれている

ゲート不成立時の出力: NO_REVIEW: review-automation-boundary — 自動化境界レビューの対象となるソースコード変更が検出されない

False-positive guards / 抑制条件

• 差分内に該当ツールの設定ファイル変更が含まれている場合、そのルールは追加中と判断し指摘しない。差分外のリポジトリ設定は確認できないため、断定ではなく「設定がなければ」という条件付きで提案する。
• マイグレーションや一時的な移行期であることが PR 説明から明確な場合は抑制する。

Rule / ルール

• 差分に「フォーマッタで自動修正できるはずのパターン」（インデント、末尾スペース、クォートスタイル等）が含まれる場合、CI へのフォーマッタ追加を促す。
• 差分に「lint ルールで自動検出できるはずのパターン」（未使用変数、console.log の残留、コメントアウトコード等）が含まれる場合、対応する lint ルールの追加を促す。
• 差分に「命名規則の逸脱」が含まれる場合、命名規則チェッカー（ESLint の naming-convention ルール等）の追加を促す。
• import 順序の乱れ、ファイル末尾改行の欠如など、ツールで強制できる規約の逸脱を見つけた場合、人間レビューで指摘するのではなくツール設定を提案する。

Evidence / 根拠の取り方

• 指摘は差分に紐づける（<file>:<line> で追える内容）。
• 自動化提案には具体的なツール名とルール名を添える。
• 推測を断定しない（不確実なら "可能性" として書く）。