| name | minus |
|---|---|
| description | 規約と振る舞いを守りながら、所有の分散、依存、状態空間、インターフェースの負荷を削る設計レビューを行う。 |
| disable-model-invocation | true |
レビュー範囲を受け取ってください。 指定がなければ、現在の差分を対象にしてください。
判断に必要であれば、呼び出し元、呼び出し先、型、テスト、履歴まで調べてください。 改善案は周辺へ及んでも構いませんが、指摘はレビュー対象が導入または顕在化させた問題に限定してください。
最初に、リポジトリのルートからレビュー対象までの階層と、README*、AGENTS.md、CLAUDE.md、CONTRIBUTING*、docs/、rules/、.github/、skills/ などを検索してください。
対象に適用される規約を読み、すべての判断と改善で必ず守ってください。 規約が競合する場合は、明記された優先順位に従ってください。 優先順位がなければ、対象に近い規約を優先してください。 競合を解消できない場合は、レビューの冒頭で明示してください。
保つべき要件、観測可能な振る舞い、公開契約、不変条件を特定してください。 確認できない事項を事実として扱わないでください。
既存の構造や実装手順は、規約または要件として確認できない限り、制約ではなく一つの実装案として扱ってください。
目指すのは、利用者が理解する概念に対して、多くの機能、設計上の判断、不変条件を内部に隠す深いモジュールです。
利用者は目的だけを伝え、内部の手順、表現、特殊条件を知る必要がありません。 各設計判断には一つの所有者があり、変更の影響はその境界内に閉じます。 各層は隣接する層と異なる抽象を提供します。 機能が増えても、外部へ露出する概念、依存、状態、例外が増えにくい構造を目指してください。
複雑さとは、変更のために理解し、追跡し、調整しなければならないものの総量です。
設計上の判断や不変条件は消さず、その所有者の外から知る必要をなくしてください。
次の四つの観点でレビューしてください。
- 所有: ルール、前提、設計判断、不変条件と、それらを強制する処理を一つの所有境界へ集めてください。検証、既定値、順序、再試行、後始末、失敗処理を、その内部事情を知るモジュールへ隠してください。
- 依存: 依存を減らし、正しい方向へ揃えてください。ロジックをその概念の所有者へ置き、既存の標準的な仕組みを再利用してください。重複、循環、不要な転送、および異なる抽象を提供しない層やラッパーを削ってください。
- 状態: 分岐、フラグ、モード、nullable、cast、fallback、中間状態、例外を整理するだけで終えず、型、モデル、契約を変えて存在自体を消してください。無効な状態は可能な限り表現不能にしてください。
- インターフェース: 利用者が理解し、指定し、順守する契約を減らしてください。シグネチャだけでなく、型、設定、副作用、失敗の意味、順序制約、性能、並行性、原子性の保証まで評価してください。
局所的な整形より、不要な概念、分岐、状態、依存、層、公開契約要素を消す再設計を優先してください。
分割、抽出、統合、一般化は、複雑さの総量を減らす場合だけ提案してください。 行数、ファイルサイズ、関数長だけを理由に分割しないでください。 一般化は、現在確認できる複数の用途を、より単純なインターフェースで扱える場合に限ってください。 未確認の将来要件のために、拡張点、設定、汎用機構を追加しないでください。 複雑さを移動または分散するだけの変更を、改善と判断しないでください。
既存構造の修繕に終始せず、要件を最初から知っていた場合に選ぶ構造を考えてください。 振る舞いの正しさだけでレビューを終えず、総複雑さを減らせる具体的な再設計がある場合は、積極的に改善を提案してください。
次の形式で簡潔に出力してください。
Findings
- : <要約> 根拠となるファイル、行、観測事実を示し、それが所有・依存・状態・インターフェースのどれをどう増やしているかを書いてください。 改善案は同じ項目内に短く含めてください。
Good Points
根拠を確認できた健全な点だけを短く書いてください。 例: 境界が保たれている、契約テストが効いている、責務が既存の所有者に収まっている、不要な公開契約が増えていない。
Next
優先順位、検証結果、残る判断事項があれば短く書いてください。
Findings は重要度順に並べ、High、Medium、Low のいずれかを付けてください。
High は、所有境界、公開契約、不変条件、状態空間、依存方向を悪化させ、今後の変更コストを明確に増やすものに使ってください。
Medium は、局所的だが同じ形で増えると設計負債になるものに使ってください。
Low は、複雑さの増加は小さいが、今直すと自然に削れるものに限ってください。
低価値な nit は出さず、根拠を示せる高確度の指摘だけを出してください。
規約に基づく指摘では、根拠となるファイルと該当箇所を示してください。
明確な複雑さの増加は、振る舞いが正しくても指摘してください。
指摘がなければ Findings に「指摘なし」とだけ書いてください。