Estimate

Skill pvnarp/agent-skills/skills/estimate

Skills I use with Claude Code across my projects. Architecture, code review, testing, security, deployment, and more.

Install

npx -y skills add pvnarp/agent-skills --skill estimate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 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.

What its author says it does

Copied from the file, not written here

Breaks down work into estimable units and identifies risks. Produces task breakdowns with complexity assessment, dependency mapping, and risk flags. Use when planning sprints, estimating features, or scoping projects.

SKILL.md

3.3 KB, as published. Nobody here has run it

Work Estimation

Estimates are communication tools, not promises. The goal is shared understanding of scope and risk, not precision.

Step 1: Break Down

Decompose the work into tasks where each task is:

Independently deliverable - produces a testable result
Small enough to reason about - if you can't explain what it takes, it's too big
Clear on "done" - you know when it's finished

Task Template

TASK: [what]
DEPENDS ON: [other tasks, or "none"]
COMPLEXITY: S / M / L / XL
UNKNOWNS: [what you don't know yet]
DONE WHEN: [specific, verifiable condition]

Size Guide

Size	Meaning	Typical Scope
S	Well-understood, straightforward	Single file change, clear pattern to follow
M	Some decisions, moderate scope	New endpoint, new component, new test suite
L	Significant scope, some unknowns	New system/module, integration, refactor
XL	Many unknowns, cross-cutting	New architecture, platform migration, multi-team

Step 2: Identify Risks

Risk Type	Signal	Impact
Unknown-unknowns	"I think this should work"	2-5x estimate
External dependency	Waiting on another team, API, approval	Blocked time
First-time technology	Team hasn't used this before	Learning curve
Unclear requirements	"We'll figure it out as we go"	Rework
Integration complexity	Multiple systems need to change together	Coordination overhead

Step 3: Map Dependencies

[Task A] ─── no deps ──→ can start immediately
[Task B] ─── depends on A ──→ blocked until A done
[Task C] ─── no deps ──→ can start immediately (parallel with A)
[Task D] ─── depends on B + C ──→ blocked until both done

Identify the critical path - the longest chain of dependent tasks. That's your minimum timeline.

Step 4: Flag What You Don't Know

The most important part of an estimate is what's NOT included:

EXCLUDED FROM ESTIMATE:
- [assumption that might be wrong]
- [scope that's unclear]
- [external dependency timeline]
- [testing/QA time if not included]

Output Format

## [Feature/Project Name]

### Tasks
| # | Task | Size | Depends On | Risk |
|---|------|------|-----------|------|
| 1 | [task] | S | - | - |
| 2 | [task] | M | 1 | [risk] |
| 3 | [task] | L | - | [risk] |

### Critical Path
[task 1] → [task 2] → [task 4]

### Risks
- [risk] - [mitigation]

### Assumptions
- [assumption that affects the estimate]

### Not Included
- [explicit exclusion]

Anti-Patterns

Padding instead of breaking down: If you need 3x buffer, you don't understand the work yet. Break it down further.
Estimating without looking at the code: Read the relevant code first.
Anchoring on the happy path: Include time for edge cases, testing, review, and deployment.
Estimating someone else's work: The person doing the work should estimate it.