todos · git:20260721.eb587ed · 2026-07-21 · sha256 c4472117af291662
todos git:20260721.eb587edA
Immutable. This exact content is served forever at /api/v1/blob/c4472117af291662.
---
name: todos
description: "This chat has a shared, live TODO list — your current plan, which the user also edits. Read this skill and reach for the todo_* tools whenever a request takes more than a couple of steps. It covers how to work with it: propose the plan FIRST (todo_write before you ask questions or start work — it's the living plan, not a post-approval checklist), refine it in place, keep status current, re-read the list (source of truth) to sync with the user's edits, respect removals, and never delete done items."
---
# Chat TODO list
## What it is
- A checklist **scoped to this chat** — your working plan for the conversation. Shown to the user in the
Todo panel; lives with the session (not committed to the repo).
- Each item has a **title**, a **status** (`pending` → `in_progress` → `done`), and an optional **note**.
- The plan is **loose items** (standalone tasks) plus optional named **groups**. When the work splits
into distinct threads/areas, give `todo_write` a **`group`** (a title + its own list of items) — author
the group as a whole, don't tag each item. `todo_add` takes an optional `group` to slot one in (created
if new). A simple plan is just loose items, no groups. **The user's own items always stay loose** — you
work them, but never fold them into a group or drop them.
- It is **shared and live**: you maintain it, and the **user edits it while you work** — adding tasks,
removing ones they've dropped. So the stored list is the **source of truth**; what you
remember is only a snapshot. **Re-read it (`todo_list`)** to stay in sync, don't trust your memory of it.
- It is **the user's status window** — how they follow what's happening at a glance. Write short, concrete
item titles, and keep statuses current, so the list always reflects reality without them asking.
## Working with it
1. **Propose the plan first — it's the point of the list.** The moment you understand a request that
takes more than a couple of steps (research, a multi-file change, distinct sub-tasks), your first
action is **`todo_write`** with your proposed ordered plan — **before** you ask clarifying questions
and **before** you start the work. The list is your *current plan*, shown to the user as you form it,
not a checklist you backfill once the plan is approved. Then refine it in place: as you learn more,
ask questions, or the user steers, update the items so the list always reflects what you now intend to
do. (A one-shot answer or single edit needs no list.)
2. **Work the loop, syncing as you go:**
- `todo_update` an item to `in_progress`, do it, then `done`. Keep status honest — it's the user's
only window into your progress.
- **Before each next item, `todo_list` again.** The user may have edited mid-work: pick up anything
new, and if an item you planned is gone, they dropped it — **skip it, don't re-add it**.
3. **Reconcile before you finish.** At the end of a turn, `todo_list` once more. If pending items remain
(including ones the user just added), either do them or clearly say what's left and why — don't go
idle silently leaving fresh items untouched.
## Invariants
- **Done stays.** Completing an item = `todo_update` → `done`. **Never delete a done item** — it's the
user's history. `todo_remove` is only for when the user explicitly asks to drop something.
- **Edit surgically.** After the first plan, use `todo_update` / `todo_add` (they touch one item).
**Never `todo_write` to tweak** an existing list — it replaces everything and erases done items;
`todo_write` is only for laying out a fresh plan.
- **Respect the user's edits.** The list is shared; treat their additions as new requests and their
removals as cancellations. Items the user added are theirs — do them, but don't rewrite or drop them
when you re-plan. (`todo_write` preserves user items and done items for you, but don't lean on that —
reach for `todo_add`/`todo_update` to edit, and keep `todo_write` for a genuinely fresh plan.)
## Tools
- `todo_list` — read the current list (the source of truth; re-read to catch the user's edits).
- `todo_add` — append one item (leaves the rest, incl. done, untouched).
- `todo_update` — progress/edit one item (`in_progress` on start, `done` when finished; done stays).
- `todo_remove` — delete one item (only when the user asks).
- `todo_write` — lay out a fresh plan (replaces the whole list — use once, at the start).