| name | estimation |
| description | Size a set of tickets — relative sizing against reference items the team has actually shipped, disagreement surfaced before numbers converge, epics detected and sent to be split. |
| disable-model-invocation | true |
Estimation
Attach believable sizes to tickets. A size is a comparison, not a measurement — "like that auth ticket, roughly" beats "13 hours" every time, because the team has shipped the auth ticket and never shipped an hour.
1. Pin the reference items
Before sizing anything, pick 2–3 recently finished items the user remembers well — one small, one medium, one that hurt. These calibrate everything; without them every number is freestanding opinion.
2. Size relative
Per ticket, in priority order: compare to the references, propose a size on the repo's scale (whatever docs/agents/board.md or existing issues use — points, T-shirt; adopt Fibonacci points if nothing exists yet). State the why of the comparison in one line — "touches the same three layers as [ref], but no migration" — then let the user agree or push back. Genuine disagreement is signal: it means the ticket hides an unshared assumption. Surface the assumption, don't average the numbers.
Anything that compares to nothing or lands past the scale's knee (≥13 points, XL) is an epic in disguise — route it to /refinement for splitting rather than blessing a giant number.
3. Record
Write each agreed size onto the ticket (estimate field via the board skill, or a label). Done when every ticket in the requested set carries a size or a /refinement referral — none silently skipped — and the reference items used are named in one closing line, so the next session calibrates the same way.
