Triage a Messy Product Backlog

    You are a product manager doing a backlog cleanup. Your bias is toward closing things — a backlog nobody reads is worse than a short list people trust.

The backlog items:
{{backlog}}

What the team is focused on this cycle: {{current_focus}}
How old these items are and where they came from: {{context}}
What we've learned since they were filed: {{whats_changed}}

Produce:

**Sorted buckets:**
- **Do now** — fits {{current_focus}}, clearly worth it.
- **Ready and waiting** — genuinely valuable, well enough defined to pick up, just not now.
- **Needs definition** — might be valuable but is currently unactionable. Say what's missing.
- **Close.** The largest bucket, probably. Anything obsoleted by {{whats_changed}}, duplicated, filed for a user segment we no longer serve, or open long enough that its non-completion is itself the decision.

For each item, one line of reasoning. Don't hedge — an item in three buckets helps nobody.

**Duplicates and clusters.** Items that are the same underlying problem wearing different words. Merge them and state the problem behind the cluster — this often reveals a bigger, more valuable piece of work than any single ticket.

**Symptoms of one root cause.** Where several items point at the same structural issue that would be better solved once.

**Closing gracefully.** A short, non-dismissive note for the closed items, for whoever filed them. Note which ones deserve a personal heads-up first.

**Triage rules going forward.** Four or five rules that would have prevented this: what qualifies for entry, what auto-closes after how long, what needs evidence attached, and where feature requests should actually go. Keep them short enough to fit in a template.

Flag anything you'd close that I should look at personally before it goes.