Skill

system-design

Guide architectural design decisions for software systems. Use this skill when designing new systems, evaluating architecture trade-offs, or creating technical design documents. Helps produce clear, well-structured design artifacts including component diagrams, data flow, and decision records.

Install

npx claudepluginhub s-hiraoku/synapse-a2a --plugin synapse-a2a

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Guide architectural decisions and produce structured design artifacts.

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.2k

mcp-builder

9 files

Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).

anthropics-skills-13

124.2k

canvas-design

20 files

Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.

anthropics-skills-13

124.2k

Stats

Parent Repo Stars2

Parent Repo Forks0

Last CommitFeb 11, 2026

Used By3 plugins

Actions

View Source View Plugin View on GitHub View README

System Design

Guide architectural decisions and produce structured design artifacts.

When to Use

Designing a new system or major feature from scratch
Evaluating trade-offs between architectural approaches
Creating Architecture Decision Records (ADRs)
Reviewing existing architecture for scalability, reliability, or maintainability concerns
Decomposing a monolith or planning a migration

Workflow

Step 1: Clarify Requirements

Before designing, gather:

Functional requirements - What must the system do?
Non-functional requirements - Performance, availability, security, cost constraints
Scope boundaries - What is explicitly out of scope?
Existing constraints - Current tech stack, team skills, timeline

Ask the user to clarify any ambiguous requirements before proceeding.

Step 2: Identify Components

Break the system into components:

Data stores - What data exists? How is it accessed?
Services / modules - What are the logical units of work?
Interfaces - How do components communicate? (API, events, shared DB, files)
External dependencies - Third-party services, APIs, infrastructure

Step 3: Evaluate Alternatives

For each significant decision, document at least 2 options:

Criterion	Option A	Option B
Complexity	...	...
Scalability	...	...
Operational cost	...	...
Team familiarity	...	...

Recommend one option with clear reasoning.

Step 4: Produce Design Artifact

Output a structured design document:

# Design: <Title>

## Context
[Problem statement and motivation]

## Requirements
- Functional: ...
- Non-functional: ...

## Architecture
[Component diagram or description]

## Key Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| ... | ... | ... |

## Data Model
[Schema or entity relationships]

## API Surface
[Key endpoints or interfaces]

## Risks & Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| ... | ... | ... |

## Open Questions
- ...

Step 5: Review Checklist

Before finalizing, verify:

Single responsibility per component
No circular dependencies between modules
Failure modes identified and handled
Data consistency model is explicit (strong vs eventual)
Security boundaries are defined
Observability points (logging, metrics, tracing) are planned

Principles

Start simple - Add complexity only when requirements demand it
Make trade-offs explicit - Every choice has a cost; document it
Design for change - Interfaces should be stable; implementations should be replaceable
Separate concerns - Data, logic, and presentation should not be entangled
Fail gracefully - Design for partial failures, not just the happy path