Compare alternatives systematically to make better design and technology decisions.
This skill appears to be a prompt-only methodology document for structured tradeoff analysis, with no keys, no remote endpoints, and no stated code execution or data access capabilities. Overall risk is low; the main caution is supply-chain uncertainty due to low community adoption, undeclared license, and unknown maintenance status.
The material explicitly states that no keys or environment variables are required; as a prompt-only skill, there is no evident path for credential collection, storage, forwarding, or misuse.
The material states there are no remote endpoints, and the README only contains an analysis framework and templates, with no described networking, API calls, or user data exfiltration.
The system check marks it as prompt-only, and the document does not declare spawning local processes, running scripts, invoking system commands, or using privileged capabilities; it is static methodological content.
There is no declared ability to read, write, or enumerate local files, databases, clipboard contents, or other resources; based on the material, it does not involve data-plane access permissions.
The source is an auditable open-source GitHub repository, and the repository path indicates the microsoft organization, both positive factors; however, the license is undeclared, community adoption is 0 stars, and maintenance status is unknown, so some supply-chain and long-term maintenance uncertainty remains.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "tradeoff-analysis" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/tradeoff-analysis/SKILL.md 2. Save it as ~/.claude/skills/tradeoff-analysis/SKILL.md 3. Reload skills and tell me it's ready
Use the 8-dimension tradeoff analysis framework to compare PostgreSQL and MongoDB for a fast-growing content platform. Output a comparison matrix, tradeoff notes for each dimension, suitability conditions, and a final recommendation.
A structured comparison with a multidimensional matrix, key tradeoff logic, and scenario-based recommendations.
We need to choose between adding a guided onboarding flow and simplifying first-use steps. Analyze the options with a tradeoff matrix across user experience, conversion, implementation cost, maintenance complexity, and risk, then recommend a direction.
A product-focused comparison showing pros, cons, and a clear rationale for the recommendation.
For the question 'Which is better, microservices or a monolith?', do not give a direct yes-or-no answer. Use common tradeoff patterns and the 8-dimension framework to explain how the choice changes by team size, business complexity, and delivery stage.
A conditional decision guide that clarifies the best choice under different assumptions.
Every design decision answers this:
"What does this optimize for, and what does it sacrifice?"
If you cannot answer this clearly for a design, the design is not yet understood.
Evaluate every design alternative against these fixed dimensions. Do not invent new dimensions — force the analysis into this frame so alternatives are comparable.
| Dimension | Key Question | Watch For |
|---|---|---|
| Latency | How fast must it respond? | P50 vs P99 distinction; latency budgets per hop |
| Complexity | How many concepts must be held in mind? | Operational complexity vs code complexity — they diverge |
| Reliability | What is the acceptable failure rate? | Partial degradation vs total failure; blast radius |
| Cost | What are the resource costs now and at scale? | Cost curves that are linear now but exponential later |
| Security | What is the attack surface? | Authentication, authorization, data exposure, supply chain |
| Scalability | What grows with usage, time, and org size? | The thing that scales worst is the bottleneck |
| Reversibility | How hard is it to undo this decision? | Data model choices are least reversible; API contracts are hard; implementation details are easy |
| Organizational fit | Does this match the team's actual ability? | A design the team cannot operate is a failed design |
For comparing N alternatives, fill this matrix:
| Dimension | Option A | Option B | Option C |
|---|---|---|---|
| Latency | [rating + note] | [rating + note] | [rating + note] |
| Complexity | ... | ... | ... |
| Reliability | ... | ... | ... |
| Cost | ... | ... | ... |
| Security | ... | ... | ... |
| Scalability | ... | ... | ... |
| Reversibility | ... | ... | ... |
| Org fit | ... | ... | ... |
| Optimizes for | [1-line summary] | [1-line summary] | [1-line summary] |
| Sacrifices | [1-line summary] | [1-line summary] | [1-line summary] |
Ratings: use qualitative assessments (good/adequate/poor) with a concrete note explaining why. Numeric scores create false precision.
These pairs recur across system design. Recognizing the pattern accelerates analysis.
Consistency vs. Availability — CAP theorem and its practical implications. Strong consistency requires coordination; eventual consistency allows independent operation. Most systems need consistency for some data and availability for other data — the design question is where to draw the line.
Simplicity vs. Flexibility — Simple systems are easy to understand but hard to extend. Flexible systems handle change but are harder to reason about. Prefer simplicity unless you have concrete evidence that flexibility will be needed — not hypothetical future requirements.
Latency vs. Throughput — Optimizing for individual request speed often reduces total system throughput (and vice versa). Batching improves throughput but hurts latency. Streaming can sometimes improve both.
Build vs. Buy — Building gives control and fit; buying gives speed and maintained infrastructure. The hidden cost of "buy" is operational dependency. The hidden cost of "build" is maintenance burden.
Centralization vs. Distribution — Centralized systems are simpler to reason about but create single points of failure and scaling bottlenecks. Distributed systems are resilient but introduce coordination complexity.
Optimization vs. Observability — Aggressive optimization (caching, denormalization, precomputation) makes systems faster but harder to debug. Ensure every optimization comes with the monitoring needed to verify it works.
Safety vs. Speed — Guardrails (validation, type checking, review processes) slow development but prevent failures. The cost of skipping them is paid later, with interest.
…
Design and assess enterprise integration patterns, legacy modernization, and orchestration strategies.
Review system designs with a seven-step method to surface risks and improvements.
Evaluate system designs through Unix/Linux principles for simplicity and composability.
Design or assess Azure system architectures, operations, and cloud service choices.
Design and evaluate data pipelines, streaming systems, and ETL architecture patterns.
Design offline-first edge systems with sync, conflict handling, and weak-network resilience.