using-task-list
Use when deciding whether to TaskCreate. Tasks track multi-step work — don't open one for trivial single-step jobs.
Files1
View on GitHubSKILL.mdskills/using-task-list/SKILL.md
GitHubUsing 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_progressimmediately before starting the task. Not "I'll set it when I'm done with the previous one" — right when you begin. - Set
completedimmediately on finishing. Don't batch 5 completions at the end of the session. - Only one
in_progressat a time (usually). If you genuinely paused one to do another, that's fine, but rare. - Never mark
completedif:- Tests are failing
- Implementation is partial
- You hit an error you couldn't resolve
- You skipped a sub-step
If blocked, leave in_progress and TaskCreate a new task describing the blocker.
Before Creating — Check Existing
When the user gives new requirements, call TaskList first. Don't blindly TaskCreate 5 tasks if 3 already exist. Merge, don't duplicate.
1. TaskList → see what's open
2. Decide: extend existing tasks, or genuinely new?
3. TaskCreate only the new ones
Fields
- subject: imperative, brief — "Fix login redirect bug", "Add CSV export to /reports"
- description: what done looks like, with enough context that you (or another agent) could pick this up later
- activeForm: present continuous, shown in the spinner — "Fixing login redirect", "Adding CSV export"
- blockedBy: task IDs that must complete first (creates dependency)
- blocks: tasks waiting on this one
Dependencies
Use addBlockedBy / addBlocks when order matters:
Task 1: "Add user table migration"
Task 2: "Add user API endpoint" blockedBy: [1]
Task 3: "Add user UI" blockedBy: [2]
TaskList shows blocked tasks so you can pick available work.
Red Flags
- You created 3 tasks but never updated their status — task list is now a lie
- You marked completed before tests passed — you'll forget and ship the bug
- You batched 5 status updates at once at session end — the user couldn't see progress in flight
- You wrote a task but didn't reference it when you started working ("ok let me do the auth thing" instead of "starting task #2")
- You opened a task for "read README" — single step, just read it
- You used the task list as a notepad ("remember to ask user about Y") — that's not a task, that's a memory note
Examples
Good
User: "重构 auth 模块,现在登录/登出/会话刷新分散在 5 个文件"
TaskCreate("Audit current auth code — list all entry points and shared state")
TaskCreate("Design unified Auth service interface", blockedBy: [1])
TaskCreate("Migrate login to Auth service", blockedBy: [2])
TaskCreate("Migrate logout to Auth service", blockedBy: [2])
TaskCreate("Migrate session refresh", blockedBy: [2])
TaskCreate("Run full test suite, fix breakage", blockedBy: [3,4,5])
Each is independently verifiable. Order is clear via blockedBy.
Bad
User: "看一下 README 然后告诉我这个项目是干啥的"
TaskCreate("Read README")
TaskCreate("Understand project purpose")
TaskCreate("Summarize for user")
No. Just read it and answer. This is 30 seconds of work, not a 3-task project.
Mid-Flight Update — Good
[user gives a 4-step request]
1. TaskList — none exist, ok
2. TaskCreate × 4
3. TaskUpdate task 1 → in_progress
4. ... do work ...
5. TaskUpdate task 1 → completed
6. TaskUpdate task 2 → in_progress
7. ...
User sees real-time progress in the spinner via activeForm.
Mid-Flight Update — Bad
1. TaskCreate × 4
2. ... do all 4 silently ...
3. TaskUpdate 1 → completed
TaskUpdate 2 → completed
TaskUpdate 3 → completed
TaskUpdate 4 → completed
User had no visibility. The task list provided zero value.
Cleanup
- Finished tasks stay marked completed (they show in TaskList).
- If a task was wrong / superseded:
status: "deleted"(permanent removal). - Don't manually delete completed tasks just to "clean up" — the history is useful.
See Also
[[using-cron]]— for time-based reminders. Tasks don't fire on time, crons do.[[writing-plans]]— plan first, then convert plan steps to tasks.[[executing-plans]]— running tasks in batches with checkpoints.