| name | trade-off-analysis |
| description | Use when asked to compare or analyze trade-offs between two or more technical solutions, approaches, libraries, or architectures — produces a structured comparison, not just a recommendation. |
Trade-off Analysis
Produces a structured comparison an EM can use in a design discussion or
decision doc — not just "I'd pick X".
Steps
-
Make sure the options and the decision criteria are actually clear before
analyzing — if the user hasn't stated what matters most (time-to-ship?
long-term maintainability? team familiarity? performance?), ask first.
An analysis optimized for the wrong criterion is worse than no analysis.
-
For each option, assess against the same dimensions consistently:
## Option A: <name>
- **Effort to implement:** <estimate + what drives it>
- **Maintenance burden:** <ongoing cost — who owns it, how it ages>
- **Risk:** <what could go wrong, how likely, how bad>
- **Reversibility:** <how hard to undo/migrate away from later>
- **Team fit:** <familiarity, hiring, existing patterns in the codebase>
-
Be honest about uncertainty — mark assumptions explicitly rather than
presenting estimates as facts: "Assuming current traffic patterns hold..."
-
Close with a recommendation and the condition under which you'd change
it: "I'd go with B unless , in which case A is the safer bet."
Notes
- Ground comparisons in this codebase's actual constraints where possible
(existing patterns, current scale, team size) — not generic pros/cons lists.
- Irreversible decisions deserve more analysis weight than reversible ones;
say which kind this is.
