triage-backlog
Skill0 starsChanged 6 months agoMITView on GitHub
Triage BACKLOG items for continued validity — verify each item's claim against the current tree and rule it keep / already-delivered / partially-delivered / duplicate / retire, with evidence per verdict. Use when the user asks to triage the backlog, check whether an item is still valid or still required, find stale / redundant / already-done backlog items, verify the backlog against HEAD, or invokes /tandem:triage-backlog. Operates as PM hat. Upstream of refine-backlog — judges whether an item deserves refinement at all; never runs DoR, never promotes to ready.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- phmatray/ai-migration-kittheir own version, first seen Sep 14, 2026
- phmatray/tagouttheir own version, first seen Sep 14, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- phmatray/ai-migration-kit★ 4same name
- phmatray/tagout★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- _00-Project-Management/CLAUDE.mdCLAUDE.md
- autopilotSkill
- close-out-storySkill
- close-phaseSkill
- coreSkill
- critiqueSkill
- curate-toolkitSkill
- documentSkill
- draft-epicSkill
- draft-okrsSkill
- draft-prdSkill
- execute-batch-parallelSkill
- execute-batchSkill
- execute-storySkill
- execution-strategistSkill
- fill-claude-mdSkill
- installSkill
- modeSkill
- monthly-retroSkill
- path-scope-exampleSkill
- peer-reviewSkill
- plan-driftSkill
- refine-backlogSkill
- reflectSkill
- run-testplanSkill
- session-startSkill
- split-into-featuresSkill
- split-into-storiesSkill
- start-phaseSkill
- updateSkill
- weekly-monitorSkill
- write-outcomesSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 28
If the user supplied nothing, default to every not-started BACKLOG item — a full-corpus triage is the normal cadence, not the exception.
- Very specific: line 32
Use Read / Glob to detect existence.
- Distinctive: line 59
Check the item against its siblings for duplicate claims and merge groups.
- Very specific: line 63
Write the triage report to _00-Project-Management/41-Reports/audits/backlog-triage-<YYYY-MM-DD>.md (frontmatter: title:, type: report, …
- Very specific: line 64
Run npm run pm:lint; if any item file changed, regenerate the dashboard (npm run pm:dash) and add a MONITOR revision-history line.
- Very specific: line 77
Never promote: No verdict here flips anything to ready — route survivors to refine-backlog.
- Distinctive: line 79
Prefer merges over multiplication: where 2–3 items share a root cause, record one merge group rather than three refinement candidates.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Tandem: triage-backlog (PM hat)
Operate as PM hat. The user wants to know which BACKLOG items are still worth holding — not whether they are ready (that is /tandem:refine-backlog's DoR gate), but whether they are still true: does the claim still reproduce at HEAD, did a later epic already deliver it, does another item say the same thing, has the premise evaporated?
Operating principle: a triage that kills items is worth more than one that promotes them; only work carrying a real testable claim earns a story. Status fields lag reality — the known failure modes are items silently completed by later epics, and items partially delivered under their own name without the file being updated.
triage-backlog vs refine-backlog (do not blur)
triage-backlog (this skill) | refine-backlog | |
| Question | Is this item still valid / required? | Is this item ready to work? |
| Checks against | The current tree, git history, ADRs, sibling items | The SOP §6 DoR checklist |
| Can flip status to | done / duplicate / wontfix / archived (terminal, evidence-gated) | ready |
| Never does | Runs DoR, promotes, writes stories | Digs git history / probes for delivery evidence (its Premise check resolves frontmatter only) |
Triage runs first. Its survivors are refine-backlog's input.
Inputs needed
- Either:
- One or more BACKLOG paths (
_00-Project-Management/11-Backlog/BACKLOG-NNNN-<slug>.md). - A scope: "the whole backlog", "everything not-started", "items older than N days", "EPIC-NN's intake items".
- One or more BACKLOG paths (
- If the user supplied nothing, default to every
not-startedBACKLOG item — a full-corpus triage is the normal cadence, not the exception.
Load into context
Use Read / Glob to detect existence. Treat missing files as "not present" rather than throwing.
- Target item(s) — end-to-end, including tranche checklists and acceptance sections.
- The tree at HEAD — the artefacts, scripts, or behaviours each item's claim names. The claim decides what to open; do not skip this because the item "looks obviously open".
- Git history —
git log --oneline -- <named-paths>for evidence that work shipped after the item was captured. - ADR folder —
_00-Project-Management/40-Decisions/for decisions that supersede or invalidate an item's premise. - Sibling backlog items — for duplicate/merge detection across the corpus.
- SOP —
_00-Project-Management/90-Standards/SOP.md§15 (sunset rule). - Most recent prior triage report — glob
_00-Project-Management/41-Reports/audits/backlog-triage-*.md; re-verify, never inherit, its verdicts. - Project root
CLAUDE.md— for project-specific overrides.
Verdict set (closed — one per item)
- STILL-VALID — the claim reproduces at HEAD. Status unchanged.
- ALREADY-DELIVERED — the work shipped. Under the item's own claim → propose
done; under a different artefact's name → proposeduplicatewith the superseding artefact named. - PARTIAL — a named tranche shipped, remainder stands. Annotate delivered-vs-remaining in the item file; status stays
not-started. - DUPLICATE / MERGE-CANDIDATE — another open item carries the same claim. Propose
duplicateon the weaker item, or record a merge group ("one decision, not several stories"). - OBSOLETE — the premise no longer exists (feature removed, decision reversed, envelope re-pinned). Propose
wontfixorarchivedper SOP §15. - DECISION-ONLY — needs an operator ruling, not code. Surface the decision; take no action silently.
- TRIGGER-GATED — the item's own text defers it behind a named trigger. Verify the trigger has not fired; leave.
- PRODUCT-BET — PRD-level scope, not story-level. Route toward
/tandem:draft-prdor an epic split; do not story-ify.
Task
- Resolve the target set. Read each item end-to-end.
- Per item, extract the testable claim — what the item asserts is broken, missing, or needed. An item with no extractable claim is itself a finding (OBSOLETE or DECISION-ONLY).
- Verify the claim against HEAD, not against the item's own prose: open the named files, run the named probes where runnable, check git history for delivery, check ADRs for supersession. Record one line of evidence per verdict (commit hash, file:line, probe output, ADR id).
- Check the item against its siblings for duplicate claims and merge groups.
- Apply the sunset lens (SOP §15):
not-started> 90 days with no movement and no live trigger → propose retirement, not perpetual holding. - Assemble the verdict table (see Output rules) and show it before touching any file.
- Apply changes per the status-flip rules below.
- Write the triage report to
_00-Project-Management/41-Reports/audits/backlog-triage-<YYYY-MM-DD>.md(frontmatter:title:,type: report,generated_at:): verdict summary table, partials with delivered-vs-remaining, merge groups, decisions owed to the operator, and the post-triage shortlist of items that earn refinement — each with priority, estimate, and any known DoR gaps, not silently promoted. - Run
npm run pm:lint; if any item file changed, regenerate the dashboard (npm run pm:dash) and add a MONITOR revision-history line.
Status-flip rules (evidence-gated, never silent)
- Annotations are free: PARTIAL delivered-vs-remaining notes, stale-title corrections, and trigger records may be written directly into item files during the pass.
- Terminal flips are gated: flipping to
done/duplicate/wontfix/archivedrequires the evidence line in the verdict table AND operator confirmation from that table — never flip terminal status in the same breath as discovering the evidence. - A
duplicateflip MUST name the superseding artefact in the item body (one sentence, e.g. "Superseded by STORY-NN.M.PP") or asuperseded_by:field — validator W6 flags a bareduplicate(and a barewontfix). - Terminal flips set
completed_atatomically in the same edit as thestatus:flip. Never touchstarted_at. - Status enum is closed (
not-started | ready | in-progress | in-review | done | blocked | wontfix | duplicate | archived) — do not invent triage states in frontmatter; verdicts live in the report, statuses in the enum.
Output rules
- Verdict table first, files second. Columns: Item · Verdict · Evidence · Proposed action.
- Never promote. No verdict here flips anything to
ready— route survivors to refine-backlog. - Never re-file killed claims. An item ruled ALREADY-DELIVERED or OBSOLETE does not get a fresh BACKLOG entry restating it.
- Prefer merges over multiplication: where 2–3 items share a root cause, record one merge group rather than three refinement candidates.
- A worked full-corpus example (72 items, four parallel verification passes, verdict counts, merge groups, shortlist-with-gaps) lives at
_00-Project-Management/41-Reports/audits/backlog-triage-2026-08-28.md— match its report shape when in doubt.
Non-negotiable rules from CLAUDE.md
- Frontmatter timestamps — terminal flips set
completed_atin the same edit; nothing else changes timestamps. - Status enum — closed 9 values; verdicts are report vocabulary, not new statuses.
- Bug-auto-raise — if verifying a claim exposes a live defect (not just a stale item), file the BUG in the same response.
- Dashboard currency — any artefact change ends with
pm:lintclean andpm:dashregenerated.
End-of-session summary (always emit)
- Items triaged: N (of M in scope)
- Verdicts: STILL-VALID x · ALREADY-DELIVERED x · PARTIAL x · DUPLICATE x · OBSOLETE x · DECISION-ONLY x · TRIGGER-GATED x · PRODUCT-BET x
- Terminal flips applied (with evidence): list, or "none — awaiting operator confirmation"
- Merge groups recorded: list
- Decisions owed to the operator: list
- Report written:
41-Reports/audits/backlog-triage-<date>.md - Refinement shortlist (with DoR gaps): top 3–5 items
Next command
Next: /tandem:refine-backlog — run the DoR gate over the shortlist survivors.
Or, if the triage surfaced PRD-level scope: /tandem:draft-prd.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

