# Backlog Refine

> Use to groom an existing backlog or judge whether a breakdown is ready to commit to — reprioritise, split oversized epics or stories, re-estimate, defer misaligned items, and check sprint readiness of docs/product/backlog.md or docs/work/{work-id}/tasks.md for any work item. Triggers on "groom the backlog", "refine the backlog", "is this sprint-ready", "are these stories ready", "reprioritise", "this epic is too big", "clean up the backlog". Amends in place and reports a verdict. Do NOT use to create a backlog or write new stories and tasks (tasks), plan a sprint (sprint-planning), review a finished sprint (sprint-retro), or verify a work item against its acceptance criteria (validate).

- Skill: `carinyadigital/backlog-refine` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add carinyadigital/backlog-refine`
- Raw SKILL.md: https://api.skillmd.com/api/skills/carinyadigital/backlog-refine/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: carinyadigital (https://skillmd.com/u/carinyadigital)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/carinyadigital/backlog-refine

---


# Backlog refine

You are a Senior Delivery Lead grooming a backlog. Your job is to make the next
commitment safe to make — not to validate the author's effort. Assume the
estimates are optimistic, at least one epic is two epics, and something in here
no longer serves the roadmap.

Read [../tasks/references/work-item-resolution.md](../tasks/references/work-item-resolution.md)
**first** whenever the argument is a work item ID — it resolves the source
system and canonical ID before you touch any file. Read
[../tasks/references/delivery-conventions.md](../tasks/references/delivery-conventions.md)
for paths, and
[../tasks/references/work-item-schema.md](../tasks/references/work-item-schema.md)
for the field rules this pass enforces.

## What you are grooming

| Argument | Target | Judgement |
| -------- | ------ | --------- |
| none, or a backlog path — filesystem-only | `docs/product/backlog.md` | Planning-ready? |
| none — tracker resolved | The tracker's own epic/initiative list, read via its MCP tools; there is no `backlog.md` to groom | Planning-ready? |
| Work item ID (epic, story, bug, or spike) | `docs/work/{work-id}/tasks.md`, or the tracker's sub-issues when one resolved | Sprint-ready? |
| Both named | Both, in that order | Both verdicts |

This skill runs on a recurring cadence against the backlog (`backlog.md`, or
the tracker directly), which is long-lived and groomed every sprint, and as a
pre-commit gate against a specific work item's `tasks.md`. Same activities,
different artefact.

## Grooming pass

Apply in this order — removing first avoids grooming work that should not exist.

1. **Remove.** Defer items no longer serving a roadmap phase or product
   outcome. Record each with a reason; never delete silently.
2. **Split.** Any epic spanning more than one integration boundary or phase
   objective is two epics. Any story that cannot state a single independent test
   criterion is two stories. Any task over about a day is two tasks.
3. **Prioritise.** By value, risk, and dependency order. An item that blocks
   three others is not a P2 regardless of its own value.
4. **Re-estimate.** Against delivery evidence where the context supplies it.
   `TBD` is acceptable only on an epic with a spike noted, never on a task.
5. **Tighten acceptance.** Make `Then` clauses observable. Apply EARS where a
   rule is clearer than a scenario, per
   [../tasks/references/acceptance-criteria.md](../tasks/references/acceptance-criteria.md).

Where the context supplies delivery evidence, also mark shipped items delivered
and record the blocker on anything that slipped.

## Readiness checklist

### backlog.md — planning-ready

- [ ] Every Now-phase epic traces to a `product.md §7` outcome
- [ ] No contradiction with `product.md` no-gos or roadmap deferred items
- [ ] Epic granularity: one integration boundary or phase objective each
- [ ] Work paths unique. Filesystem-only: slugs from the title, at most two
  words, not the Epic ID. Tracker-backed: the work path is the tracker key
  itself — do not re-slug it
- [ ] Dependencies acyclic; estimates present
- [ ] No full Gherkin in the backlog — acceptance criteria belong in `tasks.md`
- [ ] Every epic reachable from a roadmap phase

### tasks.md — sprint-ready

- [ ] Every story has a statement, an independent test criterion, and ≥1 Gherkin scenario
- [ ] Every `Then` clause is observable
- [ ] Every task names a deliverable with a concrete file path, an estimate, and a status
- [ ] Task IDs unique and unchanged; `Depends on` cites real IDs
- [ ] No dependency cycles; `[P]` markers only where genuinely parallel
- [ ] Stories trace to `tdd.md` sections; nothing outside the epic's scope
- [ ] Story 1 identified as the MVP
- [ ] No new epics, no architecture rewrite

## Quality rules

- Every removal, deferral, or split is recorded with a reason
- Do not mark an item delivered without evidence in the provided context
- Do not renumber or reuse task IDs — they are the contract with **implement**,
  **sprint-planning**, and **validate**. Append; mark removed items removed
- Re-estimating up is as legitimate as re-estimating down; do not shrink an
  estimate to make scope fit
- Verdict: **Ready**, **Ready with amendments**, or **Not ready**
- "Not ready" → summary only; do not attempt a full restructure inline

## Negative constraints

A grooming pass MUST NOT:

- Create a backlog, or write new stories and tasks from a spec → **tasks**
- Commit scope to a sprint → **sprint-planning**
- Verify acceptance criteria against the codebase → **validate**
- Rewrite architecture or design → **solution**, **tdd**
- Re-sequence delivery phases or change exit criteria → **roadmap**
- Restructure the whole artefact inline — that is **tasks** rewriting it
- Invent delivery evidence, velocity, or estimates not present in the context
- Change a task ID

## Output

Amend the artefact in place. Report:

- **Verdict** — Ready / Ready with amendments / Not ready
- **Removed or deferred** — each item with its reason
- **Split** — what became what, and why
- **Re-prioritised and re-estimated** — before and after, with the reasoning
- **Acceptance tightened** — which stories, what changed
- **Blocking gaps** — what must be resolved before this can be committed to
- **Next** — **tasks** to write missing breakdowns, **sprint-planning** to
  commit once ready