estimate

When this skill is invoked:

Read the task description from the argument. If the description is too vague to estimate meaningfully, ask for clarification before proceeding.
Read CLAUDE.md for project context: tech stack, coding standards, architectural patterns, and any estimation guidelines.
Read relevant design documents from
```
design/gdd/
```
if the task relates to a documented feature or system.
Scan the codebase to understand the systems affected by this task:
- Identify files and modules that would need to change
- Assess the complexity of those files (size, dependency count, cyclomatic complexity)
- Identify integration points with other systems
- Check for existing test coverage in the affected areas
Read past sprint data from
```
production/sprints/
```
if available:
- Look for similar completed tasks and their actual effort
- Calculate historical velocity (planned vs actual)
- Identify any estimation bias patterns (consistently over or under)
Analyze the following factors:

Code Complexity:
- Lines of code in affected files
- Number of dependencies and coupling level
- Whether this touches core/engine code vs leaf/feature code
- Whether existing patterns can be followed or new patterns are needed
Scope:
- Number of systems touched
- New code vs modification of existing code
- Amount of new test coverage required
- Data migration or configuration changes needed
Risk:
- New technology or unfamiliar libraries
- Unclear or ambiguous requirements
- Dependencies on unfinished work
- Cross-system integration complexity
- Performance sensitivity
Generate the estimate:

markdown

## Task Estimate: [Task Name]
Generated: [Date]

### Task Description
[Restate the task clearly in 1-2 sentences]

### Complexity Assessment

| Factor | Assessment | Notes |
|--------|-----------|-------|
| Systems affected | [List] | [Core, gameplay, UI, etc.] |
| Files likely modified | [Count] | [Key files listed below] |
| New code vs modification | [Ratio, e.g., 70% new / 30% modification] | |
| Integration points | [Count] | [Which systems interact] |
| Test coverage needed | [Low / Medium / High] | [Unit, integration, manual] |
| Existing patterns available | [Yes / Partial / No] | [Can follow existing code or new ground] |

**Key files likely affected:**
- `[path/to/file1]` -- [what changes here]
- `[path/to/file2]` -- [what changes here]
- `[path/to/file3]` -- [what changes here]

### Effort Estimate

| Scenario | Days | Assumption |
|----------|------|------------|
| Optimistic | [X] | Everything goes right, no surprises, requirements are clear |
| Expected | [Y] | Normal pace, minor issues, one round of review feedback |
| Pessimistic | [Z] | Significant unknowns surface, blocked for a day, requirements change |

**Recommended budget: [Y days]**

[If historical data is available: "Based on [N] similar tasks that averaged
[X] days actual vs [Y] days estimated, a [correction factor] adjustment has
been applied."]

### Confidence: [High / Medium / Low]

**High** -- Clear requirements, familiar systems, follows existing patterns,
similar tasks completed before.

**Medium** -- Some unknowns, touches moderately complex systems, partial
precedent from previous work.

**Low** -- Significant unknowns, new technology, unclear requirements, or
cross-cutting concerns across many systems.

[Explain which factors drive the confidence level for this specific task.]

### Risk Factors

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| [Specific risk] | [High/Med/Low] | [Days added if realized] | [How to reduce] |
| [Another risk] | [Likelihood] | [Impact] | [Mitigation] |

### Dependencies

| Dependency | Status | Impact if Delayed |
|-----------|--------|-------------------|
| [What must be done first] | [Done / In Progress / Not Started] | [How it affects this task] |

### Suggested Breakdown

| # | Sub-task | Estimate | Notes |
|---|----------|----------|-------|
| 1 | [Research / spike] | [X days] | [If unknowns need investigation first] |
| 2 | [Core implementation] | [X days] | [The main work] |
| 3 | [Integration with system X] | [X days] | [Connecting to existing code] |
| 4 | [Testing and validation] | [X days] | [Writing tests, manual verification] |
| 5 | [Code review and iteration] | [X days] | [Review feedback, fixes] |
| | **Total** | **[Y days]** | |

### Historical Comparison
[If similar tasks exist in sprint history:]

| Similar Task | Estimated | Actual | Relevant Difference |
|-------------|-----------|--------|-------------------|
| [Past task 1] | [X days] | [Y days] | [What makes it similar/different] |
| [Past task 2] | [X days] | [Y days] | [What makes it similar/different] |

### Notes and Assumptions
- [Key assumption that affects the estimate]
- [Another assumption]
- [Any caveats about scope boundaries -- what is included vs excluded]
- [Recommendations: e.g., "Consider a spike first if requirement X is unclear"]

Output the estimate to the user with a brief summary: recommended budget, confidence level, and the single biggest risk factor.

Guidelines

Always give a range (optimistic / expected / pessimistic), never a single number. Single-point estimates create false precision.
The recommended budget should be the expected estimate, not the optimistic one. Padding is not dishonest -- it is realistic.
If confidence is Low, recommend a time-boxed spike or prototype before committing to the full estimate.
Be explicit about what is included and excluded. Scope ambiguity is the most common source of estimation error.
Round to half-day increments. Estimating in hours implies false precision for tasks longer than a day.
If the task is too large to estimate confidently (more than 10 days expected), recommend breaking it into smaller tasks and estimating those individually.
Do not pad estimates silently. If risk exists, call it out explicitly in the risk factors section so the team can decide how to handle it.

estimate

NPX Install

Tags

SKILL.md Content

Guidelines