--- name: recall-backlog description: Triage and curate this project's persisted recall backlog - validate the open items against the current repo, apply the resulting fixes (close finished work, remove obsolete items, correct drifted ones), then rank what remains by impact and effort to recommend what to do next. Pass --clean to apply removals automatically instead of confirming them. disable-model-invocation: true argument-hint: "[--clean]" --- # Recall Backlog Triage this project's deferred-work backlog, clean it up, and surface what is worth doing next. Two read-only reviewer subagents (they ship with this plugin) do the analysis: one checks whether each open item is still real, the other scores the real ones by value. You apply the validity fixes to `backlog.md` and then report. You are the only writer here - the subagents never touch files. Closing a finished item and correcting a drifted one are safe and apply directly. Removing an item discards real deferred work if the reviewer is wrong, and the store is not under version control, so a wrong removal cannot be rolled back - which is why removals are gated by confidence and mode. ## Mode Parse `$ARGUMENTS` for the token `--clean`: - **CLEAN** - `true` if `--clean` appears anywhere, otherwise `false`. Echo the mode back in one line before proceeding: `propose` when `CLEAN` is false, `clean` when true, so the user knows up front whether removals will be applied for them. The mode only changes how removals are applied (Phase 3); everything else is the same either way. ## Locate the memory store Resolve the store paths with the recall path resolver. It derives the project's store for you, so never compute the key by hand: ```bash ${CLAUDE_SKILL_DIR}/../../hooks/recall-path.py --data-dir # the store directory ${CLAUDE_SKILL_DIR}/../../hooks/recall-path.py --backlog # backlog.md inside it ``` If the store directory or its `backlog.md` does not exist, report "No backlog found for this project." and stop. If `backlog.md` has no open `- [ ]` items, report "The backlog has no open items." and stop. Both reviewer subagents run on Sonnet, take a **batch** of items, and return one result per item, judged independently. Batching amortizes the repo grounding each agent repeats (orienting in the code, checking git history) instead of paying it once per item. **Group items into batches of roughly 5** - one agent per batch, run in parallel - preferring fewer, larger batches as the count grows, and a single batch when there are only a handful. Do not fall back to one agent per item. ## Phase 1 - validate the open items Collect every open (`- [ ]`) item from `backlog.md`. Batch them (~5 per agent) and dispatch the `backlog-validity-reviewer` subagents **in parallel** via the `Agent` tool. Pass each the absolute store path and the list of item lines verbatim. It returns, per item, `CLOSE` (already done), `REMOVE` (obsolete), `AMEND` (drifted but real), or `KEEP`, with cited evidence and a `confidence`; match each back by the `item` field. Do this first because an item still marked `[ ]` may already be done or no longer relevant - counting it as open work, or recommending it, would mislead the user. Treat `KEEP` and `AMEND` items as **genuinely open**. ## Phase 2 - score the genuinely-open items Batch the genuinely-open items (~5 per agent) and dispatch the `backlog-opportunity-reviewer` subagents **in parallel**. Pass each the store path and its list of item lines. It returns, per item, `impact` (high/medium/low), `effort` (S/M/L grounded in the actual code), `recommend_now` (yes/no), and a one-line reason; match each back by the `item` field. Running this only on the genuinely-open set keeps the recommendations honest and avoids spending analysis on work that is already done. ## Phase 3 - apply the validity fixes Turn the Phase 1 verdicts into edits to `backlog.md`: - **`CLOSE`** - the work is already done, so delete the line. Apply directly when the reviewer's confidence is high; the evidence is cited and the finished work lives on in the repo and its history, so the line records nothing the store still needs. The "Changes applied" report names every closed item, so it stays visible for the run even though the line is gone. Unlike a `REMOVE`, this discards work that is verifiably done, not a task that was never started, which is why it applies directly rather than under the removal gate. - **`AMEND`** - replace the line with the reviewer's corrected `- [ ] [S|M|L] - [#area]` line. Apply directly; it fixes drift without discarding the item. - **`REMOVE`** - this deletes the line and the deferred work it records, so it is gated by mode: - **`propose` (default):** list every removal for the user with the reviewer's evidence and get approval before deleting any of them. - **`clean`:** delete the **high-confidence** removals without asking, but still list and confirm each **low-confidence** removal first - those are the ones most likely to be wrong, and the deletion cannot be undone. - **`KEEP`** - leave untouched. Regardless of mode, confirm any `CLOSE`/`AMEND` the reviewer marked low confidence rather than applying it blind. Edit `backlog.md` in place. Do not add new items, and do not touch `learnings/` - this skill curates the backlog only. ## Report After applying the approved changes, print a compact, skimmable report. ### 1. Changes applied A one-line summary of what changed - how many items closed, removed, and amended - followed by the `CLOSE` and `REMOVE` items (with evidence), since both delete the line and this report is the only record of them, plus anything still awaiting the user's confirmation. If nothing changed, say so in one line. ### 2. Open backlog at a glance A one-line count of the items still open after the fixes, then a table breaking them down by scope (the conventional-commit section the item lives under: `feat`/`fix`/`docs`/...) and size (`S`/`M`/`L`, with a `—` column for items that carry no size tag): | Scope | S | M | L | — | Total | |-------|---|---|---|---|-------| | feat | 2 | 1 | 0 | 1 | 4 | | fix | 0 | 1 | 1 | 0 | 2 | | **Total** | 2 | 2 | 1 | 1 | 6 | ### 3. Work on next The still-open items where `recommend_now` is yes, ordered best-first. Lead with quick wins - high impact at small effort - since those are the cheapest value, then high-impact larger items. For each, give the item, its impact and effort, and the one-line reason. If nothing clears the bar, say so plainly rather than padding the list with low-value work. Keep the whole report to the table and these short lists - a triage view the user can act on at a glance, not an essay.