# Skill: realistic-eta Stops Claude from saying "should be quick" when the actual delivery will take three times longer. ## To install 1. Save this file to `~/.claude/skills/realistic-eta/SKILL.md` 2. Restart Claude Code 3. Trigger with `/realistic-eta`, `/eta`, `realistic estimate`, or `how long will this really take` --- --- name: realistic-eta description: "Stop overestimating execution speed. Apply this whenever you're about to commit to a time estimate, scope a task, or say 'should be quick.' Triggers on /realistic-eta, /eta, 'realistic estimate', 'how long will this really take', 'don't sandbag me', or any time you're tempted to write 'quick', 'small', 'simple', or 'easy' in your own response." user-invocable: true trigger: /realistic-eta --- # Realistic ETA The number-one way Claude burns trust with operators is by saying "this should take 5 minutes" when the actual delivery is 45. Most of the time the optimism feels generous, even helpful. It's not. It blows the user's plan for the next hour, makes every subsequent commitment feel cheap, and accumulates into a pattern of un-reliability that's hard to climb out of. This skill is the calibration layer. ## When to apply - Before committing to any timeline, even casually - Before saying "should be quick" or "give me a sec" - Whenever the user asks "how long will this take" - Whenever you're estimating a multi-file change, refactor, debug session, or build - Whenever you catch yourself about to write the words `quick`, `small`, `simple`, `easy`, or `just` in your own output ## The rules ### Rule 1 — Take your honest first guess. Then double it. If your gut says 30 minutes, say 60. The 30-minute answer is what feels right; the 60-minute answer is closer to what actually happens. The hidden cost is hidden work — context-switching, file reads you forgot about, edge cases, dependency surprises, the verify pass that takes as long as the build pass. ### Rule 2 — Distinguish "code-time" from "verify-time." Writing the change might take 10 minutes. Verifying it works (typecheck, build, manual test, screenshot, hard-refresh, regression check on adjacent features) often takes the same again. Estimate both, sum them, then apply Rule 1. ### Rule 3 — Reject vague qualifiers. `Quick`, `small`, `simple`, `easy`, `just` — these are red flags in your own output. If you're tempted to use one, replace it with a specific number even if you have to invent it. Numbers force commitment; vague qualifiers hide overconfidence. ### Rule 4 — Name what could blow up. Before locking an estimate, list 1–3 specific things that could double the time: - "If the existing CSS conflicts, +20 min." - "If the test fixtures need updating, +30 min." - "If we need a new endpoint vs reusing one, +1 hour." This forces you to model risk explicitly instead of hand-waving past it. ### Rule 5 — Round up, not down. 23 min → "~30 min." 47 min → "~60 min." 1h45m → "~2 hours." Never round down. The mental shortcut "well it's basically half an hour" loses 7 minutes every time you use it; that's an hour-and-change of accumulated optimism per ten estimates. ### Rule 6 — If the task is genuinely small, say so with a number. Not all estimates should be inflated. A one-line CSS fix really is 2 minutes. The rule isn't "always say it'll take longer" — it's "stop hiding behind vague qualifiers and stand by a specific number you'd be willing to be measured against." ## Output format When asked for an ETA, respond: ``` Estimate: ~60 minutes total. - Code: 20 min - Verify: 20 min - Buffer for risk: 20 min Risks that could double this: - [specific risk 1] - [specific risk 2] ``` If you catch yourself mid-sentence about to write "should be quick" — stop. Run this skill. Replace with a number. ## What this skill is NOT - Not a worst-case-scenario generator. Adding infinite buffer "just to be safe" is its own failure mode and dilutes the signal. - Not a substitute for actually breaking down complex tasks into observable steps. If the work is genuinely uncertain, say so and propose a smaller scope you can estimate confidently. - Not a license to sandbag. The goal is calibration, not pessimism. ## Self-check before returning an estimate 1. Did I round up to the nearest natural unit (15 min / 30 min / hour)? 2. Did I include verify-time, not just code-time? 3. Did I name 1–3 specific risks that could double this? 4. Would I be willing to be measured against this number? 5. Did I avoid `quick`, `small`, `simple`, `easy`, `just`? If any answer is no — rewrite before sending.