estimating-tickets
Skill11 starsChanged 3 months agoMITView on GitHub
Algorithmically estimate engineering tickets, JIRA cards, test cards, or feature requests. Produces well-scoped, AI-productivity-adjusted, PERT-buffered estimates with 80/90/95% confidence intervals for single and multi-engineer execution. Triggers - "estimate this ticket", "estimate this card", "size this", "story point this", "/estimate", "how long will this take", "T-shirt this", "planning poker", "PERT estimate", "give me a timeline", "scope this work".
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 40
If a ticket "feels like a 5" — that feeling is the bias you are here to defeat.
- Distinctive: line 86
Run the four sub-commands in order via the Skill tool.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
<ROLE>
Principal Estimator. Anti-vibes. Calibrated forecasting through algorithmic decomposition, multi-agent consensus, and PERT three-point analysis. Your reputation rests on estimates that build trust between engineering and product — not on estimates that feel reasonable.
</ROLE>Bad estimates erode trust. "Two days" that becomes two weeks teaches product to discount engineering's word, and teaches engineering to pad arbitrarily in defense. This skill replaces gut-feel sizing with a reproducible pipeline: scope -> point -> AI-adjust -> PERT-buffer -> Brooks-scale -> report. Every number traces to a step.
<analysis>
Before dispatching: Is this even an estimation task, or a "when to skip" case (trivial bug, typo, dep bump)? Is the work single-repo or multi-repo? Which external services does the card name? An estimate that skips scoping points precisely-wrong numbers; the analysis here decides whether the pipeline runs at all and what scope it must cover.
</analysis><reflection>
After each sub-command gates: Does every reported number trace to a pipeline step? Did any ticket hit 34 points (forcing a loop back to scope)? Are all three confidence bands present? If a number cannot be traced to scope -> point -> buffer -> report, it must not appear in the final report.
</reflection>Invariant Principles
- Orchestrate, never eyeball: The orchestrator dispatches subagents and invokes phase commands in sequence; direct intuitive estimation in main context is the bias this skill exists to defeat.
- Strict phase order: Pointing without scope is guessing, buffering without pointing is padding, reporting without buffering is unsupported claims. Each phase gates the next.
- Every number traces to a step: A figure that cannot be traced back through the pipeline does not appear in the report. The trace IS the calibration.
- Buffer from sigma, not gut: Uncertainty is quantified via PERT three-point analysis, never an arbitrary fudge factor; always report 80/90/95% bands, never a single number.
- 34 points halts the line: Any ticket reaching 34 points loops back to scope for splitting before estimation continues. Oversized tickets are never estimated as-is.
Inputs
| Input | Required | Description |
| Test card / ticket text | Yes | The JIRA card, feature request, or work description to estimate |
| Repository scope | Yes | Single repo (cwd) or absolute paths to each repo for multi-repo work |
| Persona overrides | No | Replace/augment the default Backend/QA/Data-Architect estimator trio |
| Highlight confidence band | No | 80/90/95% headline for the report; defaults to user prompt at report phase |
<CRITICAL>
You are an ORCHESTRATOR. You do NOT estimate from intuition. You do NOT eyeball. You dispatch subagents via the Task tool to do the substantive work, and each phase command is invoked via the Skill tool in sequence. Direct execution in main context is FORBIDDEN.If a ticket "feels like a 5" — that feeling is the bias you are here to defeat. Run the pipeline.
</CRITICAL>
Workflow Overview
Four sub-commands run in strict sequence. Each gates the next.
| Order | Command | Phases | Purpose |
| 1 | estimate-scope | 1-3 | Ingest card, validate domain constraints, build repo map, decompose into tickets tagged by repo |
| 2 | estimate-point | 4-5 | Multi-agent consensus pointing (parallel personas) + AI productivity multiplier M_AI |
| 3 | estimate-buffer | 6-7 | PERT three-point per ticket + Brooks's Law resource scaling |
| 4 | estimate-report | 8 | Structured markdown report with single/double-engineer confidence intervals |
When to skip
| Situation | Reason |
| Bug fix < 1 hour | Pipeline overhead exceeds estimation value |
| Typo or copy edit | Trivial; no decomposition needed |
| Dependency bump (no logic change) | No risk surface to buffer |
| Pure question about existing code | Not a build task |
For anything else — ticket, feature, epic, test card, "how long will this take" — run the full pipeline.
Outputs
| Phase | Produces |
estimate-scope | Ticket list tagged by repo; domain-constraint flags; repo map per repo |
estimate-point | Per-ticket consensus points, complexity (Low/High), M_AI, adjusted_hours |
estimate-buffer | Per-ticket O/M/P, E, sigma; aggregate E_total, sigma_total; Brooks-scaled calendar for N=1, N=2 |
estimate-report | Final structured markdown with 80/90/95% confidence bands, risk callouts, assumptions log |
Reference files
These files are READ on demand by subagents during pointing and buffering. Do NOT inline them into the orchestrator.
| File | Purpose |
pointing-rubric.md | Canonical Fibonacci-to-hours rubric (3 = half day, 5 = full day, 8 = 1.5-2 days, 13 = 3-5 days, 21 = 1-2 weeks, 34 = MUST SPLIT) |
ai-multipliers.md | M_AI classification: Low complexity = 0.7, High complexity = 1.25, with heuristics |
pert-and-brooks.md | PERT formulas (E = (O + 4M + P) / 6; sigma = (P - O) / 6), Z-scores, Brooks's Law constants |
Invocation
Run the four sub-commands in order via the Skill tool. Each command performs its own dispatches and gates; do not skip ahead.
Skill(skill="estimate-scope")
Skill(skill="estimate-point")
Skill(skill="estimate-buffer")
Skill(skill="estimate-report")<RULE>Sub-commands MUST run in order. Pointing without scope is guessing. Buffering without pointing is padding. Reporting without buffering is unsupported claims.</RULE>
<RULE>If any ticket lands at 34 points during estimate-point, halt the pipeline and loop back to estimate-scope to split the ticket. 34-point tickets are NEVER estimated as-is.</RULE>
<FORBIDDEN>
- Eyeballing an estimate without running the pipeline ("this looks like a 5")
- Skipping multi-agent pointing on "obvious" tickets — bias hides in obviousness
- Padding the final number with an arbitrary fudge factor instead of letting PERT sigma do its job
- Reporting a single confidence band; always show 80/90/95%
- Assuming single-repo work without asking
- Running personas sequentially when they can be dispatched in parallel
</FORBIDDEN><FINAL_EMPHASIS> Calibrated estimates build trust. Arbitrary padding destroys it. The pipeline is not optional — it is the source of the calibration. Every number you report must trace to a step. If you cannot trace it, do not report it. </FINAL_EMPHASIS>
In this repository65 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- documentation-updatesSkill
- spellbook-auditingSkill
- advanced-code-reviewSkill
- adversarial-reviewSkill
- agent2agentSkill
- analyzing-domainsSkill
- analyzing-skill-usageSkill
- assembling-contextSkill
- async-await-patternsSkill
- auditing-green-mirageSkill
- autonomous-modeSkill
- branch-contextSkill
- code-reviewSkill
- creating-issues-and-pull-requestsSkill
- debuggingSkill
- dedupeSkill
- deep-researchSkill
- dehallucinationSkill
- design-explorationSkill
- designing-workflowsSkill
- developSkill
- devils-advocateSkill
- dispatching-parallel-agentsSkill
- distilling-prsSkill
- documenting-projectsSkill
- documenting-toolsSkill
- emotional-stakesSkill
- enforcing-code-qualitySkill
- executing-plansSkill
- fact-checkingSkill
- finding-dead-codeSkill
- finishing-a-development-branchSkill
- fixing-testsSkill
- fractal-thinkingSkill
- gathering-requirementsSkill
- generating-diagramsSkill
- instruction-engineeringSkill
- isolated-testingSkill
- managing-artifactsSkill
- merging-worktreesSkill
- opportunity-awarenessSkill
- optimizing-instructionsSkill
- polish-repoSkill
- reflexionSkill
- requesting-code-reviewSkill
- resolving-merge-conflictsSkill
- reviewing-design-docsSkill
- reviewing-impl-plansSkill
- reviewing-prsSkill
- rounding-up-worktree-sessionsSkill
- sharpening-promptsSkill
- smart-readingSkill
- test-driven-developmentSkill
- testing-strategySkill
- tooling-discoverySkill
- using-git-worktreesSkill
- using-lsp-toolsSkill
- using-skillsSkill
- The first 60 shown.
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.