Backlog refine

Skill carinyaparc/skills/skills/backlog-refine

Carinya Parc Agent Skills

Install

npx -y skills add carinyaparc/skills --skill backlog-refine

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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/{epic}/tasks.md. 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 an epic against its acceptance criteria (validate).

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.7 KB, as published. Nobody here has run it

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/delivery-conventions.md for paths and slug resolution, and ../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	`docs/product/backlog.md`	Planning-ready?
Epic slug or ID	`docs/work/{epic}/tasks.md`	Sprint-ready?
Both named	Both, in that order	Both verdicts

This skill runs on a recurring cadence against backlog.md, which is long-lived and groomed every sprint, and as a pre-commit gate against a specific epic's tasks.md. Same activities, different artefact.

Grooming pass

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

Remove. Defer items no longer serving a roadmap phase or product outcome. Record each with a reason; never delete silently.
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.
Prioritise. By value, risk, and dependency order. An item that blocks three others is not a P2 regardless of its own value.
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.
Tighten acceptance. Make Then clauses observable. Apply EARS where a rule is clearer than a scenario, per ../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; slugs from the title, at most two words, not the Epic ID
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 design.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, design
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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.