---
name: ai-era-self-estimate
description: Use this skill before starting any ticket assigned to you as a coding agent, when you are the one implementing the work and no human will review the plan before you begin. Estimate your own work on four dimensions before writing any code, so the person orchestrating you can decide how much oversight this ticket needs before you start — not after they read the diff.
---

# AI Era Self-Estimate

You are about to be assigned a ticket. Before writing any code, answer the four questions below about the ticket you were just given. This is not a retrospective on work you've already done — answer before you start, based on what you can see by reading the ticket and the relevant code, not by guessing.

These are the same four dimensions used in Estimate Well's **AI Era** config, normally answered by a human estimating an agent's work from outside the codebase. You have direct visibility a human estimating from a ticket title doesn't — use it.

## The four questions

For each, vote **low / mid / high** and give one sentence of reasoning. Do not skip the reasoning — a bare vote is not useful to the person deciding whether to leave you alone or watch closely.

1. **Steering effort** — Is there one clear path to the fix, or will you need to make judgment calls you're not fully certain about along the way?
2. **Architectural impact** — Does this touch shared state, a queue, an auth path, or anything more than one service or component reaches into? Or is it contained to one file, one component, one clear boundary?
3. **Domain knowledge** — Is there anything here you'd be guessing at rather than knowing — business rules, historical context, an undocumented constraint, an assumption you can't verify from the code alone? Name it specifically if so.
4. **Review burden** — How much scrutiny should a human give the resulting diff before it merges — a skim, or a close read?

## Output format

Post this before starting any implementation work:

```
Steering effort: <low/mid/high> — <one sentence>
Architectural impact: <low/mid/high> — <one sentence>
Domain knowledge: <low/mid/high> — <one sentence>
Review burden: <low/mid/high> — <one sentence>
```

## The one rule that matters

**If any answer is "high," stop and say so explicitly before continuing.** Do not proceed and mention it only in the PR description afterward. The point of estimating first is that the person orchestrating you gets to decide — supervise this one, or let it run — before the work happens, not after.

## Why this exists

Estimate Well's AI Era config asks four questions to size AI-assisted work: steering effort, architectural impact, domain knowledge, review burden. It was built for a human to answer about an agent's work from just outside it. When a person is orchestrating many tickets and isn't reading the code before assigning it, that human is guessing from a title — the agent isn't. Answering these questions yourself, before starting, moves the estimate to the point where it's actually useful.

Read more: [estimate-well.com/blog/ai-agent-orchestration-estimation-problem](https://estimate-well.com/blog/ai-agent-orchestration-estimation-problem) · [estimate-well.com/profiles](https://estimate-well.com/profiles)
