Task Estimator
Decompose until pieces are real, count the invisible work, give a range, name the unknown that makes it 3x. Estimate the work, not the deadline.
v1.0.0 · ~657 tokens · ⬇ 0 · Updated July 6, 2026
What it does
Estimates work honestly: decomposes into understood pieces, counts the invisible work that kills estimates (tests, error handling, review+rework, integration, migration, deploy), sizes as a range (optimistic/likely/pessimistic) from reference not intuition, and surfaces the risks/assumptions/unknowns that cause the 3x. Estimates the work then compares to the deadline — never the reverse — and flags the top unknown for a spike.
Example uses
Estimate a feature honestly
A stakeholder wants a date, and your gut says two weeks — which usually means it is not two weeks.
Break down and estimate adding SSO (SAML, starting with Okta) to our Rails app. Decompose into pieces of half a day to two days each, include the invisible work — tests, error handling, review rework, the IdP configuration docs — give me optimistic, likely, and pessimistic totals, and name the single unknown most likely to make this 3x.Break down a vague ticket
The ticket says 'migrate the notification system' and nobody on the team can size it as written.
Decompose 'migrate notifications from our cron-based system to event-driven' into concrete, independently sizable pieces. State every assumption you're making about the current system, flag anything that depends on the platform team, and tell me which unknown deserves a one-day spike before we commit to any number.Sanity-check a committed deadline
The launch date was promised before the work was scoped, and you need the truth on paper before the gap becomes a crisis.
Marketing committed to shipping our public API in six weeks. Estimate the work honestly — endpoints, auth, rate limiting, docs, versioning, and the production-ready tail — then compare the range against the six-week deadline. Estimate first, compare second; do not anchor to the deadline.Install
# 1. Create the skill folder in your Claude setup mkdir -p ~/.claude/skills/task-estimator # 2. Download SKILL.md into it (or move the file you just downloaded) # → ~/.claude/skills/task-estimator/SKILL.md # 3. Claude Code auto-discovers it on next launch.
Inside the skill
---
name: task-estimator
description: Break down work and estimate it realistically, with the risks named. Use when planning a feature, sizing a task, giving a timeline, or asked "how long will this take", "break this down", "estimate this work". Decomposes, sizes honestly, and surfaces the unknowns that blow up estimates.
---
# Task Estimator
Estimates blow up because of the work nobody listed and the unknowns nobody flagged. Decompose
until the pieces are real, size honestly, and name what could make it 3x. An estimate without
its risks is a guess with a number.
## Decompose first (you can't estimate a blob)
- Break the work into pieces small enough that each is understood and independently sized —
roughly half-a-day to a couple of days each. A "2 weeks" estimate on an undivided task is fiction.
- **Include the invisible work**, which is where estimates die: tests, error handling, edge
cases, code review + rework, integration, migration/backfill, docs, deployment, and the
"make it actually production-ready" tail. The happy-path code is often the small part.
## Size honestly
- Estimate effort per piece from similar past work if you have it (reference beats intuition).
- Give a range, not a point: optimistic / likely / pessimistic. A single number pretends to a
certainty that doesn't exist. The spread communicates the uncertainty.
- **Don't anchor to the hoped-for deadline.** Estimate the work, then compare to the deadline —
not the reverse. Wishful estimates just move the disappointment later.
## Surface the risks (the real value)
- **Unknowns**: the pieces you don't understand yet — a new API, an unclear requirement, a
dependency on someone else. These have the widest spread; flag them as the top risk and
consider a spike to de-risk before committing.
- **Assumptions**: state them ("assumes the API supports X", "assumes no data migration"). A
broken assumption is where the 3x comes from.
- **Dependencies**: work blocked on other people/teams/decisions — outside your control, so outside your estimate's reliability.
## Rules
- Decompose until the pieces are real; you can't honestly size what you haven't broken down.
- Count the invisible work (tests, review, edges, deploy) — it's usually most of the total.
- Give a range and name the unknowns; estimate the work, don't reverse-engineer the deadline.
- The biggest unknown deserves a spike before a commitment, not a confident number.
## Output
The breakdown (pieces + size each), a total range (optimistic/likely/pessimistic), the top
risks and assumptions, and the one or two unknowns worth de-risking first.
Changelog
- v1.0.02026-07-03Initial clean-room write.
Frequently asked questions
Is Task Estimator free?
Yes. Task Estimator is free to download and MIT-licensed.
Where do I install Task Estimator?
Place the SKILL.md file in ~/.claude/skills/task-estimator/ and Claude Code auto-discovers it on next launch.
How many tokens does Task Estimator use?
About 657 tokens — it is designed to be token-lean.
We're developers and SaaS builders who use these tools daily in production. Every review comes from hands-on experience building real products — DealPropFirm, ThePlanetIndicator, PropFirmsCodes, and many more. We don't just review tools — we build and ship with them every day.
Written and tested by developers who build with these tools daily.