| name | review-layer-responsibility |
| description | ソフトウェアアーキテクチャのレビューを行う。コード変更について、層の責務が適切に守られているかを評価。関心の分離、依存性の方向、データの抽象度をチェックし、具体的な改善案を提示する。 |
| argument-hint | [変更内容またはファイルパス] |
| allowed-tools | Read, mcp__acp__Read, Grep |
| disable-model-invocation | false |
アーキテクチャレビュースキル
コード変更について、層の責務が適切に守られているかを評価します。
ステップ1: アーキテクチャパターンの推測
変更されたファイルのパス、ディレクトリ構造、コードから、使用されているアーキテクチャパターンを推測します。
推測結果:
- パターン名: [例: MVC + Service層]
- 理由: [ディレクトリ構造、命名規則などから]
- 確信度: 高/中/低
もし推測が難しい場合は、ユーザーに確認します。
ステップ2: 普遍的な原則でのチェック
以下の原則に照らして評価:
原則1: 関心の分離
各ファイル/クラスは単一の関心事だけを扱っているか?
原則2: 依存性の方向
- 高レベル層が低レベル層に依存しているか?
- 逆向きの依存はないか?
原則3: データの抽象度
各層が扱うデータの抽象度は適切か?
- 低レベル層: SQL、HTTPリクエスト、ファイルパス
- 中レベル層: ビジネスデータ(Entity、DTO)
- 高レベル層: 表示データ(フォーマット済み、UI用フラグ)
原則4: 責務の適切性
- データアクセス層: DB/API操作のみ
- ビジネスロジック層: ビジネスルールのみ、ビジネスの言葉で表現できるデータを返す
- プレゼンテーション層: 入力受付と出力整形、表示の都合を扱う
- 表示層: 表示のみ
ステップ3: 変更内容の分析
変更の性質
- 🎯 ビジネスロジック
- 🎨 UI/表示要件
- 📊 データ構造
- ⚡ パフォーマンス
- 🔧 リファクタリング
変更されたファイルと層
| ファイル | 推測される層 | 変更内容 |
|---|
| [...] | [...] | [...] |
ステップ4: 責務チェック
各変更について:
[ファイル名/層]
- ✅/❌ この層の責務に沿っているか
- ✅/❌ 他の層の責務が混入していないか
- ✅/❌ データの抽象度は適切か
- 評価: [...]
- 理由: [...]
ステップ5: データ配置の評価
追加・変更されたデータについて:
| データ | 現在の配置 | 評価 | 理由 |
|---|
xxx | [...] | ✅/❌ | [...] |
判断基準:
- これはビジネス知識か表示知識か?
- 他の場所でも使える汎用性があるか?
- 生データか加工データか?
ステップ6: 総合評価
🟢 適切な点
[...]
🟡 改善が望ましい点
[...]
🔴 問題点
[...]
ステップ7: 推奨対応
具体的なコード例を含めて、改善案を提示します。
重要な注意点
- プロジェクト固有の用語や構造を尊重する
- 理想論だけでなく、現実的な妥協点も示す
- トレードオフを明示する
- コード例を具体的に示す