| name | granular-visibility |
| model | sonnet |
| description | 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'. |
| category | agent-orchestration |
| triggers | ["what is the status","too many items in the list","simplify the progress tracking","long todo list"] |
| tier | 1 |
| agents | ["primary"] |
| tool_dependencies | ["file_system"] |
| inputs | [{"name":"task_list","type":"string","description":"The current task list or work description to track","required":true}] |
| outputs | [{"name":"todo_list","type":"string","description":"Granular todo list where each item maps to one discrete deliverable or decision point"}] |
Granular Visibility
Philosophy
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.
When to Use
- Any task with more than 10 discrete steps
- Multi-phase work spanning multiple tool calls or coordinated actions
- When the instinct arises to "simplify" or "clean up" progress tracking
- When working with a user who values steering and visibility over convenience
- When a todo list length triggers concern that it's "too long" — that's usually a signal the work is complex, not that the list is bloated
Workflow
Creating Granular Items
- Map discrete deliverables: One todo item per concrete output or decision point, not one per phase
- Be specific: "Read config file" is not granular; "Read config file, identify auth settings, determine if migration needed" is
- Avoid nesting: Don't hide sub-steps under parent tasks; make them visible
- Start with the full list: Granularity from the beginning creates accurate expectations
Maintaining Visibility
- Update status in real-time: Mark items
in_progress, completed, or pending as they change
- Add blockers immediately: If an item is blocked, note it — don't wait for the user to notice
- Communicate what changes: If scope shifts, show how the list evolves
- Never pre-compress: Let the user ask for a simpler view; don't offer it unprompted
Responding to "Too Long"
If the user says the todo list feels long:
- Confirm that length reflects complexity, not bloat
- Offer to reorganize (by phase, by urgency) without removing items
- Ask if they want a compressed summary in addition to the granular list
- Never delete items to make the list shorter