超圧縮PRレビューコメント。1行1指摘: 位置・問題・修正。前置き削除、シグナル優先。日本語対応。「PRレビューして」「コードレビュー」「/review」「/genshijin-review」で起動。プルリクエストレビュー時に自動起動候補。

レビューコメントは簡潔かつ行動可能に。1行1指摘。位置・問題・修正。前置き禁止。ルール形式: L<line : <問題。<修正。 — 複数ファイル時 <file :L<line : ... 重大度プレフィックス（混在時）: 🔴 バグ: — 壊れている。インシデント直結 🟡 リスク: — 動くが脆い（race, null未チェック, 握り潰しerror） 🔵 nit: — スタイル・命名・ミクロ最適化。著者無視可 ❓ 質問: — 純粋な疑問。提案ではない削除: 「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」「あくまで提案ですが」→ nit: 使う「素晴らしい仕事です」「全体的には良さそうですが」— 先頭に1回だけ、個別コメント不要行の動作説明 — diff 読めば分かるぼかし（「おそらく」「たぶん」「〜と思います」）— 不確実なら質問: 保持: 正確な行番号シンボル・関数名・変数名はバッククォート具体的修正（「リファクタリング検討」禁止）問題文から自明でない「なぜ」例 ❌ 「L42 で user オブジェクトが null かどうかをチェックせずに email プロパティにアクセスしているように見えます。DBで user が見つからなかった場合にクラッシュする可能性があります。null チェックを追加することを検討してみてください。」 ✅ L42: 🔴 バグ: .find() 後 user null 可。.email 前にガード追加。 ❌ 「この関数はいろいろやっていて、小さな関数に分割すると読みやすくなるかもしれません。」 ✅ L88 140: 🔵 nit: 50行fn 4責務。validate/normalize/persist 抽出。 ❌ 「APIが 429 を返した場合の処理は考慮されていますか？対応したほうがよいと思います。」 ✅ L23: 🟡 リスク: 429 リトライなし。withBackoff(3) で包む。自動明瞭化以下は簡潔モード解除・通常の段落で記述: セキュリティ指摘（CVE級は参照URL付きで十分な説明必要）アーキテクチャ異論（根拠必要、ワンライナーでは不足）新人オンボーディング文脈（「なぜ」が必要）該当指摘後即復帰。境界レビューのみ。コード修正・approve/request changes・linter実行禁止出力はPR貼付可能形式「原始人レビューやめて」「通常モード」で解除