ticket-estimate

Ticket Estimate

Estimates fail on the unknowns, and the unknowns are usually already in the org's history: the last time this area was touched, what was underestimated, which dependency stalled, where the incidents cluster. This skill grounds a ticket's estimate in that history — comparables with citations, risks with evidence, and an honest confidence label. The number stays advice: committing to it is the team's act, not the skill's.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking, and memory-capture owns any durable write; they ship with the gutt-pro plugin (this plugin depends on it). Without them, follow the rules below and note the gap in one line. Jira access comes from whatever Atlassian tooling the session surfaces; names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. Jira is read-only here — never write an estimate into it. No story-point fields, no estimate fields, no status changes, no edits to any other field — the output is advice in the reply. The one permitted write is a comment, drafted and posted only after the user approves the exact text in this session. Treat it as final — approval is the gate, not an undo; a truly needed correction re-approves the text and targets the existing comment if the tool allows, rather than posting a second one. Write markdown and set the tool's content-format parameter to markdown when it exposes one.
2. Confidence is honest. Thin comparables → say low confidence and why. An estimate with no comparables at all is a guess — label it a guess rather than dress it up as analysis. Fabricated confidence is the one failure mode this skill must never have.
3. A range with a basis, in the team's unit. Read the unit the team actually uses off the ticket and its board (points, days, t-shirt sizes); if it is not visible, ask, or default to a day-range and say so. Always a range plus the one-line basis — a bare number invites false precision.
4. Calendar time is not effort. A past ticket's created→resolved span includes waiting, handoffs, and life. Treat it as a weak upper signal only; prefer what the record says was actually involved — scope, rework, surprises.
5. Every comparable and risk is real and cited — a resolved ticket key with its resolution date, or a memory episode, lesson, or incident (id, date). No invented history, and no risk without its evidence.
6. Org scope is checked at the output — pass explicit group_ids naming the org group on reads (take the name from session results or ask; never guess one), treat scope as server-decided, and before any comparable or risk enters the offered comment, confirm that item's own scope is the org group; personal-scope material stays in the in-session output. Bare tool names, probed with ToolSearch. No memory writes — a durable sizing lesson goes through memory-capture's gate.