using-task-listlisted

# Using Task List — Track Multi-Step Work `TaskCreate` / `TaskList` / `TaskGet` / `TaskUpdate` are for tracking work the user can see and inspect. They are not a notebook, not a reminder system, not a substitute for actually doing the work. ## Iron Law **A task is a unit the user could verify independently.** "Read the file" is not a task. "Refactor the auth module so tests pass" is. If you can't imagine the user asking "is task #3 done?", it shouldn't be a task. ## When to TaskCreate Yes: - 3+ truly distinct steps that span time or files - Cross-file refactor, feature implementation, debug-and-fix loops - Work where mid-flight reporting helps the user steer - Plan-mode output (one task per plan step) No: - 1-2 step jobs ("read X, summarize" — just do it) - Pure exploration / Q&A - User wants an immediate answer ("what does this function do?") - You're about to do it in the next 10 seconds anyway When uncertain: **don't**. Over-tasking is more annoying than under-tasking. ## Status Workflow — MUST ``` pending → in_progress → completed ``` - Set `in_progress` **immediately before starting** the task. Not "I'll set it when I'm done with the previous one" — right when you begin. - Set `completed` **immediately on finishing**. Don't batch 5 completions at the end of the session. - Only one `in_progress` at a time (usually). If you genuinely paused one to do another, that's fine, but rare. - Never mark `completed` if: - Tests are failing - Implementation is parti