Produces a granular todo list where each item maps to one discrete deliverable or decision point, maintained at real-time accuracy throughout execution. Use when: 'what is the status', 'too many items in the list', 'simplify the progress tracking', 'long todo list'.
On complex work, the user steers. Visibility is the steering wheel. Compressed progress updates remove the user's ability to see what's happening, what's next, and what might need course correction. The instinct to simplify feels helpful to the agent but serves the agent's preference for tidiness, not the user's need for control.
The chain runs in one direction: granular visibility → user sees progress → user can steer → user trusts the process → user delegates more → agent moves faster → better outcomes.
The anti-pattern runs the other way: compressed visibility → user can't see progress → user interrupts to check status → agent stops to explain → both lose momentum → trust erodes.
in_progress, completed, or pending as they changeIf the user says the todo list feels long:
Pitfall: "The list is getting long, I should simplify it before showing the user." Reality: Length reflects work complexity. Compression removes steering ability. Fix: Show the full list. If the user wants fewer items, they'll ask.
Pitfall: Creating high-level items like "Phase 1: Analysis" to keep the list short. Reality: The user can't see what needs to happen in Phase 1 until you show up with new items mid-stream. Fix: Break Phase 1 into discrete items from the start. It's okay if that creates 8 items instead of 1.
Pitfall: Assuming all users prefer simplified views and offering compression unprompted. Reality: Many users explicitly choose granular tracking and will ask if they want less detail. Fix: Default to granular. Compression is opt-in, not default.
Pitfall: Waiting until the phase is done to update the todo list.
Reality: The user sees stale status and loses confidence in the progress tracking.
Fix: Update as items change. Mark things in_progress before you start them, completed immediately after.
pending, in_progress, completed, blocked) updated as work changes stateScenario 1: User asks to migrate a codebase across 14 files with 3 decision points → skill produces a 17-item list (14 file items + 3 decision items), each named specifically (e.g., "Parse auth settings in config.go and determine if migration required"), updated to in_progress before work starts and completed immediately after.
Scenario 2: User says "the todo list feels too long" on a 22-item task → skill confirms length reflects actual complexity, offers to reorganize items by phase without removing any, and asks whether the user wants a compressed summary alongside the full list — not instead of it.
cancelled with a reason — do not silently restructure.