SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Backend · Documentation / AGENT SKILL
architecture
0
Create or evaluate architecture decision records and system design proposals.
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.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# /architecture > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../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 ```markdown # 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 1. **State constraints upfront** — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer. 2. **Name your options** — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives. 3. **Include non-functional requirements** — Latency, cost, team expertise, and maintenance burden matter as much as features.