A Jira Backlog Cleanup Prompt That Sorts Keep, Archive, Merge

A Jira backlog cleanup prompt has to do something most backlog-grooming content avoids: make a call. The guides out there explain why grooming matters and walk you through the Jira UI. The integration tutorials wire GPT to the Jira API and then leave the actual judgment to you. What's missing is a reusable prompt that reads the tickets and says, per item, keep this, archive that, merge these two.

A backlog past a few hundred items isn't a list anymore. It's a graveyard with a few live tickets buried in it. Grooming by hand means reading every ticket and remembering the other 400 to spot duplicates. That's the job a prompt is genuinely good at.

This is the prompt that turns a CSV export into a triaged verdict list with a reason on every row.

What you can do with a cleanup prompt

• Flag tickets older than a {{stale_after}} threshold with no recent activity
• Spot near-duplicate tickets that describe the same work in different words
• Mark low-value items where the effort clearly outweighs the stated outcome
• Group related tickets that should become a single epic or be merged
• Surface tickets missing acceptance criteria so they can't be picked up as-is
• Produce a keep / archive / merge table you review before touching Jira

Why a verdict beats a report

The take: a backlog tool that "analyzes" your tickets and hands you insights is useless. You don't have time to read insights about 400 tickets. You need a decision per ticket so the review is a yes/no skim, not a fresh analysis.

So the output contract forces exactly three verdicts and nothing else. Every ticket gets KEEP, ARCHIVE, or MERGE, plus one sentence. No "consider reviewing." No maybes. The model has to commit, and you get to overrule it fast. A list of clear wrong-sometimes calls is more useful than a pile of hedged-always observations.

Anatomy of the prompt

Rules and thresholds first, the exported tickets in the middle, the output contract last. A backlog export is long, so a contract placed up top gets buried under the ticket dump. Models weight the most recent tokens, which is why the format spec sits at the end.

Role: You are a backlog triage assistant.

Stale threshold: {{stale_after}}   // e.g. 90 days since last update
Strategic context: {{product_context}}   // what the team is actually building now

Tickets (exported):
{{ticket_export}}   // one per row: key, title, updated date, status, description

Output format:
Per ticket: Key | Verdict (KEEP/ARCHIVE/MERGE) | One-line reason
For MERGE rows, name the target ticket key it should merge into.
Group MERGE candidates together at the end.
Return only the verdict table. No preamble, no summary paragraph.

Where the models differ

This job rewards a model that holds the whole list in working memory to catch duplicates. Claude is stronger here: it'll spot that JIRA-204 and JIRA-388 describe the same feature 180 tickets apart, because it tracks the earlier rows. GPT-4o is faster per ticket but its duplicate detection degrades on long exports unless you batch the input into chunks of 50 or so. Gemini handles the staleness math fine but over-archives, flagging anything old even when the {{product_context}} says it's still relevant. Knowing that, lean on Claude for de-duplication and double-check Gemini's ARCHIVE calls.

Step-by-step usage

1. Export the backlog

Pull a CSV with key, title, last-updated date, status, and description. Those five fields are what every verdict rests on.

2. Set the thresholds

Fill {{stale_after}} with a real age, and {{product_context}} with one or two sentences on what the team is building. That context stops the model from archiving a still-relevant ticket just because it's old.

3. Run it in batches if needed

Past roughly 150 tickets, split the export. Duplicate detection holds up better on chunks the model can fully reason over.

4. Review the verdicts

Skim the ARCHIVE rows for anything strategic the model missed. Check every MERGE pair is a genuine duplicate before you act.

5. Apply in Jira

The prompt doesn't touch Jira. You apply the changes you agree with, by hand or via your integration.

Prompt-craft patterns

Pattern one: name the merge target. A MERGE verdict with no target is useless. Force the model to say which key the ticket merges into, so the action is unambiguous.

For every MERGE verdict, state the destination ticket key.
A MERGE with no named target is invalid; mark it KEEP instead.

Pattern two: tie staleness to context, not just age. A 200-day-old ticket on a feature you're shipping next month is KEEP, not ARCHIVE. Feeding {{product_context}} lets the model weigh relevance against age instead of archiving on a calendar alone.

Pattern three: ban the summary. Append "no summary paragraph" to the contract. Otherwise the model writes a reflective wrap-up about backlog health that you'll never read, and it costs tokens you're paying for on a long export.

Variables you'll set

Getting started

1. Export the backlog with the five required fields into {{ticket_export}}.
2. Set a real {{stale_after}} age.
3. Add {{product_context}} so the model weighs relevance, not just age.
4. Run the prompt, in batches if the list is long.
5. Verify every MERGE pair is a true duplicate.
6. Apply the verdicts you agree with in Jira.
7. Save the filled prompt so the next grooming pass is a paste-and-run.

The Backlog Cleanup Agent Pack ships this verdict contract with the merge-target rule and the batching guidance baked in, so a quarterly cleanup stops being a dreaded afternoon.

When grooming is a recurring chore

A clean backlog makes prioritization honest, so this pairs directly with the product roadmap prompt walkthrough. The themes from your sprint retrospective prompt often point straight at which tickets are dead weight. If you're weighing a curated pack against a free template library, the Connected Roadmap Alignment Agent Pack shows what the connected versions add.