Living E2E Checklist

Keep a single live task list that the human can watch from start to finish. The list holds the whole road to done (not just the coding, but PR-readiness, opening the PR, handling review, merging, shepherding the deploy, and cleanup), and the agent works from it and keeps it current as it goes.

The point is not where the list is stored. It's that the agent reliably puts the plan in one place, works from it, and keeps it up to date, so the human never loses the thread on what a session is about or what's left, even with several agents running at once.

Why this matters

A task list that the agent actually maintains gives you two things at once:

1. A complete plan. Execution steps for the entire lifecycle, so "done" means shipped and cleaned up, not "code written."
2. Live observability. You can glance at the list and know what's done, what's in flight, and what's left, without reading the whole transcript.

The failure mode this fixes: agents that plan in prose, drift from it, never update their todo tool, and stop the list at "code written." When the list goes stale, you lose the thread, and that's worst exactly when you're running multiple agents in parallel.

The lifecycle spine

Build the list around the full path to production, not just the code. In the default stages below, each item carries its actor tag (🤖 agent, 🧑 human, 🧑🤖 both) so the template models the ownership marking instead of dropping it:

Plan       ⬜ 🤖 Confirm scope and write the plan
           🔍 🧑 Review gate: human approves the plan
Build      ⬜ 🤖 (feature work: one item per verifiable step)
           ⬜ 🤖 Tests pass / typecheck / lint clean
PR-ready   ⬜ 🤖 Code style + conventions (per repo standards)
           ⬜ 🤖 Self-review the diff
           ⬜ 🤖 Update docs / changelog
Ship       ⬜ 🤖 Open PR (Closes #N)
           ⬜ 🤖 Self-review + clear every automated/bot/CI comment before human review
           🔍 🧑 Human review gate (reached only once the PR is clean)
           ⬜ 🤖 Address human review comments (one item per thread)
           ⬜ 🤖 Merge
Deploy     ⬜ 🤖 Watch CI / deploy to green
           ⬜ 🧑🤖 Verify in the deployed environment (human if it needs a browser/device)
Cleanup    ⬜ 🤖 Delete branch + worktree
           ⬜ 🤖 Close issue / update tracking

Drop stages that don't apply, but start from the full spine so the tail of the work (deploy, cleanup) is on the list from the beginning instead of being forgotten once the code merges.

The list is also a place the human can add to. When asked to fold in another step ("also handle the changelog," "also redeploy staging"), add it to the list rather than tracking it loosely in conversation. That's what makes the agent able to drive the entire end-to-end process.

The discipline

1. Write the list early. Before execution, turn the plan into a concrete list covering the lifecycle above. Don't start coding with an empty list.
2. Work from the list. The list drives the work, not the other way around. Each step you take should correspond to an item.
3. Exactly one item in progress. Mark an item in-progress when you start it, completed the moment it's done, then move to the next.
4. Keep it current, rewrite on every state change. The list must always match reality. A stale list is worse than none, because it lies about progress. Re-emit the full list on each update rather than patching it silently.
5. Carry it to the end. The list isn't done when the code is. It's done when the deploy is green and the branch/worktree are cleaned up.

Mark who each item is for

A checklist that mixes agent and human work must say, per item, whose hands it's in. The agent owns most of it (code, tests, PR mechanics), but some steps are irreducibly human: approvals and review gates, anything needing sudo or physical/multi-machine access, and visual confirmation the agent can't perform. When ownership is left implicit, the human steps hide inside a wall of agent tasks and stall silently, waiting on someone who doesn't know it's their turn.

Tag every item with its actor, and keep the tag scannable (a leading marker or an Owner column, wherever a glance catches it):

• 🤖 agent: done autonomously by the agent.
• 🧑 human: only a person can approve, sudo, touch a second machine, or eyeball a screen. Every review gate (🔍) is a human item.
• 🧑🤖 both: the agent prepares or scripts it, then a human runs the last mile (installs the trust root, carries a key between machines, takes the screenshot).

The payoff is the same as the rest of the checklist: the human can look once and see exactly which items are waiting on them, instead of reverse-engineering it from the task text.

Mapping to agents

The structured-todo primitive already exists in most agents; the gap is using it this way, every time.

• Claude Code: use TodoWrite. It renders as a live checklist and is the right primitive: write it early, full-rewrite on each change, one in_progress item, and extend it past coding through the lifecycle spine.
• Pi: pi-manage-todo-list exposes the same read/full-rewrite contract and a live widget; same discipline applies.
• Plain fallback: when there's no live todo surface, keep a plan.md open as the work runs and edit it as state changes, so there's still one always-current place to watch.

The render differs per agent; the discipline doesn't. The behavior (create it, work from it, keep it live, carry it through deploy and cleanup) is the whole value.

See also

• Plan: The planning procedure that produces this checklist from an issue and pushes it into the live todo surface.
• Proof of Work: Pair each "it works" item with concrete evidence a human can check, so the list reflects proven progress.
• Claude Code Done Marker: Mark a session done once the list is fully carried through deploy and cleanup.
• Test-Driven Development: One task = one test = one observable behavior, a natural source of Build-stage items.
• Phased Migrations: Reversible, verifiable steps that map cleanly onto list items.