From code-practices
Present multiple approaches with explicit tradeoffs before committing to one. Use when there are multiple valid solutions to a problem.
How this skill is triggered — by the user, by Claude, or both
Slash command
/code-practices:tradeoffsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use when there are multiple valid approaches to a problem. Force explicit consideration of alternatives.
Use when there are multiple valid approaches to a problem. Force explicit consideration of alternatives.
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.
Before implementing, ask: "Is there more than one reasonable way to do this?"
If yes, stop and enumerate the 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
For each option, consider:
| Criterion | Option A | Option B | Option C | Option D |
|---|---|---|---|---|
| Security | XSS vulnerable | CSRF vulnerable | Most secure | Secure |
| Scalability | Excellent | Excellent | Needs Redis | DB load |
| Complexity | Simple | Medium | Medium | Simple |
| Stateless | Yes | Yes | No | No |
| Mobile support | Easy | Hard | Easy | Easy |
## 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.
Present the tradeoffs to stakeholders. Don't assume the "obvious" choice is correct.
## 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]
Guides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
npx claudepluginhub joshuarweaver/cascade-code-general-misc-2 --plugin rahulsub-code-practices-plugin