Todo

• Always treat that file as the source of truth.
• Never rely on chat memory alone for the latest task state.
• Create the todo-skill directory and todo-list.json file if they do not exist.

Required workflow

1. Read todo-skill/todo-list.json before answering any task-management request.
2. If the file does not exist, create it with the schema in this document before continuing.
3. After every add, remove, block, or unblock action, write the full updated JSON back to disk.
4. If the file exists but is invalid JSON or does not match the schema, repair it into a valid structure, preserve any recoverable items, and mention that repair in your response.
5. If the user request is ambiguous, ask a clarifying question instead of guessing.

Supported actions

• Add a task. Create a new item unless an equivalent active item already exists.
• Block a task. Change the matching item to status: "blocked". If the task does not exist and the request is clear, create it directly as blocked.
• Unblock a task. Change the matching item back to status: "todo" and clear blockReason.
• Remove a task. Delete only the matching item. If multiple items could match, ask for clarification.
• Read the list. Summarize tasks grouped into TODO and BLOCKED.

File format

Use this JSON shape:

{
  "version": 1,
  "updatedAt": "2026-03-22T00:00:00.000Z",
  "items": [
    {
      "id": "task-1",
      "title": "Example task",
      "status": "todo",
      "createdAt": "2026-03-22T00:00:00.000Z",
      "updatedAt": "2026-03-22T00:00:00.000Z",
      "blockReason": null
    }
  ]
}

Field rules

• Keep version at 1.
• Generate stable, human-readable IDs such as prepare-demo or task-2.
• Keep titles concise and preserve the user's intent.
• Use only todo or blocked for status.
• Use ISO timestamps for createdAt, item updatedAt, and top-level updatedAt.
• Keep blockReason as null unless the user gave a reason or a short precise reason is clearly implied.

Mutation rules

• Avoid duplicate active items that describe the same work.
• Preserve existing IDs and createdAt values for unchanged items.
• Update the touched item's updatedAt whenever you modify it.
• Update the top-level updatedAt on every write.
• Keep untouched items in their original order unless there is a strong reason to reorder them.

Response style

• After each mutation, say what changed.
• When showing the list, group tasks into TODO and BLOCKED.
• Include each blocked task's reason when one exists.