Compare

Structured comparison of 2+ alternatives. Enforces a comparison matrix with consistent criteria so every alternative is evaluated on the SAME data points.

Steps

1. Define the comparison frame:

   • List all alternatives to compare (minimum 2)
   • Identify the use case or decision context (WHY is this comparison needed?)
   • Ask the user for must-have requirements vs nice-to-have criteria

2. Define evaluation criteria before searching (prevents cherry-picking):

   • Choose 5-8 criteria relevant to the use case
   • Common technical criteria: performance, developer experience, ecosystem/community, documentation quality, maintenance status, license, cost, learning curve
   • Weight criteria: must-have vs important vs nice-to-have
   • Every criterion MUST be evaluated for ALL alternatives (no gaps)

3. Research each alternative using search and extract:

   • search(action="search", query="[alternative] [criterion] benchmark OR comparison")
   • For each alternative, gather the SAME data points
   • Prefer quantitative data (benchmarks, stars, download counts, release frequency)
   • Note data recency — a 2023 benchmark may not reflect 2026 reality
   • Use extract on official docs for feature verification

4. Build the comparison matrix:

   | Criterion (weight) | Alternative A | Alternative B | Alternative C |
   |---------------------|---------------|---------------|---------------|
   | Performance (must)  | [data+source] | [data+source] | [data+source] |
   | DX (important)      | [data+source] | [data+source] | [data+source] |
   

   • Every cell must have a value — use "No data found" if genuinely unavailable
   • Include source links for verifiable claims
   • Use consistent units (same benchmark suite, same metric)

5. Produce decision recommendation:

   • Best for [use case X]: [Alternative] — because [reason based on must-have criteria]
   • Best for [use case Y]: [Alternative] — if the use case differs
   • Tradeoffs: What you give up with each choice
   • Avoid if: Dealbreaker scenarios for each alternative
   • Confidence: High (extensive data) / Medium (partial data) / Low (limited data)

Rules for Fair Comparison

• Same data points: If you measure response time for A, measure it for B too
• Same recency: Do not compare A's 2026 benchmark with B's 2023 benchmark
• Primary sources: Official docs and benchmarks over third-party opinions
• Acknowledge bias: If most search results favor one option, note this and search harder for the other
• No false equivalence: If one alternative is clearly better on all criteria, say so

Common Pitfalls

• Popularity bias: Most-popular is not always best-fit for the specific use case
• Feature-list comparison: Having more features is not inherently better
• Ignoring migration cost: Switching cost is a real criterion, include it
• Stale comparisons: Framework landscapes change fast. Always check latest versions.
• Missing "do nothing": Sometimes the best choice is to keep what you already have

When to Use

• Choosing between libraries, frameworks, or tools
• Evaluating database options, hosting providers, or API services
• Comparing architectural approaches (monolith vs microservices, REST vs GraphQL)
• Any decision where multiple viable options exist and evidence should drive the choice