estimate

name	estimate
description	Estimates how long a task will take with AI. Breaks the task into sub-tasks and gives realistic AI-assisted time estimates based on calibrated research data. Triggers on 'how long will this take', 'estimate this', 'scope this feature', 'what's the ETA', or before starting a project to set expectations.

/estimate — AI-Era Time Estimates

Estimate how long a task will actually take — with AI in the picture.

Usage:

• /estimate [task description] — estimate a described task
• /estimate — estimate from current context (recent issues, conversation)

Step 1: Parse the Task

Break the task into concrete sub-tasks. Each sub-task should be a shippable unit of work.

If the description is vague, ask ONE clarifying question max. Don't interrogate — make reasonable assumptions and list them.

Extract for each sub-task:

• What needs to be built (component, endpoint, migration, etc.)
• Tech involved (language, framework, APIs, integrations)
• Complexity tier (see references/estimation-framework.md)

If in a repo, run git ls-files | head -30 and check the stack. Knowing the codebase changes the estimate.

Step 2: Estimate Each Sub-Task

For each sub-task, estimate the total time including human involvement:

Component	What It Covers
AI generation	Claude/Cursor writing the code
Prompting	Human describing what to build, iterating on prompts
Review	Human reading, understanding, and approving AI output
Testing	Running it, checking edge cases, manual QA
Debugging	Fixing what the AI got wrong, iteration cycles
Integration	Connecting pieces, deployment, config

Use the rates in references/estimation-framework.md.

Always produce a range (optimistic → realistic). The optimistic assumes clean execution. The realistic assumes 1-2 iteration cycles per sub-task.

Step 3: Display the Estimate

┌─────────────────────────────────────────┐
│ 📐 ESTIMATE                             │
├─────────────────────────────────────────┤
│                                         │
│  Task: [1-line description]             │
│                                         │
│  Estimate:  [range]                     │
│                                         │
├─────────────────────────────────────────┤
│ Breakdown                               │
│                                         │
│  1. [Sub-task]             ~[time]      │
│  2. [Sub-task]             ~[time]      │
│  3. [Sub-task]             ~[time]      │
│  4. Review & test          ~[time]      │
│                                         │
│ Assumptions                             │
│  • [key assumption]                     │
│  • [key assumption]                     │
│                                         │
└─────────────────────────────────────────┘

Rules:

• Estimate is always a range: "2–4 hours" not "3 hours"
• Sub-tasks show individual time estimates
• "Review & test" is always a line item — it's real time humans spend
• Assumptions section is mandatory — be transparent about what you're assuming
• If the task is trivial (< 30 min total), just say so in one line. No box needed.
• Keep it to 3–7 sub-tasks. If more, you're scoping a project, not a task — suggest breaking it up.

Step 4: Offer to Start

After showing the estimate: "Want to start with #1?"

If the user says yes, begin working on the first sub-task. The estimate becomes a natural checklist.

Gotchas

• AI doesn't eliminate all human time. Review, testing, and deployment are still real. A "2-hour AI estimate" that ignores 3 hours of human review is a lie.
• Iteration cycles are the hidden cost. AI gets it 80% right on the first pass. The last 20% — edge cases, styling, business logic nuance — takes disproportionate time. Always budget for 1-2 rounds of "that's not quite right."
• Integrations multiply time. Connecting to Stripe, sending emails, OAuth flows — these have real debugging time regardless of AI. Third-party APIs don't care how fast your code generator is.
• Don't estimate what you can't see. If the task involves a codebase you haven't read, say so. "Estimate assumes standard [framework] patterns. Could be higher if the codebase has unusual architecture."
• Scope creep is the real enemy. The estimate covers what was asked, not what will inevitably get added. If the task sounds like it'll grow, flag it: "This estimate covers X. If Y is also needed, add [time]."