Skip to content

backlog-picker: the Rules bullet undercuts worth: no, and path:line is a dedupe key that drifts #478

Description

@denysshnurenko

Two things in cookbook/backlog-picker/SKILL.md that work against the skill's own goal. Both surfaced
while adapting it into a work monorepo. Happy to split them into two issues if you prefer.

1. "Prefer deleting to demoting" contradicts the worth: no rationale

The item format explains why no is a first-class value:

no is a valid answer: a real item not worth the edit still belongs here, because writing it down
is what stops it being rediscovered every review.

The Rules section then says:

Prefer deleting to demoting. An item nobody will ever do is noise; say so and offer to drop it.

"An item nobody will ever do" is the definition of worth: nolater already covers deferred work. So
an agent following the Rules section offers to delete every no item on each pass over the list, and once
one is deleted the next review rediscovers the defect and files it again. That is the loop the first line
says the backlog exists to break.

Step 4 has the reconcilable wording — "drop a named item — a no that has stopped being worth carrying" —
but it never says what makes a no stop being worth carrying, and the unconditional version sits under the
heading "Rules", which is where an agent looks for the binding form.

A charitable reading is that the bullet targets serial demotion (yeslaterno) rather than no
items as such. The wording does not say that.

We dropped the bullet, since Step 4 already covers the legitimate case.

2. where: path:line is named as the dedupe key, and it drifts

The format section names it:

where: path:line — omit when the item is not anchored to one place. The dedupe key alongside the slug.

and Appending repeats it:

Dedupe before writing, on where first and the slug second.

while the reading flow already concedes the field goes stale:

where goes stale when a file is renamed or a line moves.

So the stated dedupe key is a value the document elsewhere says drifts. Any edit above the item shifts its
line; a later reviewer who also picks a different valid slug then matches on neither key, and a second file
is written for one defect — the case Appending exists to prevent.

This needs both the line to have moved and the slug to differ, so it is narrower than #1. The cheap fix is
to dedupe on the path and treat the line as a hint: the path survives the edits that move the line, and
it is what the agent has in hand anyway.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions