What this skill does
Provides a structured framework for comparing options under uncertainty. It surfaces criteria, weights them by stated priorities, scores each option, and produces a transparent recommendation — including the conditions under which a different option would be the right call.
When to use it
- User asks "should we use X or Y?", "which approach is better?", or "help me decide between…".
- User needs to document a decision and its rationale for a team or stakeholder.
- User wants to understand the trade-offs before committing to a direction.
- User is revisiting a past decision to validate or challenge it.
Instructions
Name the decision. State the decision being made in one sentence as a question (e.g., "Which message broker should we use for the order pipeline?").
Enumerate the options. List all options under consideration. If the user has provided fewer than two, ask for alternatives before proceeding.
Elicit criteria. Identify the decision criteria from the user's context. Group into:
- Must-haves (constraints that disqualify options if not met)
- Optimisation criteria (factors to weigh and compare)
Common criteria to consider: cost, performance, operational complexity, team expertise, vendor lock-in, time to implement, scalability, security, ecosystem maturity.
Weight the criteria. If the user has stated priorities, assign relative weights (High / Medium / Low or a 1–5 scale). Make weights explicit, not hidden.
Score each option. For each optimisation criterion, rate each option (Strong / Adequate / Weak) with a brief justification. Apply must-haves as pass/fail gates first.
Identify the dominant option. Summarise which option scores best overall. Note any criteria where a different option clearly wins.
State the recommendation with explicit conditions: "We recommend X. If [condition], Y becomes the better choice."
Produce the report using the output format below.
Output format
# Trade-off Analysis: [Decision question]
**Date:** YYYY-MM-DD
**Decision owner:** [name or team]
**Options considered:** [Option A, Option B, …]
---
## Must-haves (pass/fail)
| Criterion | Option A | Option B |
|-------------------|----------|----------|
| [constraint] | Pass / Fail | Pass / Fail |
*Options that fail any must-have are eliminated from further analysis.*
---
## Comparison
**Criteria weights:** [High = 3, Medium = 2, Low = 1]
| Criterion | Weight | Option A | Option B | Notes |
|-------------------|--------|----------|----------|-------|
| [criterion] | High | Strong | Adequate | ... |
| [criterion] | Medium | Weak | Strong | ... |
---
## Summary scores
| Option | Weighted score | Strengths | Weaknesses |
|----------|---------------|----------------------------|-------------------------|
| Option A | [n/total] | ... | ... |
| Option B | [n/total] | ... | ... |
---
## Recommendation
**Recommended:** [Option]
**Reasoning:** [2–3 sentences explaining the dominant factors.]
**Choose differently if:**
- [Condition 1] → prefer [alternative]
- [Condition 2] → prefer [alternative]
---
## Risks of the recommended option
- [Risk 1]
- [Risk 2]
## Open questions
- [Any unknowns that could change the recommendation]
Examples
Example 1 — Message broker selection
Input: "Should we use Kafka or RabbitMQ for our order pipeline? We need high throughput, the team knows RabbitMQ, and we can't afford a large ops burden."
Expected output: Trade-off report weighting throughput (High), ops burden (High), and team expertise (Medium). Recommendation section stating which wins and under what conditions the other is better.
Example 2 — Build vs. buy
Input: "We're deciding whether to build our own auth system or use an existing provider."
Expected output: Report identifying must-haves (compliance requirements), scoring options on security, time to market, long-term cost, and control. Clear recommendation with the condition that triggers the alternative.
Notes
- If criteria are missing or ambiguous, ask one targeted clarifying question before scoring.
- Do not hide weights or scoring inside a narrative — keep them in the table so the reasoning is auditable.
- Avoid the recommendation being purely score-mechanical: note qualitative factors that override the numbers if relevant.
- A "no clear winner" result is a valid output when options are genuinely close — state what new information would break the tie.
1---2name: tradeoff-analysis3description: Provides a structured framework for comparing options under uncertainty. It surfaces criteria, weights them by stated priorities, scores each option, and produces a transparent recommendation — including the conditions under which a different option would be the right call.4---56## What this skill does78Provides a structured framework for comparing options under uncertainty. It surfaces criteria, weights them by stated priorities, scores each option, and produces a transparent recommendation — including the conditions under which a different option would be the right call.910## When to use it1112- User asks "should we use X or Y?", "which approach is better?", or "help me decide between…".13- User needs to document a decision and its rationale for a team or stakeholder.14- User wants to understand the trade-offs before committing to a direction.15- User is revisiting a past decision to validate or challenge it.1617## Instructions18191. **Name the decision.** State the decision being made in one sentence as a question (e.g., "Which message broker should we use for the order pipeline?").20212. **Enumerate the options.** List all options under consideration. If the user has provided fewer than two, ask for alternatives before proceeding.22233. **Elicit criteria.** Identify the decision criteria from the user's context. Group into:24 - **Must-haves** (constraints that disqualify options if not met)25 - **Optimisation criteria** (factors to weigh and compare)2627 Common criteria to consider: cost, performance, operational complexity, team expertise, vendor lock-in, time to implement, scalability, security, ecosystem maturity.28294. **Weight the criteria.** If the user has stated priorities, assign relative weights (High / Medium / Low or a 1–5 scale). Make weights explicit, not hidden.30315. **Score each option.** For each optimisation criterion, rate each option (`Strong` / `Adequate` / `Weak`) with a brief justification. Apply must-haves as pass/fail gates first.32336. **Identify the dominant option.** Summarise which option scores best overall. Note any criteria where a different option clearly wins.34357. **State the recommendation** with explicit conditions: "We recommend X. If [condition], Y becomes the better choice."36378. **Produce the report** using the output format below.3839## Output format4041```markdown42# Trade-off Analysis: [Decision question]4344**Date:** YYYY-MM-DD 45**Decision owner:** [name or team] 46**Options considered:** [Option A, Option B, …]4748---4950## Must-haves (pass/fail)5152| Criterion | Option A | Option B |53|-------------------|----------|----------|54| [constraint] | Pass / Fail | Pass / Fail |5556*Options that fail any must-have are eliminated from further analysis.*5758---5960## Comparison6162**Criteria weights:** [High = 3, Medium = 2, Low = 1]6364| Criterion | Weight | Option A | Option B | Notes |65|-------------------|--------|----------|----------|-------|66| [criterion] | High | Strong | Adequate | ... |67| [criterion] | Medium | Weak | Strong | ... |6869---7071## Summary scores7273| Option | Weighted score | Strengths | Weaknesses |74|----------|---------------|----------------------------|-------------------------|75| Option A | [n/total] | ... | ... |76| Option B | [n/total] | ... | ... |7778---7980## Recommendation8182**Recommended:** [Option]8384**Reasoning:** [2–3 sentences explaining the dominant factors.]8586**Choose differently if:**87- [Condition 1] → prefer [alternative]88- [Condition 2] → prefer [alternative]8990---9192## Risks of the recommended option9394- [Risk 1]95- [Risk 2]9697## Open questions9899- [Any unknowns that could change the recommendation]100```101102## Examples103104### Example 1 — Message broker selection105106**Input:** "Should we use Kafka or RabbitMQ for our order pipeline? We need high throughput, the team knows RabbitMQ, and we can't afford a large ops burden." 107**Expected output:** Trade-off report weighting throughput (High), ops burden (High), and team expertise (Medium). Recommendation section stating which wins and under what conditions the other is better.108109### Example 2 — Build vs. buy110111**Input:** "We're deciding whether to build our own auth system or use an existing provider." 112**Expected output:** Report identifying must-haves (compliance requirements), scoring options on security, time to market, long-term cost, and control. Clear recommendation with the condition that triggers the alternative.113114## Notes115116- If criteria are missing or ambiguous, ask one targeted clarifying question before scoring.117- Do not hide weights or scoring inside a narrative — keep them in the table so the reasoning is auditable.118- Avoid the recommendation being purely score-mechanical: note qualitative factors that override the numbers if relevant.119- A "no clear winner" result is a valid output when options are genuinely close — state what new information would break the tie.
MarieLynneBlock