writing-planslisted

Write the implementation plan as if the engineer executing it has strong general skills but zero knowledge of this codebase, this domain, or your intentions. Everything they need to act has to be on the page: which files to touch, the actual code, how to test it, what "done" looks like for each step. Vagueness in a plan becomes wasted work or wrong work at execution time. A good plan is a sequence of small, verifiable tasks — each one producing a self-contained change that makes sense on its own and leaves the project working. ## Step 1: Orient before planning Read the spec or requirements fully, then look at the codebase the plan will touch — existing patterns, conventions, the files involved. Plan *with* the grain of the code that's there, not against an idealised version of it. If the spec spans several independent subsystems, say so and propose splitting it into one plan per subsystem; each plan should produce working, testable software on its own. ## Step 2: Map the files first Before writing any task, list the files the work will create or modify and the single responsibility of each. This is where the decomposition gets decided. - Give each file one clear job. Prefer smaller, focused files over large ones that do several things — they're easier to reason about and edit reliably. - Keep things that change together in the same place; split by responsibility, not by technical layer. - In an existing codebase, follow the established structure. Don't unilaterally rest