Dev Workflow

The end-to-end spine that carries a piece of work from an issue to a shipped, verified change. Not the techniques for changing code (see Development Methods) or the one-off chores (see Dev Tasks), but the disciplines that keep the whole journey legible and verifiable as it runs.

Four topics compose the workflow. Three form one per-item loop:

• Plan is the intent: turn an issue into a narrative plan plus a living end-to-end checklist that spans the whole lifecycle.
• Living E2E Checklist is the live status: one checklist, always current, that the human can watch from start to finish.
• Proof of Work is the evidence: each "it works" step shows concrete, checkable proof instead of asserting success.

Review gates are where a human consumes that evidence and decides pass or fail. There are several across the lifecycle, not one: the human reviews the plan, the PR, and the final cleanup, and, when they ask for it, a retrospective (usually prompted by too many process mistakes along the way). Together with the three topics, these gates form a per-item loop: plan the step, do it, prove it, gate it, check it off, live.

The fourth, Work Tracking, is the durable substrate: it persists that checklist and its history to the branch (a WORK.md per worktree) so any session, current or future, can resume the work or hand it off.

Topics

• Plan: Turn an issue into a plan plus a living end-to-end execution checklist across the whole lifecycle (plan, build, PR-ready, ship, deploy, cleanup), with proof-of-work evidence and human-review gates. Use before starting real work on an issue or a multi-step change.
• Living E2E Checklist: Keep one live task list the human can watch start to finish, spanning the whole lifecycle, not just coding. Write it early, work from it, keep it current. Use whenever a task has more than a couple of steps.
• Proof of Work: Emit concrete, checkable evidence (screenshots, captured command output, the rendered diff) so a human can verify each step fast, on top of tests. Use for any step whose point is "confirm it works," especially UI work.
• Work Tracking: Track a workstream with a committed WORK.md per worktree (purpose, done-when criteria, status, session log) so any agent session can resume it or hand it off. Use for multi-session or parallel-worktree work.

See also

• Development Methods: The techniques (TDD, refactoring, phased migrations, root-cause diagnosis) that supply the Build-stage items a plan tracks.
• Pull Request Workflow: The Ship and Deploy stages the checklist ends in.
• Begin Work: Gather issue, branch, and PR context before planning delegated issue work.
• Prompt Engineering: Task lists and target-convergence prompts for structuring and converging the steps.
• Recap Current Work: The point-in-time status the human reads from this checklist. The plan looks forward; a recap reports where it stands now, grouped by meaning with a marker per item.
• Worktrees: One worktree per workstream, the unit Work Tracking tracks.