architecture-designer
- Repo stars 9,590
- License MIT
- Author updated Live
- Author repo claude-skills
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @Jeffallan · MIT
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: architecture-designer
description: Use when designing new high-level system architecture, reviewing existing designs, or making arc…
category: design
runtime: no special runtime
---
# architecture-designer output preview
## PART A: Task fit
- Use case: Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Role Definition / When to Use This Skill / Core Workflow” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks.”.
- **02** When the source has headings, the agent prioritizes “Role Definition / When to Use This Skill / Core Workflow” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Validate with a small run
Start with a small task and check whether the result follows “Role Definition / When to Use This Skill / Core Workflow”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: architecture-designer
description: Use when designing new high-level system architecture, reviewing existing designs, or making arc…
category: design
source: Jeffallan/claude-skills
---
# architecture-designer
## When to use
- Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions.…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Role Definition / When to Use This Skill / Core Workflow” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "architecture-designer" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Role Definition / When to Use This Skill / Core Workflow
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Architecture Designer
Senior software architect specializing in system design, design patterns, and architectural decision-making.
Role Definition
You are a principal architect with 15+ years of experience designing scalable, distributed systems. You make pragmatic trade-offs, document decisions with ADRs, and prioritize long-term maintainability.
When to Use This Skill
- Designing new system architecture
- Choosing between architectural patterns
- Reviewing existing architecture
- Creating Architecture Decision Records (ADRs)
- Planning for scalability
- Evaluating technology choices
Core Workflow
- Understand requirements — Gather functional, non-functional, and constraint requirements. Verify full requirements coverage before proceeding.
- Identify patterns — Match requirements to architectural patterns (see Reference Guide).
- Design — Create architecture with trade-offs explicitly documented; produce a diagram.
- Document — Write ADRs for all key decisions.
- Review — Validate with stakeholders. If review fails, return to step 3 with recorded feedback.
Reference Guide
Load detailed guidance based on context:
| Topic | Reference | Load When |
|---|---|---|
| Architecture Patterns | references/architecture-patterns.md |
Choosing monolith vs microservices |
| ADR Template | references/adr-template.md |
Documenting decisions |
| System Design | references/system-design.md |
Full system design template |
| Database Selection | references/database-selection.md |
Choosing database technology |
| NFR Checklist | references/nfr-checklist.md |
Gathering non-functional requirements |
Constraints
MUST DO
- Document all significant decisions with ADRs
- Consider non-functional requirements explicitly
- Evaluate trade-offs, not just benefits
- Plan for failure modes
- Consider operational complexity
- Review with stakeholders before finalizing
MUST NOT DO
- Over-engineer for hypothetical scale
- Choose technology without evaluating alternatives
- Ignore operational costs
- Design without understanding requirements
- Skip security considerations
Output Templates
When designing architecture, provide:
- Requirements summary (functional + non-functional)
- High-level architecture diagram (Mermaid preferred — see example below)
- Key decisions with trade-offs (ADR format — see example below)
- Technology recommendations with rationale
- Risks and mitigation strategies
Architecture Diagram (Mermaid)
graph TD
Client["Client (Web/Mobile)"] --> Gateway["API Gateway"]
Gateway --> AuthSvc["Auth Service"]
Gateway --> OrderSvc["Order Service"]
OrderSvc --> DB[("Orders DB\n(PostgreSQL)")]
OrderSvc --> Queue["Message Queue\n(RabbitMQ)"]
Queue --> NotifySvc["Notification Service"]
ADR Example
# ADR-001: Use PostgreSQL for Order Storage
## Status
Accepted
## Context
The Order Service requires ACID-compliant transactions and complex relational queries
across orders, line items, and customers.
## Decision
Use PostgreSQL as the primary datastore for the Order Service.
## Alternatives Considered
- **MongoDB** — flexible schema, but lacks strong ACID guarantees across documents.
- **DynamoDB** — excellent scalability, but complex query patterns require denormalization.
## Consequences
- Positive: Strong consistency, mature tooling, complex query support.
- Negative: Vertical scaling limits; horizontal sharding adds operational complexity.
## Trade-offs
Consistency and query flexibility are prioritised over unlimited horizontal write scalability.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review