code-reviewlisted

# コードレビュー支援スキル ## 1. 入力 - レビュー対象：PR URL / 差分 / 単一ファイル / 複数ファイル - コンテキスト（あれば）：関連 Ticket · 設計書 · 規約遵守する言語 ## 2. 手順 ### Step 1：コンテキストの把握 1. PR Description · Ticket · 関連設計書を確認。 2. 影響範囲（モジュール · DB · 外部 I/F · 後方互換性）を把握。 3. 言語別コーディング規約（[`/docs/30-standards/coding/`](../../docs/30-standards/coding/)）を該当言語のみ参照。 ### Step 2：観点別レビュー（① → ② → ③ → ④） [`/docs/30-standards/code-review.md`](../../docs/30-standards/code-review.md) §2〜§5 のチェックリストを 1 項目ずつ通す。 #### ① 正しさ - 仕様遵守（受入基準 · 設計書） - 境界値（0 · 空 · null · 最大 · オーバーフロー） - 異常系（例外 · タイムアウト · リトライ · 部分失敗） - 並行性（競合 · デッドロック · データ競合） - 副作用 · 後方互換 · 国際化 · タイムゾーン #### ② 安全性 - 認証 · 認可 - 入力検証（SQLi · XSS · CSRF · Path Traversal · Command Injection · LDAP · XML · SSRF） - Secret · PII の取扱 - 暗号化 · 監査ログ · エラー情報露出 - 依存ライブラリの既知脆弱性 #### ③ 保守性 - 命名 · 関数粒度 · クラス粒度 - コメント（why が書かれているか） - マジックナンバー · 文字列の定数化 - DRY · テスト容易性 · テストの質 - ドキュメント · TODO 残 #### ④ パフォーマンス - 計算量（O(n²) 以上） - DB N+1 · 不要 JOIN · インデックス - 同期 I/O 混入 · 大容量メモリ展開 - キャッシュ · ログ過多 ### Step 3：指摘の出力 各指摘に **強さラベル** を付ける： - `[must]` マージ前に必ず修正。 - `[should]` 強く推奨。修正不可なら理由を返答。 - `[nit]` 好みレベル。次回以降でも可。 ### Step 4：総評 - **総評**：3〜5 行で全体の品質感、merge 可否の所感。 - **推奨アクション**： - 即修正：箇条書き - 議論要：箇条書き（Ticket 化推奨） - 別 PR で対応：箇条書き ## 3. 出力フォーマット例 ```markdown ## レビ��ー総評 （3〜5 行） ## 即修正（must） - [ ] file.ts:42 — 入力 `email` の null チェックが抜けている。`if (!email) return ...` を追加。 - [ ] file.ts:88 — エラー時に Secret がログに出ている。マスキングまたは出力削除。 ## 強く推奨（should） - [ ] service.ts — 3 つの責務を持つ。`validate`, `transform`, `persist` に分割。