Skip to content
Back to skills

Architecture

ASecurity

Create or evaluate an architecture decision record (ADR). Use when choosing

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 20, 2026
code-quality

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add ruskicoder/system-prompts --skill architecture --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Architecture?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Architecture
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/ruskicoder-architecture/badge)](https://www.skillsdirectory.com/skills/ruskicoder-architecture)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: architecture
description: 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.
argument-hint: <decision or system to design>
---

<!-- Generated from skills/engineering-architecture.md by tools/generate_integrations.py. Edit the source file, not this one. -->

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

```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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…