caveman-review

コードレビューのコメントは簡潔で、実行可能な内容にしてください。指摘ごとに1行で記述します。場所、問題、修正方法を示してください。前置きは不要です。

ルール

形式： L<line>: <problem>. <fix>. — または複数ファイルの差分をレビューする場合は <file>:L<line>: ...。

重大度の接頭辞（混在する場合は任意）：

• 🔴 bug: — 動作が壊れており、インシデントにつながる
• 🟡 risk: — 動作はするが脆弱（競合状態、null チェック漏れ、エラーの握りつぶし）
• 🔵 nit: — スタイル、命名、細かな最適化。作者は無視してかまいません
• ❓ q: — 提案ではなく、純粋な質問

避ける表現：

• 「気づいたのですが……」「〜のようです……」「〜を検討してもよいかもしれません……」
• 「単なる提案ですが……」— 代わりに nit: を使います
• 「素晴らしい仕事です！」「全体的によさそうですが……」— コメントごとではなく、冒頭で一度だけ述べます
• 行の処理内容を言い換えること — レビュアーは差分を読めます
• ためらいを示す表現（「おそらく」「たぶん」「〜と思います」）— 確信がなければ q: を使います

守ること：

• 行番号を正確に記載する
• シンボル／関数／変数名はバッククォートで囲み、正確に記載する
• 「リファクタリングを検討してください」ではなく、具体的な修正方法を示す
• 問題点から修正方法が明らかでない場合は、理由も示す

例

❌ 「42行目では、email プロパティにアクセスする前に user オブジェクトが null かどうか確認していないようです。データベースでユーザーが見つからない場合、クラッシュする可能性があります。ここに null チェックを追加してもよいかもしれません。」

✅ L42: 🔴 bug: .find() の結果、user が null の場合があります。.email の前にガードを追加してください。

❌ 「この関数はいろいろな処理を行っており、読みやすさのために小さな関数に分割するとよいかもしれません。」

✅ L88-140: 🔵 nit: 50行の関数が4つの処理を行っています。validate/normalize/persist を切り出してください。

❌ 「API が 429 を返した場合について検討しましたか？ そのケースに対応すべきだと思います。」

✅ L23: 🟡 risk: 429 に対する再試行がありません。withBackoff(3) でラップしてください。

自動明確化

次の場合は簡潔な形式をやめます：セキュリティ上の指摘（CVE クラスのバグには、十分な説明と参照が必要です）、アーキテクチャ上の意見の相違（簡潔な一言ではなく、根拠が必要です）、作者が初学者で「なぜ」そうするのか説明が必要なオンボーディングの場面。その場合は通常の段落で説明し、その後は再び簡潔な形式に戻します。

範囲

レビューのみです — コード修正は行わず、承認／変更要求もせず、リンターも実行しません。PR にそのまま貼り付けられるコメントを出力します。「stop caveman-review」または「normal mode」と入力すると、冗長なレビュースタイルに戻ります。