Compare multiple approaches, technologies, or implementations with trade-off analysis and recommendations
Compares technologies, tools, or approaches with detailed trade-off analysis and recommendations.
/plugin marketplace add C0ntr0lledCha0s/claude-code-plugin-automations/plugin install research-agent@claude-code-plugin-automations[option A] vs [option B] (for context)Systematically compare multiple approaches, technologies, tools, or implementations to help make informed decisions based on trade-offs and context.
$ARGUMENTS: The comparison query (e.g., "REST vs GraphQL", "Redux vs Zustand for React", "SQL vs NoSQL for e-commerce")When this command is invoked with /compare <option A> vs <option B> [context]:
/compare REST vs GraphQL for our API
Expected behavior:
Researches both REST and GraphQL current state (2025)
Analyzes project context (checks existing API if present)
Provides comprehensive comparison:
Comparison: REST vs GraphQL
| Aspect | REST | GraphQL |
|---|---|---|
| Data Fetching | Multiple endpoints, may over/under-fetch | Single endpoint, request exactly what you need |
| Performance | Can cache with HTTP caching | Requires additional caching layer |
| Versioning | URL versioning (/v1/, /v2/) | Schema evolution, no versioning |
| Learning Curve | Low, familiar to most devs | Medium, requires learning GraphQL concepts |
| Tooling | Mature (Swagger, Postman) | Excellent (GraphiQL, Apollo DevTools) |
| Error Handling | HTTP status codes | Errors in response body with 200 status |
| Type Safety | Requires OpenAPI/Swagger | Built-in with schema |
| Mobile-Friendly | Multiple requests may be needed | Fetch all data in one request |
| Real-time | WebSockets or SSE | Subscriptions built-in |
| Complexity | Low | Higher (schema, resolvers, N+1 problem) |
REST ✓ Pros:
✗ Cons:
GraphQL ✓ Pros:
✗ Cons:
REST
// Fetch user and their posts (2 requests)
const user = await fetch('/api/users/123');
const posts = await fetch('/api/users/123/posts');
GraphQL
# Fetch user and posts (1 request)
query {
user(id: "123") {
name
email
posts {
title
content
}
}
}
Choose REST if:
Choose GraphQL if:
Based on typical API needs:
Hybrid Approach: You can also use both:
/compare Redux vs Zustand vs Jotai for React state management
Expected behavior:
Checks current state management in project
Researches all three libraries (2025 versions)
Provides multi-way comparison:
Comparison: Redux vs Zustand vs Jotai
| Feature | Redux | Zustand | Jotai |
|---|---|---|---|
| Bundle Size | ~13KB (with RTK) | ~1KB | ~3KB |
| Boilerplate | High | Low | Low |
| Learning Curve | Steep | Gentle | Medium |
| TypeScript | Good (RTK) | Excellent | Excellent |
| DevTools | Excellent | Good | Good |
| Middleware | Extensive | Simple | Flexible |
| Performance | Good | Excellent | Excellent |
| Async | Redux Thunk/Saga | Built-in | Built-in |
| Atomic Updates | No | No | Yes |
Redux (with Redux Toolkit)
// Store setup
const counterSlice = createSlice({
name: 'counter',
initialState: { value: 0 },
reducers: {
increment: (state) => { state.value += 1; },
},
});
const store = configureStore({
reducer: { counter: counterSlice.reducer },
});
// Component usage
const count = useSelector((state) => state.counter.value);
const dispatch = useDispatch();
dispatch(counterSlice.actions.increment());
Zustand
// Store setup
const useStore = create((set) => ({
count: 0,
increment: () => set((state) => ({ count: state.count + 1 })),
}));
// Component usage (that's it!)
const { count, increment } = useStore();
Jotai
// Atom definition
const countAtom = atom(0);
// Component usage
const [count, setCount] = useAtom(countAtom);
setCount(count + 1);
Choose Redux if:
Choose Zustand if:
Choose Jotai if:
For new projects in 2025: Start with Zustand
Upgrade to Redux if you outgrow Zustand (rare).
/compare monorepo vs polyrepo for our team
Expected behavior:
Analyzes project context (team size, current setup)
Researches both approaches
Provides decision framework:
Comparison: Monorepo vs Polyrepo
| Aspect | Monorepo | Polyrepo |
|---|---|---|
| Code Sharing | Easy, direct imports | Requires publishing packages |
| Atomic Changes | Yes, change multiple packages in one commit | No, requires multiple PRs |
| Versioning | Simplified | Complex (each repo versioned separately) |
| CI/CD | Complex, requires smart caching | Simple, per-repo |
| Build Times | Slower (more code) | Faster (isolated) |
| Tooling | Requires monorepo tools (Nx, Turborepo) | Standard git workflows |
| Onboarding | One clone, see everything | Clone multiple repos |
| Access Control | Coarse-grained | Fine-grained per repo |
| Scaling | Can get large | Naturally bounded |
Monorepo ✓ Pros:
✗ Cons:
Polyrepo ✓ Pros:
✗ Cons:
Monorepo Tools:
Polyrepo Tools:
Choose Monorepo if:
Choose Polyrepo if:
[Based on detected team size and project structure]
For small teams (2-10 devs): Monorepo
For large organizations: Polyrepo or Monorepo per team
/compare class components vs functional components in React
Expected behavior: Provides historical context and current best practices with migration guidance.
# Comparison: [Option A] vs [Option B] [vs Option C]
## Quick Summary
[One-sentence summary of when to use each option]
## Overview
**[Option A]**: [Brief description]
**[Option B]**: [Brief description]
## Detailed Comparison
| Aspect | Option A | Option B |
|--------|----------|----------|
| [Criterion 1] | [Assessment] | [Assessment] |
| [Criterion 2] | [Assessment] | [Assessment] |
## Pros & Cons
### Option A
✓ **Pros**:
- [Pro 1]
- [Pro 2]
✗ **Cons**:
- [Con 1]
- [Con 2]
### Option B
✓ **Pros**:
- [Pro 1]
- [Pro 2]
✗ **Cons**:
- [Con 1]
- [Con 2]
## Code Examples
[Side-by-side code showing both approaches]
## When to Choose
**Choose [Option A] if:**
- [Criterion]
- [Criterion]
**Choose [Option B] if:**
- [Criterion]
- [Criterion]
## Recommendation
[Context-specific recommendation with rationale]
## Migration Path (if applicable)
[How to move from one to the other]
## Resources
- [Link to docs for Option A]
- [Link to docs for Option B]
Error: Unclear comparison.
Usage: /compare <option A> vs <option B> [context]
Examples:
/compare REST vs GraphQL
/compare Redux vs Zustand for React
/compare SQL vs NoSQL for e-commerce app
/compare microservices vs monolith
Note similarities and highlight subtle differences.
Explain why comparison doesn't make sense and suggest alternatives.
/compare Redux vs Zustand vs Jotai vs Context API
Compares multiple options (up to 4-5 recommended).
/compare PostgreSQL vs MongoDB for real-time chat app
Focuses comparison on specific use case.
/compare our current auth approach vs OAuth 2.0
Evaluates existing implementation against alternatives.
Pro Tip: Use /compare when deciding between options, /best-practice to learn the standard approach, and /research for deep dive into your choice.