---
name: estimate-as-a-senniordev
description: Auto-generate time estimates for senior developers after feature Q&A is complete
status: done
parts:
  - CLAUDE.md
estimate:
  optimistic: 15 minutes
  normal: 30 minutes
  pessimistic: 1 hour
---

# Feature: estimate-as-a-senniordev

## Description

After all questions have been answered and the plan is completed, automatically generate a time estimate showing how long a senior developer would take to implement the feature. The estimate is saved at the end of the feature markdown document.

---

## Q & A

### Q1: When should the estimation be generated? Options: (A) Automatically when all Q&A is completed and status changes to 'ready', (B) When the document is updated with a 'Complete Definition' section, (C) As a separate tool that the LLM must explicitly call, (D) Other?
**Category:** clarification
**Answer:** Before beginning implementation - when everything is clarified and status changes to 'ready'. The estimate should be auto-generated at this point.

### Q2: What format should the estimate take? Options: (A) Single number (e.g., '4 hours'), (B) Range (e.g., '2-4 hours'), (C) Breakdown by task with total (e.g., 'Backend: 2h, Frontend: 1h, Tests: 1h, Total: 4h'), (D) T-shirt sizes (S/M/L/XL)?
**Category:** clarification
**Answer:** Three-point estimate: pessimistic, normal (most likely), and optimistic times.

### Q3: What level of seniority should the estimate assume? The feature says 'senior dev' - should we clarify this means 5+ years experience, familiar with the project's tech stack, or define it differently?
**Category:** clarification
**Answer:** Senior developer = 5+ years of experience, familiar with the project's tech stack.

### Q4: Should the estimate include any assumptions or caveats? For example: 'Assumes tests already exist', 'Excludes code review time', 'Assumes familiarity with codebase'?
**Category:** missing_requirement
**Answer:** Yes, include assumptions and caveats with the estimate.

### Q5: Where in the markdown should the estimate be placed? Options: (A) At the very end of the document, (B) In a dedicated '## Estimate' section after 'Implementation Plan', (C) As part of the 'Implementation Plan' section?
**Category:** clarification
**Answer:** At the very end of the document.

### Q6: Should there be any confidence level attached to the estimate (e.g., 'High confidence', '80% confident')? Complex features may have less predictable timelines.
**Category:** missing_requirement
**Answer:** No confidence level needed for now.

### Q7: Implementation approach: Should this be (A) built into the existing update_feature_document flow, (B) a new dedicated tool like 'generate_estimate', (C) instructions in CLAUDE.md for the LLM to add estimates manually?
**Category:** integration
**Answer:** Build into existing flow - should be auto-generated when status changes to 'ready'.

---

## Complete Definition

### Overview
When a feature transitions to `ready` status (all questions answered), the system should prompt/instruct the LLM to generate a time estimate and append it to the feature document. The estimate uses a three-point format (optimistic, normal, pessimistic) and includes assumptions.

### Estimate Format
The estimate section should be appended at the very end of the markdown document:

```markdown
---

## Estimate

**Senior Developer Profile:** 5+ years experience, familiar with the project's tech stack.

| Scenario | Time |
|----------|------|
| Optimistic | X hours |
| Normal | Y hours |
| Pessimistic | Z hours |

### Assumptions
- [List of assumptions that affect the estimate]
- [e.g., "Assumes existing test infrastructure"]
- [e.g., "Excludes code review iterations"]
```

### Trigger Point
The estimate should be generated when:
1. All questions are answered (`save_qa_response` marks the last question as answered)
2. Status transitions to `ready`

### Implementation Approach
Update the `CLAUDE.md` instructions to require the LLM to:
1. After all Q&A is complete and before setting status to `implementing`
2. Analyze the complete feature definition
3. Generate a three-point estimate based on the implementation plan
4. Append the estimate section to the feature document using `update_feature_document`

This keeps the estimation logic in the LLM (which understands the complexity) rather than in the MCP server code.

---

## Implementation Plan

### Files to Modify
1. `CLAUDE.md` - Add instructions for automatic estimate generation in the workflow

### Implementation Steps

1. **Update CLAUDE.md Workflow Section**
   - Add a new step between "Phase 1: Feature Definition" and "Phase 2: Implementation"
   - Document the estimate generation requirement
   - Specify the three-point estimate format
   - List what assumptions should be considered

2. **Update the Feature Development Workflow**
   Add after step 5 (Update Document):
   ```
   6. **Generate Estimate**: Before starting implementation, analyze the complete 
      feature definition and generate a three-point time estimate (optimistic, 
      normal, pessimistic) for a senior developer (5+ years, familiar with stack).
      Include assumptions. Append to the feature document.
   ```

3. **Add Estimate Section Template to CLAUDE.md**
   Document the expected format:
   - Senior developer profile definition
   - Three-point estimate table
   - Assumptions list

### Changes to CLAUDE.md

Add the following to the "Feature Development Workflow" section:

```markdown
### Phase 1.5: Estimation (Before Implementation)

After all questions are answered and the complete definition is ready:

1. **Generate Estimate**: Analyze the feature and create a time estimate
2. **Format**: Use three-point estimation:
   - **Optimistic**: Best case, everything goes smoothly
   - **Normal**: Most likely scenario
   - **Pessimistic**: Worst case, unexpected complications
3. **Assumptions**: List key assumptions that affect the estimate
4. **Append**: Add the estimate section at the end of the feature document

#### Estimate Section Template
```
---

## Estimate

**Senior Developer Profile:** 5+ years experience, familiar with the project's tech stack.

| Scenario | Time |
|----------|------|
| Optimistic | X hours |
| Normal | Y hours |
| Pessimistic | Z hours |

### Assumptions
- Assumption 1
- Assumption 2
```
```

---

## Testing Considerations

1. **Manual Testing**: Create a new feature, answer all questions, verify the LLM generates an estimate
2. **Format Validation**: Ensure the estimate follows the three-point format
3. **Placement**: Verify estimate appears at the end of the document
4. **Assumptions**: Check that relevant assumptions are included

---

## Estimate

**Senior Developer Profile:** 5+ years experience, familiar with the project's tech stack.

| Scenario | Time |
|----------|------|
| Optimistic | 15 minutes |
| Normal | 30 minutes |
| Pessimistic | 1 hour |

### Assumptions
- Only modifying CLAUDE.md documentation (no code changes)
- Clear understanding of existing workflow structure
- No changes needed to MCP server code
- Estimate generation logic stays in LLM, not in Rust code
