review-layer-responsibility

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: 推奨対応

具体的なコード例を含めて、改善案を提示します。

重要な注意点

• プロジェクト固有の用語や構造を尊重する
• 理想論だけでなく、現実的な妥協点も示す
• トレードオフを明示する
• コード例を具体的に示す