Present Tradeoffs Skill

Trigger

Use when there are multiple valid approaches to a problem. Force explicit consideration of alternatives.

The Problem

Karpathy: "They don't present tradeoffs, they don't push back when they should."

LLMs pick an approach and run with it. This skill forces consideration of alternatives and their tradeoffs.

Process

Step 1: Identify the Decision Point

Before implementing, ask: "Is there more than one reasonable way to do this?"

If yes, stop and enumerate the options.

Step 2: List All Viable Options

Don't filter yet. List every approach that could work:

## Options for User Session Storage

### Option A: JWT in localStorage
### Option B: JWT in httpOnly cookie
### Option C: Server-side sessions with Redis
### Option D: Server-side sessions with database

Step 3: Evaluate Each Option

For each option, consider:

Step 4: Make Tradeoffs Explicit

## Recommendation: Option B (JWT in httpOnly cookie)

### Why
- Best balance of security and simplicity
- Immune to XSS attacks (main threat vector)
- CSRF mitigated with SameSite=Strict

### What We Give Up
- Slightly more complex mobile integration (need to handle cookies)
- Token can't be easily accessed from JavaScript (intentional)
- Slightly larger request payload (cookie sent with every request)

### What We Gain
- Automatic CSRF protection with SameSite
- No JavaScript access = immune to XSS token theft
- Built-in expiration handling

### Alternative Considered
Option C (Redis sessions) would be more secure but adds infrastructure complexity. Recommended if we later need session revocation.

Step 5: Get Explicit Approval

Present the tradeoffs to stakeholders. Don't assume the "obvious" choice is correct.

Tradeoff Categories to Consider

Performance vs Simplicity

• Caching adds speed but complexity
• Denormalization speeds reads but complicates writes
• Premature optimization is the root of all evil

Security vs Usability

• Shorter sessions are safer but annoy users
• 2FA is more secure but adds friction
• Strict validation catches attacks but may reject valid input

Flexibility vs Complexity

• Generic solutions handle more cases but are harder to understand
• Configuration options add flexibility but increase surface area
• Abstractions enable change but obscure behavior

Consistency vs Availability (CAP)

• Strong consistency means potential unavailability
• Eventual consistency means potential stale reads
• There is no free lunch

Build vs Buy

• Building gives control but costs time
• Buying saves time but adds dependencies
• Open source is "free" but still has maintenance cost

Template

## Decision: [What needs to be decided]

### Context
[Why this decision matters]

### Options Considered

#### Option A: [Name]
**Pros:** [List]
**Cons:** [List]
**Best when:** [Conditions]

#### Option B: [Name]
**Pros:** [List]
**Cons:** [List]
**Best when:** [Conditions]

### Recommendation
[Which option and why]

### Tradeoffs Accepted
[What we're giving up]

### Revisit If
[Conditions that would change this decision]