mcpField
A
architecture-review

architecture-review

github.com/owainlewis開発423309 回インストール今日更新
リポジトリ

architecture-review について

技術提案を独立した立場から読み取り専用で評価するアーキテクチャレビュー用スキルです。動作や安全性、障害対応、検証可能性を追跡し、所見と判定を返します。

主な機能

  1. 01新たな独立レビュアーを必須化
  2. 02リポジトリの根拠に基づき主張を確認
  3. 03入力から結果・障害までを追跡
  4. 04設計・セキュリティ・復旧を評価
  5. 05所見・質問・判定を提示

活用シーン

  1. 01実装前の技術提案レビュー
  2. 02障害経路と復旧策の確認
  3. 03受け入れ基準の検証可能性の評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/owainlewis/blueprint --skill architecture-review

インストール後、Claude Code で/architecture-reviewを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

アーキテクチャレビュー

技術提案を誤りやすく、安全でないものにしやすく、または証明不可能にしやすい選択を見つけます。 ドキュメントの長さや形式ではなく、提案されている動作とトレードオフをレビューします。

提案を書いていない新しいサブエージェントを1つ使います。レビュアーには、完全なコンテキストを提供します。委任せずに直接作業するよう指示してください。あなたがそのレビュアーである場合は、直接レビューしてください。読み取り専用で作業してください。

新しいサブエージェントを利用できない場合は、停止して、独立したレビューを実施できないことを報告してください。ユーザーが文書化されたセルフレビューを明示的に承認した場合に限り、続行してください。

プロセス

  1. 目標、提案、要件、意図するアーキテクチャ、リポジトリの指示、関連する現行コード、 テスト、スキーマ、設定、リンク先の資料を読みます。現行システムに関する主張は、コード、テスト、スキーマ、設定、インフラストラクチャ、または関連する実行時の証拠によって裏付けられるまで、未検証として扱います。
  2. 問題、影響を受けるユーザー、意図する結果、成功指標、スコープ、制約、主なトレードオフを明示します。提案で不明確なものがあれば報告します。
  3. 入力から観測可能な結果まで、実際のケースを1つ追跡します。重要な場合は、所有者、検証、状態変更、副作用、応答のタイミング、失敗、再試行、クリーンアップ、ユーザーに表示される内容を含めます。
  4. 以下のレビュー観点に基づいて、選択された設計を検証します。同じ結果と証明を、状態、結合、重複、運用作業を減らして実現できる、よりシンプルな選択肢がないか検討します。
  5. 重要な未解決の質問を明らかにします。証拠から回答を推奨できる場合は、その回答を推奨します。設計に影響しない質問を作り出してはいけません。
  6. 指摘事項、未解決の質問、簡潔な評価、そして1つの判定を返します。提案を書き換えたり、作業計画を立てたり、実装コードをレビューしたり、変更を実装したりしないでください。

レビュー観点

  • 要件および合意済みのアーキテクチャとの適合性を確認します。新しいシステムにコードがないことを理由にせず、現状に関する主張を検証します。
  • 所有権、境界、インターフェース、データ、互換性、移行、ロールアウト、ロールバックを確認します。
  • 提案に影響する場合は、部分的な失敗、再試行、キャンセル、並行処理、起動、終了、復旧を追跡します。
  • 提案の選択を左右する場合に限り、主張されている規模、限られたリソース、レイテンシ、スループット、ストレージ、コスト、依存関係の障害、運用担当者による復旧を確認します。
  • ID、認可、信頼できない入力、認証情報、破壊的な権限、機密データの取り扱いを確認します。
  • 重要なルールや障害経路について、観測可能な受け入れ基準と証明を求めます。ユーザーから見える動作、インターフェース、データルール、セキュリティポリシー、障害時の動作を、実装時に決めさせてはいけません。

重要な質問

ユーザー、データ、インターフェース、セキュリティ、規模、パフォーマンス、運用、コスト、互換性、証明に影響する形で、能力のある実装者が異なる回答をし得る場合に限り、未解決の質問として報告します。

  • ブロッキング: 回答が得られるまで実装を開始すべきではありません。
  • 重要: 提案に回答を記録すべきですが、利用可能な証拠に基づき、レビュアーは安全な既定値を推奨できます。

文体上の質問、実装内で安全に決められる質問、提示されたスコープ外の質問、提案が対応すると主張する規模を超える推測的な質問は省略します。

指摘事項

設計や安全性を変える可能性のある欠陥のみ報告してください。

  • ブロッカー: 選択が安全でない、目標や現在のシステムと矛盾している、または重大な障害から復旧できない。
  • 重要: 提案によって実装が大きく異なる可能性がある、または動作、規模、パフォーマンス、セキュリティ、運用、互換性、実証に関して無視できないリスクが残る。

各指摘事項または未解決の質問には、その箇所、具体的な障害または曖昧さ、影響、根拠、そして最小限の修正または推奨する回答を記載してください。新しいチームメンバーが設計を説明、評価、実装できなくなるような不明瞭な表現も報告してください。それ以外の文章上の好みは省略してください。

平易な言葉を使ってください。具体的な条件、障害、影響を明記してください。問題があるかもしれない や リスクがある可能性がある といった曖昧な表現で、不明点を隠さないでください。

判定

  • Approve:ブロッカー、重要な指摘事項、未解決の質問が残っていない。
  • Request changes:修正可能なブロッカー、重要な指摘事項、未解決の質問がある。
  • Blocked:レビューに必要なコンテキスト、リポジトリの根拠、専門家による確認、または独立したレビュアーが不足している。

未検証の事項を明記してください。文書が詳細であることや、テンプレートの各セクションがすべて埋まっていることを理由に、承認しないでください。

コメント