/architecture

不慣れなプレースホルダーを見かけた場合、またはどのツールが接続されているかを確認する必要がある場合は、CONNECTORS.md を参照してください。

アーキテクチャ決定記録 (ADR) を作成するか、システム設計を評価します。

使い方

/architecture $ARGUMENTS

モード

ADR を作成する: 「イベントバス用に Kafka または SQS を使用すべきか?」 設計を評価する: 「このマイクロサービス提案をレビューしてください」 システム設計: 「アプリ向けの通知システムを設計してください」

要件の収集、スケーラビリティ分析、トレードオフ評価に関する詳細なフレームワークについては、system-design スキルを参照してください。

出力 — ADR フォーマット

# ADR-[number]: [Title]

**Status:** Proposed | Accepted | Deprecated | Superseded
**Date:** [Date]
**Deciders:** [Who needs to sign off]

## Context
[What is the situation? What forces are at play?]

## Decision
[What is the change we're proposing?]

## Options Considered

### Option A: [Name]
| Dimension | Assessment |
|-----------|------------|
| Complexity | [Low/Med/High] |
| Cost | [Assessment] |
| Scalability | [Assessment] |
| Team familiarity | [Assessment] |

**Pros:** [List]
**Cons:** [List]

### Option B: [Name]
[Same format]

## Trade-off Analysis
[Key trade-offs between options with clear reasoning]

## Consequences
- [What becomes easier]
- [What becomes harder]
- [What we'll need to revisit]

## Action Items
1. [ ] [Implementation step]
2. [ ] [Follow-up]

コネクタが利用可能な場合

~~knowledge base が接続されている場合:

• 以前の ADR と設計ドキュメントを検索
• 関連する技術的コンテキストを検索

~~project tracker が接続されている場合:

• 関連するエピックとチケットにリンク
• 実装タスクを作成

Tips

1. 制約を最初に述べる — 「2週間以内にリリースする必要があります」または「1秒あたり 10K リクエストを処理する必要があります」という制約は答えに大きく影響します。
2. オプションに名前を付ける — 1つの方向に傾いている場合でも、明示的な代替案を含むよりバランスの取れた分析を提供します。
3. 非機能要件を含める — レイテンシー、コスト、チームの専門知識、メンテナンスの負担は機能と同じくらい重要です。