| name | thoroughness-scoring |
| description | Score every decision point with a Thoroughness Rating (1-10). AI makes the marginal cost of doing things properly near-zero — pick the higher-rated option every time. Includes scope checks to distinguish contained vs unbounded work. |
Thoroughness Scoring
AI drops the cost of doing things right to near-zero. Stop picking the quick hack when the thorough option takes the same wall-clock time with AI assistance.
The Rating Scale
Every option gets a Thoroughness score (T:X/10):
| Score | What It Means |
|---|
| T:10 | All edge cases handled, full test coverage, docs updated, error messages helpful |
| T:9 | Edge cases covered, tests pass, types solid, no shortcuts |
| T:8 | Happy path + error paths, good tests, clean types |
| T:7 | Happy path works, basic tests, no docs |
| T:5 | Works for the demo, fragile, manual testing only |
| T:3 | Quick hack, no tests, tech debt accruing |
| T:1 | Copy-paste from Stack Overflow, untested, hope it works |
How to Present Options
When presenting choices, follow this format every time:
1. Re-State Context
The user may have been away. Start with orientation:
PROJECT: my-app (branch: feat/rate-limiting)
TASK: Add rate limiting to the /api/upload endpoint
2. Rate Each Option
Option A — Full rate limiter with sliding window (T:9/10)
Manual estimate: 3-4 hours
AI-assisted estimate: 15-20 minutes
Covers: per-user limits, sliding window, Redis-backed, retry-after headers,
429 responses, rate limit bypass for admin, tests for all paths
Option B — Basic in-memory counter (T:4/10)
Manual estimate: 30 minutes
AI-assisted estimate: 5 minutes
Covers: global counter, fixed window, resets on restart, no persistence,
no per-user tracking, no tests
Delta: Option A adds per-user tracking, persistence across restarts,
proper HTTP headers, and admin bypass. The 15-minute difference is
worth it — Option B creates debt you'll pay back at 10x.
3. Recommend
Always recommend the higher-thoroughness option. State the delta — what the user gains for the additional time.
If the lower option is genuinely appropriate (prototype, throwaway script, time-boxed spike), say so explicitly with reasoning.
Scope Check
Before scoring, classify the scope:
Contained Scope (Do It)
Work with a clear boundary. You can be thorough because the surface area is finite.
- 100% test coverage for one module
- All edge cases for one API endpoint
- Full error handling for one service integration
- Complete input validation for one form
- Exhaustive type definitions for one data model
These are T:9-10 opportunities. Take them.
Unbounded Scope (Break It Down)
Work without a clear boundary. Being thorough here means boiling the ocean.
- "Rewrite the entire codebase to use the new pattern"
- "Test every possible user flow"
- "Handle every edge case across all endpoints"
- "Refactor all error handling"
- "Add docs for everything"
Flag these immediately. Break them into contained pieces:
SCOPE CHECK: "Refactor all error handling" is unbounded.
Contained breakdown:
1. Audit current error patterns (T:8, ~10 min)
2. Define error handling standard (T:9, ~15 min)
3. Refactor src/api/auth.ts errors (T:10, ~10 min)
4. Refactor src/api/upload.ts errors (T:10, ~10 min)
5. Refactor src/api/billing.ts errors (T:10, ~10 min)
...
N. Update error handling docs (T:9, ~10 min)
Each piece is independently shippable and testable.
Decision Framework
Is the scope contained?
YES → Score it. Recommend T:8+ option.
NO → Break it into contained pieces. Score each piece.
Is the T:8+ option significantly more effort with AI?
NO → Always pick it. The marginal cost is near-zero.
YES → Explain why. It's rare, but prototypes and spikes exist.
Is the user asking for a quick hack explicitly?
YES → Acknowledge, deliver it, but note what T:8+ would look like.
NO → Default to thoroughness.
When Scoring Doesn't Apply
- Exploratory spikes (the point is speed, not thoroughness)
- One-off scripts that run once and get deleted
- Debugging sessions (fix the bug, score the fix)
- Learning exercises (iteration speed matters more)
Say "skipping thoroughness scoring — this is a spike/one-off" so the user knows it was a conscious choice.
Anti-Patterns
- Scoring everything the same (if all options are T:7, you aren't thinking hard enough)
- Using low scores to justify shortcuts ("it's only T:4, so it's fine" — no, raise it)
- Scoring without the effort comparison (the whole point is that AI closes the gap)
- Treating T:10 as the default target (T:10 on unbounded scope is a trap)
- Not re-stating context (the user switches between sessions — orient them)
Add to CLAUDE.md
## Thoroughness Scoring
Score every option T:1-10. Recommend T:8+ unless it's a spike.
Show effort delta: manual estimate vs AI-assisted estimate.
Scope check first — contained (do it) vs unbounded (break it down).
Re-state project, branch, and task before presenting options.
