triage-backlog

Triage Backlog

Decide, entry by entry, which improvements in .turbo/backlog.md are worth keeping.

Step 1: Read the Backlog and Merge Duplicates

Resolve the repo root with git rev-parse --show-toplevel, except inside a linked worktree — where git rev-parse --git-dir differs from --git-common-dir — in which case use the parent of the common dir.

When that root holds the legacy .turbo/improvements.md, carry it into .turbo/backlog.md before reading, with the Write or Edit tool. When .turbo/backlog.md does not exist, write the legacy content there with its # Improvements header changed to # Backlog. Otherwise, append each legacy entry that .turbo/backlog.md does not already hold word for word. Once .turbo/backlog.md holds every legacy entry, delete the legacy file. When the write or the deletion is refused, tell the user what is left to do.

Read .turbo/backlog.md under that root. When it does not exist or holds no entries, present "No backlog entries to triage." Then use the TaskList tool and proceed to any remaining task.

Merge entries that cover the same improvement into one entry that keeps every detail either held, write the merged entries back, and output which ones were merged. Update each Paired with line in counterpart entries that names a title the merge retired.

Number the remaining entries in file order.

Step 2: Assess Each Entry

Work from each entry's own text. Read the code an entry names only when its text is too thin to say what the entry is for.

For each entry, settle the two parts its question in Step 3 carries, without outputting them yet:

• Story — one sentence naming who benefits and what they get, in plain language a reader who has not seen the code can follow. When nothing changes for the person using the software, tell it from the maintainer's side: what the entry simplifies.
• Recommendation — keep or drop, with a one-line reason.

Recommend keeping an entry that serves a goal the person using the software actually has, fixes a problem that was observed, or simplifies existing code. Recommend dropping one that is theoretical or was never observed, is decoration, would be resolved by another entry's fix, or adds machinery no requirement demands. For an entry carrying a Revisit line, apply these criteria to the fuller version it describes as though its condition held; the condition being unmet is no ground to drop it. When the entry's text settles neither, recommend neither and name what is unclear.