backlog-dedupe

Backlog Dedupe & Aggregation

Backlogs accumulate the same ask in different words: filed twice a year apart, filed small three times instead of once as one piece of work, or left open long after a decision quietly retired it. Every planning pass then pays for the noise. This skill scans a bounded slice, clusters what is really one piece of work, proposes what the clusters consolidate into, and lists what looks dead — every claim carrying its evidence, every action waiting for the human. The agent proposes; the human disposes.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking, and memory-capture owns any durable write; all three 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; find it in your tool list — names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. Propose-only — nothing in Jira changes without per-action approval. No close, cancel, merge, link, label, issue creation, or field edit lands unless the user approved that specific action, or an explicitly named batch of them, in this session. Approval is the gate, not an undo; silence is not approval. A batch counts as named only where the text the user reads before answering carries every key and what happens to each — a label standing for them is not that text. One ask decides one thing: nothing unrelated rides along in the same question, and housekeeping never shares a question with a Jira action. The one other permitted write is a comment, drafted and posted only after the user approves the exact text. Write markdown and set the tool's content-format parameter to markdown when it exposes one.
2. Fetch the slice once and whole, then work the copy. Pull the slice into an enumerated working set — key, summary, status, age, last activity — and cluster against that. One pass means the entire slice, not the first page: search results are paginated, so follow the pages until the set is complete, or narrow the query until it fits one, and say which you did next to the count. A total recounted over a truncated page is precise and wrong, and nothing downstream can detect it. Per-ticket live calls across a slice multiply cost and stall long before the slice ends; fetch an item's full detail only for the few whose verdict turns on it.
3. Counts are recounted, never estimated — and "every" and "none" are counts. Cluster sizes, stale totals, and any claim of how many tickets something covers are computed by enumerating the working set. A number that cannot be recounted from the set does not enter the output. A claim about all of something — every edit in a history, no real activity on a ticket — is the same claim wearing a different word: enumerate it, give the tally, and name the exceptions. "Twenty of twenty-two entries are sprint moves" is a finding; "every entry is a sprint move" is that finding with the exceptions dropped, and the exceptions are often where the real activity is.
4. Every cluster carries its evidence; every stale candidate carries its justification. A cluster names its ticket keys, the outcome they share (not the wording), and any memory record tying them together — each with id and date. A stale candidate states age, last activity, and what superseded it or decided against it. A bare list of old tickets is exactly the output this skill must never produce.
5. Calibrate on a sample before scaling. Before clustering the full slice, run the bar over a handful of items and report those verdicts first — at least one you read as clearly current and one as clearly stale or duplicated, each with the evidence that put it there. Where the user or the record can confirm them, that is the check; where neither can, the sample still puts the bar in front of the user early enough to be argued with. A bar that misreads the sample does not get scaled to the slice.
6. Org scope is checked at the output, and engagements do not mix. Pass explicit group_ids naming the org group on reads — take the name from session results or ask; never guess one — and treat scope as server-decided. Where the session has surfaced no group yet, ask before the first read rather than running one unscoped and repairing after — an omitted group_ids does not mean the org group, it means an unspecified set that includes personal scope, and the opening themed pass is where that goes unnoticed. Nothing from another client's engagement enters any query, cluster, or proposal — check per line, not per run. The run summary, once decisions are made, goes through memory-capture's gate into the engagement's own group, chosen deliberately on the same never-guess terms and targeted by whatever means memory-capture says targets it.
7. Bare tool names, probed with ToolSearch before concluding one is missing; the mcp__…__ prefix varies per install.
8. Issue types, workflow transitions, and link names come from the organization, not from this skill. Read what the project actually exposes before proposing against it: its issue types, the transitions its workflow defines, the link types the instance carries. A consolidation is proposed at whatever type that project uses for work of its size, and an action is named the way the workflow names it. Never hardcode one; where a proposal needs a shape the project does not have, say so rather than inventing it.