Option Comparator

Evaluates 2 to 4 technical options against explicit, user-defined criteria. Generates an objective comparison matrix and transparent trade-off summary without subjective bias.

1. Purpose

Help teams make evidence-based technical choices. An "Option" is a candidate solution. A "Criterion" is an explicit standard of judgment (e.g. latency, memory, license, cost).

2. When to Use

Use this skill when:

• Choosing between libraries, architectures, databases, or deployment strategies.
• User asks: "Compare X vs Y based on [criteria]".
• Weighing trade-offs with explicit requirements.

3. When Not to Use

• Do not use for code diff review; use diff-reviewer.
• Do not use to verify factual claims; use claim-checker.

4. Required Inputs

• options: List of 2 to 4 options to compare (names or descriptions).
• criteria: List of explicit comparison criteria (e.g., Performance, Cost, Complexity, License).
• context_data: Available facts or benchmarks about each option.

5. Missing-Input Behavior

1. If options contains fewer than 2 items: stop and ask: "Please provide at least 2 options to compare."
2. If criteria is missing: propose 3 standard criteria based on context (e.g., Complexity, Performance, Maintenance) and ask for confirmation before scoring.
3. Never score an option on a criterion without stating the underlying fact or source.

6. Procedure

Follow these numbered actions:

1. Action 1: Standardize Matrix Axes
   • Set options as columns and criteria as rows.
2. Action 2: Evaluate Each Option Against Each Criterion
   • Assign rating: High / Med / Low or Yes / No / Partial.
   • Provide a 1-sentence factual justification for each cell.
3. Action 3: Identify Primary Trade-offs
   • Summarize what you gain and what you give up with each option.
4. Action 4: Formulate Conditional Recommendation
   • State: "Choose Option A if [condition]. Choose Option B if [condition]."
   • Do not declare a blanket winner unless one option dominates across all criteria.
5. Action 5: Emit Comparison Report
   • Format using Section 8.

7. Decision Rules

• If license compatibility is a criterion and an option has GPL/copyleft: flag as License Risk if proprietary closed source context is given.
• If data is missing for an option on a specific criterion: mark cell as Unknown / Needs Benchmark, not as Low.

8. Output Format

Emit the comparison using this template:

### Technical Comparison: [Topic]

#### Comparison Matrix
| Criterion | Option A: [Name] | Option B: [Name] | Option C: [Name] |
| :--- | :--- | :--- | :--- |
| **[Criterion 1]** | [Rating]: [Evidence] | [Rating]: [Evidence] | ... |
| **[Criterion 2]** | [Rating]: [Evidence] | [Rating]: [Evidence] | ... |

#### Key Trade-offs
- **Option A**: Best for [X], but compromises on [Y].
- **Option B**: Best for [Y], but compromises on [X].

#### Decision Rule / Recommendation
- Choose **Option A** if: [Condition].
- Choose **Option B** if: [Condition].

9. Verification Checklist

• Every option is rated against all listed criteria.
• Ratings have concrete justifications, not just numbers.
• Recommendations are conditional based on user priorities.
• No personal favoritism or ungrounded claims.

10. Common Failures and Recovery

11. Stop or Escalation Conditions

Stop and ask the user when:

• All options are missing documented performance or compatibility facts.

12. Examples

Example 1: Successful Execution

Input:

Options: SQLite vs PostgreSQL
Criteria: Setup complexity, Concurrent write throughput, Operational overhead
Context: Single-node CLI application running locally for one user.

Output:

### Technical Comparison: SQLite vs PostgreSQL for Local CLI

#### Comparison Matrix
| Criterion | Option A: SQLite | Option B: PostgreSQL |
| :--- | :--- | :--- |
| **Setup complexity** | Low: Zero configuration, embedded single-file database. | High: Requires separate daemon, user setup, connection string. |
| **Concurrent write throughput** | Low: Database-level locking limits concurrent writer threads. | High: Multi-version concurrency control (MVCC) handles heavy concurrent writes. |
| **Operational overhead** | Low: Backed up by copying one file, no background server process. | Medium: Requires service monitoring, port binding, daemon management. |

#### Key Trade-offs
- **SQLite**: Minimal complexity and zero operational overhead, but limited concurrency.
- **PostgreSQL**: High concurrency and scalability, but requires running and maintaining a daemon.

#### Decision Rule / Recommendation
- Choose **SQLite** if: The app is a local single-user CLI where zero-config portability is priority.
- Choose **PostgreSQL** if: The app will be deployed as a multi-user web service with high concurrent writes.

Example 2: Ambiguous or Missing Input

Input:

Compare Redis.

Output:

### Technical Comparison: Insufficient Options

- **Status**: Halted

Comparing alternatives requires at least 2 options. Please specify what you would like to compare Redis against (for example: Memcached, KeyDB, or PostgreSQL unlogged tables) and your key criteria.

Example 3: Expected Final Output

Output:

### Technical Comparison: Zod vs Yup for Form Validation

#### Comparison Matrix
| Criterion | Option A: Zod | Option B: Yup |
| :--- | :--- | :--- |
| **TypeScript Inference** | High: Native `z.infer<typeof schema>` without duplicate types. | Moderate: Requires explicit type bridging in complex schemas. |
| **Bundle Size** | Medium: ~12 KB minzipped. | Medium: ~14 KB minzipped. |

#### Key Trade-offs
- **Zod**: Superior static type inference in modern TypeScript codebases.
- **Yup**: Established ecosystem in older React Formik applications.

#### Decision Rule / Recommendation
- Choose **Zod** for modern TypeScript projects.
- Choose **Yup** if maintaining legacy Formik codebases already configured for Yup.