estimating-agent-tasks
Skill1 starsChanged 8 months agoApache-2.0View on GitHub
Use when planning features, estimating tasks, scoping sprints, or budgeting costs for projects built with AI coding agents. Triggers on estimation, story points, task sizing, sprint planning, complexity scoring, model selection, token budgeting, or timeline planning for agent-assisted development.
In this repository11 other files it gives its agents.
- ai-tone-calibrationSkill
- evolution-api-managementSkill
- captureSkill
- connectSkill
- emergeSkill
- reviewSkill
- obsidian-second-brainSkill
- todaySkill
- quality-gateSkill
- validate-claude-code-setupSkill
- video-to-contextSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 95
When tasks can run in parallel (subagents/teams), total time = critical path (longest sequential chain), not sum of all tasks.
- Distinctive: line 109
When estimating a project, produce a table like this:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Estimating Agent Tasks — ACR Framework
Overview
Agent Complexity Rating (ACR) replaces story points for AI-agent-assisted development. Story points measure human effort to BUILD. ACR measures the real bottleneck: how hard it is to VALIDATE, REVIEW, and INTEGRATE agent output.
When to Use
- Planning features, sprints, or roadmaps for AI-agent development
- Estimating time, cost, model, or tokens for a set of tasks
- Replacing story points in project planning documents
- NOT for: pure human development, non-coding tasks, single trivial changes
ACR = E + R + I (range 3-15)
Three axes, each scored 1-5:
E — Scope (Escopo)
| Score | Description | Example |
| 1 | 1 file, isolated change | Config tweak, typo fix |
| 2 | 2-5 files, single feature | New component + route |
| 3 | 6-15 files, cross-cutting | Endpoint + frontend + DB schema |
| 4 | 15+ files, multi-domain | Auth migration across codebase |
| 5 | Entire architecture | Full system redesign |
R — Review (Revisao)
R = pure human review time spent reading and evaluating agent output. Does NOT include time waiting for agent iterations (that's captured in I).
| Score | Description | Human time |
| 1 | Auto-verifiable (tests pass = done) | <10 min |
| 2 | Quick diff scan | 10-20 min |
| 3 | Careful review (logic, edge cases) | 20-45 min |
| 4 | Deep review (security, architecture) | 45min-1.5h |
| 5 | Expert review (legal, UX, compliance) | >1.5h |
I — Iteration (Iteracao)
Each cycle = one round-trip: human reviews output → gives feedback → agent adjusts. NOT agent-internal retries.
| Score | Description | Round-trips |
| 1 | First-shot (agent nails it) | 1 |
| 2 | Minor fixes | 2 |
| 3 | Moderate back-and-forth | 3-4 |
| 4 | Complex integration, many adjustments | 5-7 |
| 5 | Exploratory, trial-and-error | 8+ |
ACR to Time Mapping
| ACR | Size | Wall clock (solo dev + agent) |
| 3-4 | XS | 30min - 1h |
| 5-6 | S | 1-3h |
| 7-9 | M | 3-8h (half day to full day) |
| 10-12 | L | 1-2 days |
| 13-15 | XL | 2-4 days |
Model Selection
| Condition | Model | Why |
| ACR >= 10 or security/auth critical | Opus | Deep reasoning, edge cases, architectural decisions |
| ACR 7-9 (default) | Sonnet | Best cost-quality balance for standard implementation |
| ACR <= 6 and low risk | Haiku | Fast and cheap: boilerplate, static pages, config |
Security override: Security/auth tasks always use Opus regardless of ACR score. A simple auth config change (ACR 5) still needs Opus because security mistakes are costly and hard to detect in review.
Hybrid strategy within a phase: Opus as architect/lead, Sonnet subagents for implementation, Haiku for repetitive sub-tasks.
Token and Cost Estimation
| Size | Turns | Tokens ~ | Opus ~$ | Sonnet ~$ | Haiku ~$ |
| XS | 5-10 | 100-250K | $3-8 | $0.60-1.50 | $0.15-0.40 |
| S | 10-20 | 250-500K | $8-15 | $1.50-3 | $0.40-0.80 |
| M | 20-40 | 500K-1.2M | $15-36 | $3-7 | $0.80-2 |
| L | 40-80 | 1-2.5M | $30-75 | $6-15 | $1.50-4 |
| XL | 80-150 | 2-5M | $60-150 | $12-30 | $3-8 |
Blended rates (3:1 input:output): Opus ~$30/M, Sonnet ~$6/M, Haiku ~$1.60/M. On Max plan ($100-200/mo), use token estimates for quota planning instead of cost. Range heuristic: Use lower bound for greenfield projects (less context to read). Use upper bound for legacy codebases (many files to read/understand before changing).
Parallelism
When tasks can run in parallel (subagents/teams), total time = critical path (longest sequential chain), not sum of all tasks.
How to calculate:
- List all tasks with dependencies (use
→for "blocks":Task A → Task Bmeans B depends on A) - Draw the dependency graph
- Find the longest path — that's your real timeline
- Parallel tasks within that path add zero extra time
Example: Tasks A, B, C where A → C and B → C (C depends on both):
- Sequential time: A + B + C
- Parallel time: max(A, B) + C
Output Format
When estimating a project, produce a table like this:
| Task | E | R | I | ACR | Size | Model | Tokens ~ | Cost ~ | Time ~ |
| Task name | X | X | X | XX | S/M/L | Opus/Sonnet/Haiku | XXK-XXM | $XX | Xh/Xd |
Then calculate:
- Total tokens (sum)
- Total cost (sum, considering model per task)
- Sequential time (sum of all times)
- Parallel time (critical path only)
Common Mistakes
| Mistake | Fix |
| Using story points habits (effort-based) | ACR measures review + iteration burden, not coding effort |
| Same model for everything | Match model to task: Opus for hard, Haiku for trivial |
| Summing time for parallel tasks | Use critical path, not total sum |
| Ignoring iteration cycles | I axis is often the biggest time factor |
| Overestimating scope of simple tasks | A 1-file change is E1 even if the file is complex |
| Underestimating review for security tasks | Security/auth always gets R >= 4 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.