tasklisted

## Task $ARGUMENTS ## Your Instructions ### 1. Use Existing Plan or Create Task Plan **If a PLAN file was provided or mentioned** (e.g., from a prior `/plan` command) with structured phases, it is your working document — do not create a separate TASK file. **Never replace or condense a PLAN file.** It is the user's reviewed work product: goals, file references, verification details, rationale. Add tracking to it in place — convert implementation bullets to checkboxes (`- Item` → `- [ ] Item`), append new items or sections as gaps appear, update status markers as you progress — so that the checkboxes sit alongside the existing prose, never instead of it. An edit that removes more text than it adds is almost certainly wrong. **If no suitable PLAN file exists**, create a markdown file `TASK_[descriptor]_[timestamp].md` containing: - Task description - Checklist of specific steps/subtasks - Success criteria - Any dependencies or prerequisites Keep it brief: one concise line per item, links to files instead of explanations (`[config](./src/config.js)`). This is a tracking tool, not documentation. Status markers: - `[ ]` Not started - `[~]` In progress - `[x]` Complete - `[!]` Blocked or needs attention ### 2. Execute While Updating Update the checklist after every significant action — `[~]` when starting an item, `[x]` when done, `[!]` on blockers — and add subtasks as they surface. The file is the live record: sessions crash mid-run, and anyone (including a fresh session