SKILLKnowledge Work

architecture

プラグイン: Engineering
引数: <decision or system to design>
ソース: GitHub で見る ↗

説明

アーキテクチャ決定記録（システム構成の重要な判断を記した文書）を作成または評価します。 **次のような場合に使用:** - 複数の技術の中から選択する必要がある場合（例：Kafka対SQS） - 設計上の判断を、メリット・デメリットや影響と共に記録したい場合 - システム設計の提案を審査する場合 - 要件と制約条件から新しいコンポーネントを設計する場合

原文を表示

Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.

ユースケース

複数の技術から選択する必要がある場合
設計判断をメリット・デメリットと共に記録したい場合
システム設計の提案を審査する場合
要件と制約条件から新規コンポーネントを設計する場合

本文

/architecture

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Create an Architecture Decision Record (ADR) or evaluate a system design.

Usage

/architecture $ARGUMENTS

Modes

Create an ADR: "Should we use Kafka or SQS for our event bus?" Evaluate a design: "Review this microservices proposal" System design: "Design the notification system for our app"

See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.

Output — ADR Format

# 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]

If Connectors Available

If ~~knowledge base is connected:

Search for prior ADRs and design docs
Find relevant technical context

If ~~project tracker is connected:

Link to related epics and tickets
Create implementation tasks

Tips

State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。

Modes

Create an ADR: "Should we use Kafka or SQS for our event bus?" Evaluate a design: "Review this microservices proposal" System design: "Design the notification system for our app"

See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.

Output — ADR Format

# 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]

Tips

State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.

Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.

Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.