architecture について
要件や機能仕様と並行して、ルートの `ARCHITECTURE.md` を作成・更新するアーキテクチャスキルです。境界、決定、データフロー、リスク、検証事項を記録し、タスク計画や実装は行いません。
主な機能
- 01ルートの `ARCHITECTURE.md` を作成・更新
- 02境界・責任・データを記録
- 03Mermaidの構成図とデータフロー図を作成
- 04重要な成功・失敗経路を追跡
- 05決定・不足・リスク・検証を記録
活用シーン
- 01新規システムのアーキテクチャ文書を作成
- 02重要な変更後にアーキテクチャを更新
- 03レビュー用にシステム設計を準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/architectureを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
アーキテクチャ
ルートに ARCHITECTURE.md を作成または更新します。これから構築するシステムを設計してください。
REQUIREMENTS.md と並ぶ、長期的に維持するシステムドキュメントとして扱います。
製品のニーズには /requirements を、機能の技術的な変更には /spec を使用します。
プロセス
- 要件、リポジトリの指示、既存のアーキテクチャ、関連するコード、スキーマ、テスト、インフラストラクチャを確認します。新しいシステムには、まだコードがない場合もあります。
- システムの形を決める判断を特定します。境界、責任、データの所有権、依存関係、品質上の制約などです。重要な判断に必要な情報が不足している場合は質問し、根拠から推奨案を示せる場合は、そのトレードオフとともに提案します。
- 要件を満たす最もシンプルな構造を選びます。重要な判断について、選んだアプローチ、最も有力な代替案、選択理由、主なコストを説明します。該当する場合は既存システムの維持も検討します。選択に影響しない比較は省略します。
- 以下の構成に沿ってアーキテクチャを記述します。アーキテクチャ図とデータフロー図を必ず含めてください。要件を複製するのではなく、参照してください。
- 重要な成功フローと失敗フローをたどります。要件に照らして、所有権、契約、データの一貫性、セキュリティ、復旧、測定可能な上限を確認します。
- アーキテクチャをレビューできる状態になったら終了します。タスクの計画や実装は行いません。
ドキュメントの構成
- 概要と目標： システム、その主要な部分、信頼できる情報源、設計を左右する要件。
- システム境界： ユーザー、外部システム、コンポーネント、重要なインターフェース。必須のアーキテクチャ図とデータフロー図を含めます。
- 責任と依存関係： 各部分が所有するものと所有しないもの、依存関係が向かう方向。
- データモデル： 中核となるエンティティ、関係、識別子、所有権、ライフサイクル、制約、一貫性ルール、保持期間、ストレージの選択。役立つ場合はエンティティ図を含めます。大規模なスキーマは繰り返さず、リンクしてください。
- 実行時フロー： 重要な実行順序、データの移動、トランザクション、副作用、障害、再試行、復旧。
- セキュリティと運用： 設計に関わる信頼境界、認可、デプロイ、可観測性、リソース上限、運用担当者による復旧。
- 運用上の想定： 設計を左右する想定負荷、レイテンシ、可用性、復旧、コストの制約。根拠のある目標を使い、重要な未確定事項とその影響を、数値を捏造せずに記録します。製品の上限については要件を参照してください。
- 目標とするシステムへの移行経路： 既存システムの場合は、必要に応じて重要なギャップ、互換性の制約、移行、ロールバックについて説明します。機能の詳細は仕様に、提供タスクは
/planに記載します。 - 判断とステータス： 判断に「提案」または「承認済み」の印を付けます。現在のシステムで実装済みのもの、不足しているもの、設計と異なるものは別途明記します。承認済みであっても、実装済みとは限りません。
- リスクと検証： 未解決の判断、前提、品質シナリオ、設計を検証するために必要な確認。
図
主要なコンポーネント、外部アクター、データストア、データフローを示す Mermaid 図を必ず含めてください。1 つの図でアーキテクチャとフローを扱えます。両方を組み合わせるとどちらかが読みにくくなる場合は、2 つ目の図を使ってください。
明確なラベル、ラベル付きの矢印、システム境界または信頼境界を示すグループを使用してください。どの部分がつながっているかだけでなく、部分間で何が移動するかを示してください。余裕のある間隔を取り、追いやすいレイアウトにしてください。読みやすいコントラストを保った、控えめで統一感のある配色を使用してください。矢印の交差や装飾的な細部は避けてください。図が混み合う場合はフローごとに分割し、概要図も残してください。
完成前に図をレンダリングして確認してください。ラベル、矢印の向き、読みやすさ、記述された設計との整合性を確認してください。主要なフローと、読者が理解しておくべき境界を説明するキャプションを付けてください。
図は必須です。このシステムの説明に役立つ場合にのみ、ほかのセクションを使用してください。関連する項目はまとめ、空のセクションは省略してください。共通ルールはここに記載し、機能固有のスキーマ変更やマイグレーションはその仕様書に記載してください。
既存の実装に関する主張は、信頼できるファイルまたは実行時の証拠に照らして確認してください。将来の動作や前提は明確に示してください。人間の承認なしに提案を承認済みとしないでください。重要なアーキテクチャ上のルールには、安定した INV-n ID を付け、想定する適用方法と検証方法を明記してください。
承認済みの変更によって、所有権、依存関係、インターフェース、保存データ、信頼境界、デプロイ、またはハードリミットが変わる場合は、この文書を更新してください。この文書を最新の状態に保ってください。有用な内容と安定した参照先を維持し、機能に関する意思決定の履歴は仕様書に残してください。
返却内容
パス、主な判断とトレードオフ、実装上の不足、ブロッキングとなる質問を報告してください。