system-design
- Repo stars 19,014
- Author repo knowledge-work-plugins
System Design
Help design systems and evaluate architectural decisions.
Framework
1. Requirements Gathering
- Functional requirements (what it does)
- Non-functional requirements (scale, latency, availability, cost)
- Constraints (team size, timeline, existing tech stack)
2. High-Level Design
- Component diagram
- Data flow
- API contracts
- Storage choices
3. Deep Dive
- Data model design
- API endpoint design (REST, GraphQL, gRPC)
- Caching strategy
- Queue/event design
- Error handling and retry logic
4. Scale and Reliability
- Load estimation
- Horizontal vs. vertical scaling
- Failover and redundancy
- Monitoring and alerting
5. Trade-off Analysis
- Every decision has trade-offs. Make them explicit.
- Consider: complexity, cost, team familiarity, time to market, maintainability
Output
Produce clear, structured design documents with diagrams (ASCII or described), explicit assumptions, and trade-off analysis. Always identify what you'd revisit as the system grows.
- Fluxly category
- Design
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 88 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @anthropics · no license declared
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Detected network behavior
- External requests
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Framework
Functional requirements (what it does) Non-functional requirements (scale, latency, availability, cost) Constraints (team size, timeline, existing tech stack)
Component diagram Data flow API contracts
Data model design API endpoint design (REST, GraphQL, gRPC) Caching strategy
Load estimation Horizontal vs. vertical scaling Failover and redundancy
Every decision has trade-offs. Make them explicit. Consider: complexity, cost, team familiarity, time to market, maintainability
# System Design
Help design systems and evaluate architectural decisions.
## Framework
### 1. Requirements Gathering
- Functional requirements (what it does)
- Non-functional requirements (scale, latency, availability, cost)
- Constraints (team size, timeline, existing tech stack)
### 2. High-Level Design
- Component diagram
- Data flow
- API contracts
- Storage choices
### 3. Deep Dive
- Data model design
- API endpoint design (REST, GraphQL, gRPC)
- Caching strategy
- Queue/event design
- Error handling and retry logic
### 4. Scale and Reliability
- Load estimation
- Horizontal vs. vertical scaling
- Failover and redundancy
- Monitoring and alerting
### 5. Trade-off Analysis
- Every decision has trade-offs. Make them explicit.
- Consider: complexity, cost, team familiarity, time to market, maintainability
## Output
Produce clear, structured design documents with diagrams (ASCII or described), explicit assumptions, and trade-off analysis. Always identify what you'd revisit as the system grows. Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Framework → 1. Requirements Gathering → 2. High-Level Design → 3. Deep Dive → 4. Scale and Reliability → 5. Trade-off Analysis
terms -> Help design systems and evaluate architectural decisions. · Produce clear, structured design documents with diagrams (ASCII or described), explicit assumptions, and trade-off analysis.
files/cmd -> Queue/event
body sha256 -> 9a0479e16073
Decide Fit First
Design Intent
How To Use It
Boundaries And Review