Turn a Feature Request Into an Honest Estimate Range

A two-day estimate becomes six when the request hides integration work, migration rules, product decisions, or one dependency nobody inspected. The fix is not padding. It is naming the unknowns before naming the date.

This guide belongs to reel R092. Comment ESTIMATE for the matching module and runnable starter.

Define the boundary before building

Input: feature request, current code evidence, dependencies, acceptance criteria, known constraints, team availability, and delivery deadline.

Output: an assumption ledger, unknowns list, discovery spikes, estimate range, confidence, re-estimation triggers, and excluded work.

The starter keeps exact checks in code and gives Claude only the reviewable drafting work. Dry-run is the default. Live mode can call Anthropic's Messages API, but it still returns a draft and performs no external action.

Paste this boundary into Claude Code before asking for implementation:

Workflow: Turn a Feature Request Into an Honest Estimate Range
Input: feature request, current code evidence, dependencies, acceptance criteria, known constraints, team availability, and delivery deadline
Output: an assumption ledger, unknowns list, discovery spikes, estimate range, confidence, re-estimation triggers, and excluded work

Map the trigger, strict input fields, deterministic code checks, Claude drafting step, approval gate, failure queue, and saved evidence. Use null for missing facts. Do not change code or call an external service yet.

The modules that matter

Define the outcome

Write the user-visible done state, acceptance checks, non-goals, and dependencies. If two people can read the request and build different things, it is not ready to estimate.

Price the unknowns

Separate known implementation slices from discovery spikes. Give each assumption an evidence link, confidence, and a trigger that would force re-estimation.

Return a range

Use completed similar work as the base. State the likely range, confidence, availability assumptions, and what would move either end. A single date can still be a target, but it should not pretend to be certainty.

Rules worth keeping beside the code

Estimate a defined outcome rather than a one-line request.
Separate implementation work from discovery work.
Attach confidence to evidence and named assumptions.
Re-estimate when a written trigger changes the plan.

The dangerous version is presenting a single date as certainty, hiding integration unknowns, counting unavailable people, or padding an undefined scope. The pack deliberately stops at a draft so a person can inspect those boundaries before enabling anything real.

Test the ugly paths

Highest-risk unknown has a bounded spike.
Dependencies have named owners.
Estimate excludes stated non-goals.
Availability matches the calendar.
A changed assumption triggers re-estimation.

The final verification is concrete: Run the smallest discovery spike for the highest-risk unknown, update the estimate with its result, and compare the range with completed similar work.

Use this prompt to turn the evidence into acceptance tests:

Design tests for Turn a Feature Request Into an Honest Estimate Range using only the attached fictional fixtures.
Cover the normal path, missing input, malformed input, a repeated event, a permission failure, a dependency failure, and the named safety boundary.
For each test return: input, expected state, prohibited side effect, and evidence to save.
Do not execute external actions.

Run the pack locally

The ZIP is a complete Node 22 starter with no third-party npm dependency. It includes an importable n8n webhook, Docker Compose, GitHub Actions validation and manual-run workflows, deterministic samples, and tests.

npm test
npm run validate
npm run sample
cp .env.example .env
docker compose up --build

Only set WORKFLOW_MODE=live, ANTHROPIC_API_KEY, and ANTHROPIC_MODEL after the dry-run output and tests make sense for your system. Keep real secrets in the environment, never in the n8n export.

Download the runnable pack

Start with the fictional dry-run. It validates the input and returns a reviewable draft without changing code, production data, customer accounts, or an external service.

Before enabling a real action

Replace every fictional fixture, assign the approval owner, define the duplicate key, set a timeout and retry rule, and save the original evidence. Then test one failure on purpose. If the workflow cannot stop visibly and replay safely, it is not ready to act.