---
name: groom-backlog
description: Review the fetched backlog and flag what's not ready to work — rough-size each ticket (S/M/L), call out under-specified tickets (missing acceptance criteria or grain) and stale ones, and surface them for the lead. Advisory by default; updates the PM tool only on approval.
disable-model-invocation: true
argument-hint: "[scope, e.g. 'this sprint' | discipline tag]"
---

# Groom the backlog

A backlog full of vague or stale tickets stalls the team — work starts, hits an unanswered question, and bounces back to plan mode. This skill grooms the backlog *before* work starts: it rough-sizes each ticket, flags the ones that aren't ready, and hands the list to the lead. It complements the `ticket-fetcher` (which captures tickets faithfully but doesn't judge their readiness) — grooming is the judgment pass the fetcher deliberately leaves out.

`$ARGUMENTS` may scope the pass (e.g. `this sprint`, a discipline tag like `ae`, or a repo path).

This skill is **advisory**: it produces a grooming report and proposed tags. It modifies the PM tool only if the user approves the changes.

## What it checks per ticket

1. **Effort size (t-shirt).** Assign `size:S` / `size:M` / `size:L` from discipline + scope heuristics:
   - **S** — a single model/column change, one connector field, a config tweak, a focused bug fix.
   - **M** — a new model + tests, a new connector source, a dashboard with a few charts, a multi-file refactor in one layer.
   - **L** — a new pipeline end to end, a dimensional remodel, anything spanning multiple layers or disciplines, or anything with material unknowns.
   - Size is a rough planning signal, not a commitment. When a ticket is too vague to size, that itself is a readiness flag (below) — tag `size:?`.

2. **Readiness — under-specified.** Flag tickets missing what an implementer needs to start without guessing:
   - No **acceptance criteria** (what does "done" look like?).
   - Ambiguous **grain / scope** for `ae`/`da` work (per-what? which entities? which date range?).
   - No **source** identified for `de` ingestion work.
   - A cross-discipline ticket not split into per-discipline subtasks (the fetcher usually splits these — flag any that slipped through).

3. **Staleness.** Flag tickets that look abandoned or overtaken: long-untouched, past a `due:` date with no progress, or superseded by a merged PR (cross-check `MEMORY.md` and recent PRs). Recommend close / re-scope / re-prioritise — don't auto-close.

## Output

A grooming report grouped by readiness:

- **Ready** — sized, criteria present, dependencies clear. Count only, with sizes.
- **Needs detail** — per ticket: what's missing and the one question that would unblock it.
- **Stale / overtaken** — per ticket: why, and the recommended action.

Then, **on approval**, apply the agreed changes to the PM tool (size tags, a comment listing the open questions, status changes for stale tickets). Tool-agnostic; lead-only for the write step.

## Steps

1. Pull the in-scope backlog (from the task list and/or the PM tool).
2. For each ticket: size it, check readiness, check staleness.
3. Render the grooming report.
4. Present proposed PM-tool changes for approval; apply only what's approved.
5. Report what changed and what still needs a user decision.

## Boundaries

- **Advisory first** — never silently rewrite or close tickets; the report and the approval gate are the point.
- **Sizes are estimates** — label them as planning signals, not commitments; re-size when scope changes.
- **Don't invent acceptance criteria** — flag their absence and ask; writing them is the requester's call, surfaced for the lead.
- **Tool-agnostic, lead-only writes** — respect the PM-tool gotchas the `ticket-fetcher` documents. Never read, request, or echo credential values.