How do I install the Architecture skill?

Run npx skillmds@latest add clawpod-app/architecture in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Architecture safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Architecture?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Architecture free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Architecture?

clawpod-app (@clawpod-app) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Architecture by clawpod-app — Agent Skill

Name: Architecture
Rating: 4.5 (4 reviews)
Author: clawpod-app

Architecture

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.

clawpod-app Updated Sep 22, 2026

File contents

/architecture

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.

---name: architecturedescription: 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.---# /architectureCreate 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 Items1. [ ] [Implementation step]2. [ ] [Follow-up]```## If Connectors AvailableIf **~~knowledge base** is connected:- Search for prior ADRs and design docs- Find relevant technical contextIf **~~project tracker** is connected:- Link to related epics and tickets- Create implementation tasks## Tips1. **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.

Frequently asked questions