Skip to content
Back to skills

Planning Estimate

ASecurity

Sizing work as ranges, not points: per-task estimates, the critical path total, buffer, schedule, range drivers, and the conditions that would break it.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 19, 2026
ai-agentsgoexpress

Security analysis

A100/100

Pro scans all 5 files and shows the line behind each finding

Scanned September 19, 2026

npx -y skills add simota/planning-skills --skill planning-estimate --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Planning Estimate?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Planning Estimate
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/simota-planning-estimate/badge)](https://www.skillsdirectory.com/skills/simota-planning-estimate)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: planning-estimate
description: "Sizing work as ranges, not points: per-task estimates, the critical path total, buffer, schedule, range drivers, and the conditions that would break it."
allowed-tools: Read, Grep, Glob, Write, Edit
---
<!-- planning:contract -->

## Owns

How long, expressed as a range with the reasons it is that wide. **The drivers
of the range are the deliverable; the number is a summary of them.**

Phases: `REFERENCE → SIZE → AGGREGATE → BUFFER → STRESS`.

## Before starting

- **Require shaped tasks.** A task with no observable done condition cannot be
  sized — you would be estimating a description
- **Find comparable actuals first.** An estimate anchored on something that
  actually happened beats one anchored on how the work feels; where no
  comparable exists, say so and widen the range
- **Establish the real capacity, not the headcount.** State the assumed
  productive fraction and what it is based on
<!-- deliver:sizing -->
- **Declare the tier before anything else**, read off the work and stated at the
  top of the deliverable. `S` — under a day, reversible: one brief in the
  response, **no files, no handoff**. `M` — multi-day, single owner: the brief
  and the plan. `L` — multi-week, multi-owner, or hard to reverse: the full set,
  ending in risks and a review verdict. **Over-planning an `S` is a failure of
  the same weight as under-planning an `L`**
- **The planning gate stops the run at the phase that owns the condition** — the
  goal cannot be stated in one sentence without "and", no success criterion is
  measurable, a load-bearing assumption is cheap to verify and unverified, or the
  person has already decided and is asking for execution; `_planning/SIZING.md`
  says which phase evaluates each. A gate that fires is reported, not worked around
- **`excludes` may not be empty** and execution waits on an empty
  `open_questions`. In planning, an exclusion becomes a non-goal, and a non-goal
  written down is the cheapest scope control there is (`_planning/SIZING.md`)
- **A term with two meanings, or a concept with two names, is a question, never
  a silent choice** — one question with its default, the answer into the
  brief's `terms` and `.agents/glossary.md`, and the glossary's names only from
  then on (`_planning/SIZING.md` § Terms)
<!-- /deliver:sizing -->

## Decide first

| Situation | How to proceed |
|---|---|
| Choosing a method, sizing the buffer, or converting to elapsed time | [sizing](playbooks/sizing.md) |
| Writing the deliverable | [template](reference/template.md) |
| About to give a number | [traps](playbooks/traps.md) |
| Effort and calendar time are being conflated | Separate them. **Two days of work spanning a review cycle and a weekly deploy is two days of effort and eight days of elapsed time** — this is the most common scheduling error there is |
| Combining task ranges into a total | [aggregation](reference/aggregation.md) — **means add, σ adds in quadrature.** Summing the pessimistic values put the total at p100 in every simulated run |
| Several tracks run in parallel | They do not add, and they do not take the longest either: everything must finish, so the merge lands on the slowest draw. Eight equal chains slipped the p50 by 20% with none of them late ([aggregation](reference/aggregation.md)) |
| Someone wants the number lower | Reducing scope changes the estimate. Wishing does not. Offer the scope cut, not a smaller number |
| The range is uncomfortably wide | That is information. Narrowing it without new facts is fabrication |
| The estimate is written and about to be handed over | Leave the scoring row empty and present — task, range, midpoint, `open`. **A calibration record starts as blanks in the estimate**, because nobody creates it later |
<!-- deliver:values -->
- Ties break by `_planning/VALUES.md`, read top to bottom: honesty over
  completeness · mechanism over intent · **deciding over deferring** ·
  subtraction over addition · reversibility over optimality · the human decides
  what, the agent decides how. Against all of them: **a harness that is correct
  and avoided has failed** — planning is the easiest of all work to perform
  rather than do, so when the artifact set costs more than the work, say so
<!-- /deliver:values -->

## Always / Never

- Always: emit `[optimistic / likely / pessimistic]` with a confidence level and
  its reason. **Never a single number**
- Always: make the buffer a named, separate, justified line with a percentage and
  a reason. **Padding hidden inside task estimates destroys the information the
  range carries**
- Always: state the top three drivers of the range's width, in order
- Always: name the conditions under which the estimate breaks entirely
- Never: negotiate an estimate downward to fit a date
- Never: present a schedule without saying which assumptions about capacity it rests on
- Never: estimate a task you cannot describe the done condition of

## Verify with

An estimate is `[verified]` only where it is anchored on a cited comparable —
with the pointer to it. Everything else is `[assumed]`, which is the normal case
and is stated rather than dressed up by the precision of the number.

- **Confidence is per estimate, not per document.** `Low` confidence on a task
  on the critical path is a blocking finding, not a footnote
<!-- deliver:report -->
- **Tag every factual claim in a decision-bearing section**, exactly one:
  `[verified: <pointer>]` — read, run, or cited, with the pointer ·
  `[assumed]` — needs a matching `A-n` and a cost of being wrong ·
  `[unknown]` — needs a matching `Q-n`. **An untagged claim is a defect**, and a
  pointer-less `[verified]` is `[assumed]` wearing a better tag
- **Never emit a single-point estimate**, and attach `High | Medium | Low`
  confidence with a one-line reason. `Low` on a load-bearing item is a blocking
  finding, not a footnote
- **Report `status`**: `DONE` (every claim tagged, every load-bearing assumption
  verified or costed, zero `UNVERIFIED`) / `PARTIAL` / `BLOCKED`
- **Every residual is `BLOCKED` / `OUT-OF-SCOPE` / `DEFERRED` / `UNVERIFIED`**
  and appears in the handoff's `open` with its `A-n` or `Q-n`. `UNVERIFIED` is
  the one that matters: every other class is visible in the plan, while **an
  unverified assumption reads exactly like a fact**
- **Never omit the sweep** — markers against `open`, claims against claims
  tagged: `swept, 0 markers; 22 claims / 22 tagged` (`_planning/CONTRACT.md`)
<!-- /deliver:report -->
<!-- deliver:score -->
- **A range is scored, or it never meant anything.** Whatever was given one
  number-pair gets one outcome once the work closes — `within`, `under`,
  `over`, `open`, `abandoned` — and the ratio of actual to midpoint beside it.
  Scored on the original range, never the revision. **A record of ten `within`
  in ten is a defect**: ranges that cannot be wrong carry no information
  (`_planning/CALIBRATION.md`)
<!-- /deliver:score -->

## Done when

Every estimate is a range with confidence and a reason, effort and elapsed time
are separate, the total came from the critical path rather than a sum, the
buffer is a named line, and the three widest range drivers are stated in order.
<!-- deliver:surface -->
- **Say what the moment needs.** Start: one line naming what will be planned and what
  is excluded. Mid-run: a line when the reader must act now — a discovered constraint
  that invalidates the plan, a blocked path, work that would grow the scope. Asking counts
  as speaking: one question, the decision it unblocks, the default taken if nobody answers
- **End with the answer in one line** — status, tier and what was decided; then the sweep
  line, then one line per residual a human must decide, then what is next. A reader who
  stops after the first line has the result
- **The artifacts and the handoff are the record, the report is the view.** The brief, the
  plan and the per-claim tags live in files and are shown when asked
- **Short enough to be read to the end**, plus the artifacts — named, never
  restated. Too long means cutting content, not reformatting it: no restatement of the
  request, no closing summary (`_planning/REPORT.md`)
- **Not bigger than it is.** The requested scope is the deliverable; thought
  goes deeper into the one thing asked, never wider. **A real problem is the
  exception** — something that would break, is unsafe, or rests on a false
  premise is explained in full (`_planning/REPORT.md`)
<!-- /deliver:surface -->

Files in this skill

  • SKILL.md8.4 KB
  • playbooks/sizing.md2.2 KB
  • playbooks/traps.md1011 B
  • reference/aggregation.md6 KB
  • reference/template.md965 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.