Turn a swampy task list back into a groomed pool: one goal at a time, decide what's still real, what's next, and what can go — so /week-plan pulls from decisions you already made instead of a flat dump.
Usage
/goal-backlog— Walk every group, one goal at a time/goal-backlog Q3-2026-goal-2— Groom one goal only
The one rule that overrides everything
Never delete or move a task silently. Every exit from the backlog is the user's decision, and before any line is removed or relocated you show the exact lines that will change. Completing a task through the Work MCP is the only exit that needs no preview, because nothing is removed.
Step 1: Load the backlog
Call get_goal_backlog(goal_id="all") (or the single goal ID the user named).
Handle the response per CLAUDE.md's feature_status convention:
off(Quarter Goals room off): one calm line with the returneduser_message, no error tone, and stop — there is nothing to groom without goals.not_installed/broken: surface the returneduser_messageand its fix path, then stop.unknown, or the tool errors: say the backlog could not be checked. Do not improvise a grooming pass from grep.
If the pool is empty (open_task_count is 0), say so plainly and stop — no invented work.
Then show a one-screen overview in plain language, largest and stalest groups first:
"27 open tasks. Goal 2 (Launch mobile beta) holds 14 — 9 untouched for 3+ weeks. Goal 1 holds 6, all fresh. 5 tasks serve a pillar but no goal, and 2 are linked to nothing at all. Where do you want to start?"
Staleness comes from each task's staleness_days (age since the task was created); a group's stale_count uses the 3-week line the tool reports. Say "sat untouched for 3+ weeks" — never dress the number up as activity data it isn't.
Step 2: Groom one goal at a time
For the chosen group, show: the count, the stale flags, tentative (?) links, and the current next-up order if one exists. Keep it to one screen; titles and ages, not raw metadata.
Work through three passes, in this order:
2a. Settle the doubtful links
For each task marked tentative, ask one short question — "Does 'Draft partner FAQ' really serve this goal?" — and call confirm_goal_link(task_id, action="confirm") or action="clear". Cleared tasks fall back to their pillar group; mention that so they don't seem to vanish.
2b. Retire what's dead — completion is not the only exit
For stale items (and anything the user calls out), offer four honest exits:
| Exit | What happens | How |
|---|---|---|
| Done | It was actually finished — mark it complete everywhere | update_task_status(task_id, status="d") |
| Someday | Still real, not this quarter — park it out of the open pool | Move the task line and its indented child bullets from 03-Tasks/Tasks.md to 03-Tasks/Someday.md (create that file with a one-line header if missing). Show the exact lines before moving. Nothing is deleted; moving the lines back revives the task. |
| Delete | It's noise — remove it for good | Show the exact lines that will be removed and get an explicit yes for that task first. Never batch-delete on one blanket approval. |
| Keep | Still earning its place | No change |
2c. Set the next-up order for the survivors
Ask the deciding question plainly: "When this goal gets week-time, what should be picked up first?"
For each item the user sequences, call set_task_next_up(task_id, next_up=N) (1 = first). To drop something out of the order, set_task_next_up(task_id, next_up=null). Suggest an order from priority and age if asked, but the user ranks — don't renumber a queue they already set without asking.
Step 3: Pillar-only and orphaned work — last
After the goal groups, walk the pillar groups, then the fully orphaned tasks:
- For each, offer to link it to a goal — or consciously leave it operational; not everything must ladder up, and saying so is a fine outcome.
- To add a link, append the documented indented child bullet under the task line in
03-Tasks/Tasks.md— for example- Goal: Q3-2026-goal-2— matching the metadata format Dex writes itself. Show the edit before making it. - Orphans with no pillar either get a pillar bullet the same way or stay put by choice.
Pillar groups can carry a next-up order too — same question, same tool.
Step 4: Provisional goals — offer once, then move on
A group flagged provisional was recovered from freeform text: its ID is generated and tasks cannot link to it until it is structured. Offer once:
"Two of your goals were recovered from freeform notes. Want me to structure them into the quarter goals page shape (
### N. Title — **Pillar** ^Qn-YYYY-goal-N) so tasks can link to them?"
If declined, drop it — don't raise it again this session, and don't repeat the offer per goal.
Step 5: Close with a one-screen summary
End with exactly what changed, nothing rhetorical:
"Grooming done.
- Goal 2: confirmed 2 links, cleared 1, marked 1 done, parked 3 in Someday, next-up order set (3 items).
- Goal 1: untouched — all fresh.
- Linked 2 pillar tasks to Goal 3; left 3 operational by your call.
- Deleted 1 task (you approved the exact line).
/week-planwill now pull each goal's next-up items first. To undo an order, ask me to clear next-up on a task; to revive a parked task, move its lines back from03-Tasks/Someday.md."
Quality bar
A good grooming pass leaves every surviving task deliberately kept, every stale item decided (not re-snoozed by silence), and at least the most active goals with a next-up order /week-plan can pull from. The user should be able to say afterwards what left the pool and why.
Anti-patterns
- Deleting or moving anything without showing the exact lines and getting a yes. This is the cardinal sin of a groomer.
- Marking a task done to tidy it away. Done means finished; use Someday or delete for the rest.
- Nagging about provisional goals after one declined offer.
- Renumbering the user's existing next-up order on your own initiative.
- Grooming into planning. Choosing the week's priorities is
/week-plan's job; hand off there instead of duplicating it.
Track Usage (Silent)
Update System/usage_log.md to mark goal-backlog grooming as used.
Analytics (Silent): Call track_event with event_name goal_backlog_completed and properties goals_groomed, tasks_retired, next_up_set. Fires only if the user opted into analytics; no action if it returns "analytics_disabled".