Estimation techniques
Skill Amey-Thakur/AI-SKILLS/skills/research/estimation-techniques
Estimate unknown quantities with Fermi decomposition, reference classes, and honest error bars. Use when you need a number for a decision and no exact figure exists.From its SKILL.md
npx -y skills add Amey-Thakur/AI-SKILLS --skill estimation-techniquesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.7 KB, 814 tokens by cl100k_base, as published. Nobody here has run it
Estimation techniques
Many decisions need a number that nobody knows exactly: how much traffic, how long the project, how big the market. Good estimation gets within an order of magnitude fast by decomposing the unknown into knowable parts, anchoring on real reference data, and stating the uncertainty honestly rather than pretending precision.
Method
- Decompose with Fermi estimation. Break the unknown into a product of factors you can each estimate to within a factor of a few: "requests per day = users x sessions per user x requests per session". Errors in independent factors partially cancel, so a product of rough estimates is often within 2-3x of truth (the classic "piano tuners in Chicago" method: see the decomposition instinct in first-principles-thinking, capacity-planning's load model).
- Anchor on reference classes, not intuition. Instead of estimating this project's duration from scratch, ask how long similar projects actually took (reference-class forecasting): the outside view beats the inside view, which is systematically optimistic (the planning fallacy). "Projects like this took 3-6 months" is more reliable than "this one feels like 6 weeks" (see the optimism correction in status-updates).
- Bound with best/worst/likely. Estimate a range, not a point: the plausible low, high, and most-likely: because a single number implies a precision you do not have and invites false confidence. The range is the honest answer, and its width tells the decision-maker how much the estimate can be trusted (see tradeoff-analysis's sensitivity).
- State error bars and carry them. An estimate without uncertainty is a lie of precision; "roughly 10,000, could be 5,000-20,000" is more useful than "10,000" because it tells you whether the decision is robust to the uncertainty. Propagate the uncertainty through the decision (if the answer flips within the error bars, you need a better estimate: see experiment-design-basics).
- Sanity-check against a second method and known bounds. Estimate the same quantity a different way and see if they agree (order-of-magnitude agreement is reassuring; wild disagreement means a factor is wrong); check against hard limits (an estimate exceeding the total market or the physical maximum is wrong somewhere). Cross-checking catches the decimal-place and unit errors that single estimates hide.
- Calibrate over time. Track your estimates against actuals (see decision-journals): are your ranges right about as often as their confidence claims, or are you overconfident (ranges too narrow: the common failure)? Calibration is trainable, and estimators who track their record get measurably better at sizing uncertainty.
Boundaries
- Estimation gets you a defensible number for a decision, not a precise fact; treat estimates as inputs with uncertainty, not truths, and revisit them as real data arrives (see capacity-planning's re-forecasting).
- Some quantities have fat tails or fundamental unpredictability (novel systems, black-swan events) where point estimates mislead badly; there, plan for ranges and robustness rather than betting on the estimate (see the degradation planning in scalability-planning).
- Anchoring is a double-edged tool: a bad reference class or a planted number biases the estimate. Choose reference classes deliberately and beware anchors others supply (see the negotiation anchoring in salary-negotiation).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most task breakdown skills give in 814 tokens
Counted across 221 of the 230 authors here whose files we hold, read 2026-09-06
- Write acceptance criteria for every taskin 32 of 221, across 30 files
- Add checkpoints every two to three tasksin 18 of 221, across 16 files
- Schedule high-risk tasks earlyin 16 of 221, across 14 files
- Slice work vertically into complete feature pathsin 16 of 221, across 14 files
- Include verification steps in every taskin 15 of 221, across 13 files
- Map dependencies between componentsin 14 of 221, across 12 files
- Get human approval before implementingin 14 of 221, across 12 files
- Enter read-only plan mode before writing codein 10 of 221
- Read the spec and codebase before planningin 9 of 221, across 7 files
- Map the dependency graph before ordering tasksin 8 of 221
- Break any task touching more than five filesin 8 of 221
- List each task's dependenciesin 7 of 221
Said here and by no other author read
- anchor on reference classes instead of intuition
- estimate a best, worst, and most-likely range
- state error bars with every estimate
- propagate uncertainty through the decision
- sanity-check the estimate with a second method
- check estimates against hard physical or market bounds
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.