writing-plans

An implementation plan breaks down feature specifications into short, 2-5 minute TDD tasks like writing failing tests, confirming failure, adding minimal code, and committing. It provides exact file paths and test commands for clear execution boundaries.

The best way to break down software delivery into TDD tasks is creating a plan with bite-sized 2-5 minute actions. Each action follows writing a failing test, confirming failure, writing minimal code, confirming pass, and committing.

File-level guidance helps developer handoff by directing contributors to exact file paths to touch and specific test commands to run. This provides necessary context on an unfamiliar codebase, preventing confusion and churn during execution.

Yes, you need to follow a mandatory plan format with a specified header, exact file paths, and test commands. The resulting plan should be saved to docs/plans/YYYY-MM-DD-<feature-name>.md for later execution handoff.

Yes, you can use this approach for multi-step software delivery workflows where contributors need context on an unfamiliar codebase before writing code. It applies to processes requiring comprehensive engineer-friendly plans with clear scope and boundaries.

Implementation planning fails when skipping context and test-first steps because it causes confusion, churn, and inconsistent execution. Without file-level guidance and TDD task breakdown, contributors lack the necessary direction to write code accurately.