duck-review

🦆 レビュー。デフォルトでは簡潔で、すぐに対応できる形式にします。

目的

変更されたコードを、リスクの高い順に、貼り付けてすぐに使える形式で、具体的な修正案とともにレビューします。

哲学上のガードレール（スキル固有）

共有ガードレールは references/GUARDRAILS.md を継承します。

コメントとドキュメントの整合性

• 長期的に有効な制約、不変条件、契約、動作を記述します。
• コードコメントや通常のドキュメントで開発の経緯を説明しないでください。
• 変更の作成過程を説明するだけの、却下されたアプローチ、「以前はこうだった」という説明、直近の変更に関する文脈、レビュー、テスト、セッションへの言及は削除するか、問題として指摘してください。
• セッション限定の決定、承認フラグ、一時的なマーカーを、長期的に保持する成果物に残さないでください。
• 履歴は、ADR や変更履歴など、履歴を記録するための長期的な成果物にのみ残してください。
• テストやレビューへの言及は、長期的に有効な制約または検証要件を示す場合に限り残してください。

スキル固有の追加事項：

• 指摘と修正方針を提示し、マージや承認の判断はユーザーに委ねます。

有効化

ユーザーが問題や修正方針を確認するために、差分、コード、PR のレビューを依頼した場合に使用します。

方法

1. 文脈を明確にする（曖昧な場合）

• 文脈が不十分な場合は、的を絞った確認質問を1～3つ行います。

• 根拠が不足している場合は、前提を明示します。

• レビューの文脈が曖昧な場合は、まず的を絞った確認質問を1つ行います。

• 各指摘を、差分やコードの明確な根拠に紐づけます。

2. Duck Ladder を適用する（複雑さの抑制）

修正方針を提案する際は、最初に該当する段階で止めます。

1. 変更不要（YAGNI）
2. 既存のローカルヘルパーやパターンを再利用する
3. 標準ライブラリやネイティブ機能に置き換える
4. すでにインストールされている依存関係を使う
5. 最小限で安全な差分に縮小する
6. その後に限り、新しいコードや抽象化を追加する

3. レビューワークフロー

1. レビュー対象があることを確認します（差分、PR の説明、または貼り付けられたコード）。ない場合は、具体的なレビュー対象を求めます。
2. 次の優先順位で確認します：セキュリティ -> 正確性 -> データ整合性 -> パフォーマンス -> テスト -> ドキュメント -> 簡素化。
3. 対応可能な指摘のみ出力します。各指摘は1行で、場所、問題、修正方針を示します。
4. 該当する中で最も強いプレフィックスを使います。複数該当する場合は、最もリスクの高いものを選びます。
5. 出力形式を厳守します。すべての指摘を、1行のプレフィックス付きコメントテンプレートにします。
6. セキュリティまたは取り返しのつかないリスクに関する指摘では、段落形式（Auto-Clarity）に切り替え、その後は簡潔なコメントに戻します。
7. 大規模なリファクタリングでは、影響の大きい指摘を優先し、細かな指摘を並べないでください。
8. 指摘に確信が持てない場合は、確かな事実を捏造せず、確認質問を1つ行います。
9. 同じ行に複数の問題がある場合は、修正方法が異なれば別々のコメントに分けます。

コメントやドキュメントをレビューする際、長期的に有効な制約ではなく開発の経緯を説明している記述は、📝 doc: として指摘します。

プレフィックスの選択が曖昧な場合や、コメントの表現例が必要な場合は、references/review-comment-examples.md を読み込みます。

4. 指摘事項の出力

1 行コメントのテンプレート：

<prefix> <path[:line]> — <problem>. Fix: <smallest safe change>.

PR スレッドにそのまま貼り付けられるコメントにしてください。

ルール（スキーマ優先、文章は柔軟に）：

• 各指摘事項の行は、承認済みのプレフィックストークンで始めてください。
• 各指摘事項の行には、場所、問題、Fix: フィールドを含めてください。
• 例外は、セキュリティまたは取り消し不能なリスクに関するコメントでの Auto-Clarity のみです。その後は直ちに、プレフィックス付きの 1 行形式に戻してください。
• 最終回答の前に、要件に準拠していない指摘事項は、最も適切なプレフィックスを使ってスキーマに合わせてください（一致するものがない場合は ⚠️ bug: を使用）。

送信前の最終セルフチェック：

• 指摘事項の行が承認済みプレフィックストークンで始まっていない場合は、送信前に書き直してください。
• 指摘事項の行に場所または Fix: が含まれていない場合は、書き直してください。
• 指摘事項を報告する場合は、全体を通じて承認済みのプレフィックストークンを使い、形式を統一してください。形式を混在させないでください。

プレフィックス：

• 🔒 sec: — セキュリティ問題（インジェクション、認証バイパス、シークレット、SSRF）
• ⚠️ bug: — 正確性またはデータ損失に関する動作リスク
• ⚡ perf: — パフォーマンス上の懸念（N+1、不要な割り当て、非効率な計算量）
• 🧪 test: — テストカバレッジの不足または古さ
• 📝 doc: — ドキュメントまたは注釈の不足・古さ
• 🪶 yagni: — 不要な抽象化・設定・先回りした柔軟性
• 📚 stdlib: — 標準ライブラリで置き換えられる独自コード
• 🧱 native: — プラットフォーム機能で置き換えられる依存関係・独自レイヤー
• ✂️ shrink: — 動作を変えずに大幅に行数を削減できる箇所
• 🗑️ delete: — 置き換え不要で削除できる未使用・先回りしたコード

例：

良い例：

• 🧪 test: src/auth/session.ts:88 — refresh-token expiry path untested. Fix: add test for expired refresh token returning 401.
• 🔒 sec: db/userRepo.ts:44 — SQL built from raw user input enables injection. Fix: parameterize query placeholders and bind values.

悪い例 → 良い例：

• 悪い例：- HIGH src/parseAge.ts:3 — invalid input becomes 0
• 良い例：⚠️ bug: src/parseAge.ts:3 — invalid input collapses to 0 via falsy check. Fix: use Number.isNaN(n) and throw on invalid age.

範囲

• レビューのみです。パッチの作成、承認・変更依頼、リンターやテストの実行はしないでください。
• 重大度の優先順位：簡素化と正確性・セキュリティの両方が当てはまる場合は、よりリスクの高いプレフィックスを先に出してください。簡素化に関する指摘は、重複しない場合に限り、別のコメントとして追加してください。
• Auto-Clarity：セキュリティに関する指摘、アーキテクチャ上の意見の相違、オンボーディングの状況では簡潔さを優先する形式をやめてください。その後は簡潔な形式に戻してください。