/clear-tasks

/clear-tasks — Resolve Open Tasks (DONE / WON'T FIX)

Clear open tasks by resolving them. "Clearing" means marking a task DONE or WON'T FIX — it does NOT delete the line. Resolved tasks stay in the file as a record but automatically drop out of /plan-day, /plan-weekend, and /review-tasks (which only match - [ ]).

Resolution semantics

Resolution	Checkbox change	Appended tags
DONE	- [ ] → - [x]	resolution:done resolved:<YYYY-MM-DD>
WON'T FIX	- [ ] → - [-]	resolution:wontfix resolved:<YYYY-MM-DD>

• resolved: date is determined at runtime from the system clock.
• Append the resolution tags at the END of the existing task line, using the same double-space separator. Do NOT remove or reorder the task's existing tags.

Recurring tasks (recurs: present) — DONE means "log a pass", not "retire"

A task carrying a recurs: tag is a standing review (see the gtd-prioritization skill's Recurring Tasks section). Its DONE semantics are different:

Resolution on a recurring task	Checkbox change	Edit applied
DONE (completed this cycle)	stays - [ ]	set/update last:<YYYY-MM-DD> to today — this rolls the next occurrence forward by one interval. Do NOT add resolution:/resolved:, do NOT flip the checkbox.
WON'T FIX (stop recurring)	- [ ] → - [-]	resolution:wontfix resolved:<YYYY-MM-DD> — retires the standing task as normal.

• For a recurring DONE: if a last: tag already exists, replace ONLY its date value; if absent, append last:<YYYY-MM-DD> at the end. Leave recurs: and every other tag untouched.
• Confirm a recurring DONE as a roll-forward, e.g. Logged pass: <title> — last:2026-06-09, next due 2026-06-12.

Argument Parsing

Parse $ARGUMENTS:

• domain (optional): if the first token matches a canonical name or alias in tasks/domains.md (read it), scope the search to that single file (tasks/<canonical>.md).
• matcher (optional): remaining free text. Case-insensitive substring match against open task titles to narrow candidates.
• If a leading token looks like a domain but matches nothing in tasks/domains.md, warn and treat the whole argument as a matcher across all domains.

Execution Steps

1. Discover & read: Glob tasks/*.md, ALWAYS excluding inbox.md by basename. If a domain was supplied, restrict to that file. Read the file(s).

2. Collect open candidates: parse only incomplete tasks with regex ^- \[ \] (.+)$ (ignore - [x], - [-], comments, headers). If a matcher was given, keep only tasks whose title contains the matcher (case-insensitive). Record each candidate's file and line number.

3. Handle candidate count:

   • 0 candidates → report "No matching open tasks to clear." and STOP (no edits).
   • 1 candidate → skip selection; go straight to the resolution question for that task.
   • 2–4 candidates → ask Q1 (Select, multiSelect): one option per candidate task (label = short title, description = domain · prio · due). The user selects which to clear.
   • >4 candidates → do NOT truncate silently. Print the full numbered candidate list as text (grouped by domain, showing prio/due), then ask the user to narrow: present an AskUserQuestion with options to (a) scope to one domain, (b) re-run with a matcher, or (c) pick "Other" and type the line numbers to clear. Proceed once the selection is ≤ a workable set.

4. Ask resolution intent — ALWAYS, never assume via AskUserQuestion. The command MUST NOT clear any task without first asking whether it is DONE or WON'T FIX. Do not default or infer the resolution — the user decides explicitly.

   • Ask PER selected task so each can differ (a batch often mixes completed and abandoned tasks). Because AskUserQuestion allows up to 4 questions per call, ask one question per task in a single call when ≤4 tasks are selected; for >4, ask in successive calls (batches of 4). Each question:
     • Header: Resolution; question text names the task title.
     • Options: DONE — task completed; WON'T FIX — abandoned / no longer relevant. (User may pick "Other" to cancel clearing that specific task.)
   • Shortcut for a uniform batch: you MAY first ask one question "Same resolution for all N tasks?" with options All DONE, All WON'T FIX, Decide per task. Only if the user picks a uniform option do you skip the per-task questions; "Decide per task" falls back to the per-task questions above. Either way, the intent is always explicitly asked — never silently applied.
   • Optionally also ask a free-text Note: if provided, append it as note:"<text>" — keep it short; omit if empty.

5. Apply edits (in place, surgical): for each selected task, use Edit to change ONLY that line:

   • Recurring task + DONE (task line contains a recurs: tag and the resolution is DONE): do NOT flip the checkbox and do NOT append resolution:/resolved:. Instead set/update last:<YYYY-MM-DD> to today (replace the existing last: value, or append last:<date> if none). This is the only case where the line stays - [ ].
   • All other cases (non-recurring, or recurring + WON'T FIX): replace the leading - [ ] with - [x] (DONE) or - [-] (WON'T FIX), and append resolution:<done|wontfix> resolved:<YYYY-MM-DD> (and note:"..." if given) at the end of the line.
   • The old_string for each Edit MUST be the exact full existing line so the match is unique; NEVER touch any other line, the header, or other tasks.

6. Confirm:

   Cleared N task(s):
   - [x] <title>  (fulltime, resolution:done, resolved:2026-06-08)
   - [-] <title>  (knowledge, resolution:wontfix, resolved:2026-06-08)
   

Notes

• Non-destructive: this command never deletes task lines. To remove or archive resolved (- [x] / - [-]) lines later, that's a separate operation — ask explicitly.
• In-place edit is the intended exception to the plugin's append-only rule: clearing legitimately modifies the target task's own line. All OTHER lines remain untouched.
• Inbox (tasks/inbox.md) is never read here — clear it via the Triage agent instead.
• Resolved tasks are automatically excluded from /plan-day, /plan-weekend, and /review-tasks because those only match - [ ].
• If the user supplied a matcher that is dangerously broad (would select every open task), confirm before applying.