Effort estimation

# Effort estimation

Use this skill during planning, backlog grooming, or resourcing to get a first-pass effort estimate for every feature in a list report.

## Definitions

Use these meanings consistently in every step.

- **Feature:** A feature record in the provided list report, or a feature whose record link the user pasted into the chat
- **Estimation method:** How effort is expressed. Default to T-shirt sizes of XS, S, M, L, and XL. Story points and time are also supported when the user asks.
- **Complexity signals:** What drives the estimate: the number of requirements, dependencies on the **Related** tab, integrations involved, data model changes, and how much of the behavior is already defined
- **Confidence:** How much the estimate can be trusted (rated high, medium, or low) based on how completely the feature is defined

## Workflow

1. Read every feature in the list report. Do not sample.
2. Confirm the estimation method and the sizing scale with the user when they differ from the defaults
3. For each feature, read the description, the requirements, and the records on the **Related** tab. A feature with no requirements is not small, it is undefined.
4. Identify the complexity signals present on each feature and note which ones are absent because the feature is thin rather than simple
5. Assign an estimate and write one line of reasoning that cites the specific signals behind it
6. Rate confidence. Any feature with no requirements and no linked records is low confidence by definition.
7. Flag features that cannot be estimated and state exactly what is needed before they can be
8. Summarize total effort by size band so the team can see the shape of the release, not just the individual numbers

## Rules

- If no features are provided, ask for a list report or pasted record links before estimating
- Every estimate carries reasoning that cites something on the record
- Never present a middling estimate to fill a cell. An undefined feature is flagged, not averaged.
- Note when an existing estimate on the record disagrees materially with this analysis
- Reference features by reference number and name
- Do not write estimates back to the record. Present the table and let the user apply it.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
| Feature | Estimate | Confidence | Reasoning |  
  
### Cannot be estimated yet  
- <feature>: <what is required before it can be sized>  
  
### Disagreements with existing estimates  
- <feature>: <this analysis versus the estimate on the record>  
  
### Totals by size  
| Size | Count | Features |
```

## Quality checks

- Every feature in the list report appears in the table or in the cannot-be-estimated list
- Every estimate cites a specific complexity signal
- Thin features are flagged as undefined rather than sized as small
- Confidence ratings track the completeness of each record