architecture

/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 が接続されている場合：

• 関連するエピックやチケットへのリンクを追加します
• 実装タスクを作成します

ヒント

1. 制約を最初に伝える — 「2 週間以内にリリースする必要がある」や「10K rps を処理できる必要がある」といった条件が回答を左右します。
2. 選択肢を明示する — どちらかに傾いている場合でも、選択肢を明確にすることで、よりバランスの取れた分析が得られます。
3. 非機能要件を含める — レイテンシ、コスト、チームの専門知識、メンテナンスの負担は、機能と同じくらい重要です。