agent-todo

name

agent-todo

description

Manage the local Agent TODO Rust + SQLite application through its versioned CLI JSON protocol. Use when the user asks to create, capture, remember, list, search, inspect, edit, reschedule, prioritize, complete, reopen, or delete TODOs; mentions deadlines, projects, tags, estimates, today's work, pending work, or tasks needing clarification; or asks an AI agent to turn natural language into structured local tasks.

Agent TODO

Use the local todo CLI as the execution and storage layer. Do not edit SQLite directly.

Resolve the command

From the project root, prefer the first available form:

1. todo when installed and available in PATH.
2. .\target\release\todo.exe on Windows when the release binary exists.
3. cargo run -- followed by the TODO arguments during development.

Use the user's --database path or TODO_DB value when one is already in scope. Otherwise use the application's default database.

Workflow

1. Identify the operation: create, list/search, show, update, done, reopen, or delete.
2. Run todo agent schema when the current protocol is not already known.
3. Normalize the request using the rules below.
4. Ask a question only when ambiguity materially changes execution. Otherwise preserve uncertainty in assumptions, confidence, and needs_clarification.
5. Send one versioned JSON request through todo agent apply so related operations share a transaction.
6. Check the exit code and JSON ok field.
7. Report the task ID and the important fields that were stored or changed.

Read references/protocol.md when constructing requests or choosing fields.

Normalize human intent

• Write title as a concise action, preferably verb + object.
• Put the definition of done in outcome.
• Put context, constraints, links, and execution details in description.
• Use start for when work becomes actionable; use due only for a finish-by deadline.
• Do not invent a clock time when the user supplied only a date.
• Use the conversation or environment timezone; record it when a time is present.
• Keep priority coarse: low, medium, high, or urgent. Do not infer urgent merely because a date exists.
• Store effort in estimated_minutes, independently from priority.
• Use project for durable grouping and tags for cross-cutting context.
• Preserve the exact request in source_text and set source_kind to agent.
• Record explicit date/person/object interpretations in assumptions.
• Set confidence from 0 to 1 based on structural certainty.
• Use a stable unique client_token for retry-safe creates.

Clarification policy

Ask before writing when the missing answer changes the task's identity, responsible object, or important deadline and the user expects a precise task.

If the user mainly wants fast capture, create the task with needs_clarification: true and explain what remains unresolved.

Do not ask merely because project, tags, estimate, or notes are absent.

Safety and behavior

• Confirm permanent deletion unless the user explicitly requested deletion of a clearly identified task.
• Search or list before updating when an ID is not known. Do not guess IDs.
• Use one transaction for multiple related changes.
• Do not promise reminder notifications; the current product stores dates but does not yet deliver reminder alerts.
• Do not store passwords, API keys, tokens, or other secrets in task content or metadata.
• Do not silently report success when the command failed or returned ok: false.

Response style

After success, respond compactly with:

• action performed;
• task ID and title;
• deadline/start time when relevant;
• any assumption or unresolved clarification.

Example: 已创建 #12「提交报销材料」；截止 7 月 22 日 15:00。假设“下周三”指 2026-07-22。