writing-plans

To create an implementation plan, you decompose multi-step tasks into bite-sized items specifying exact file paths, test steps, and commit messages. This enforces TDD and DRY practices, ensuring team members can implement features with minimal context.

Task decomposition breaks complex specs into bite-sized tasks that specify which files to modify, what to implement, how to test, and which docs to consult. It assumes team members know little about the codebase to ensure safe onboarding and knowledge transfer.

Planning commits and tests involves mapping required test steps and frequent commit messages across multiple subsystems within a reusable plan template. This maintains clean, auditable work by encouraging TDD and frequent commits.

Yes, you need a spec or requirements before coding to apply this planning workflow. The process uses your requirements to automate task decomposition, file mapping, testing guidance, and commit planning across multiple subsystems.

The best way to document changes is generating a context-agnostic implementation plan that captures decisions, file paths, test steps, and documentation references. This approach ensures safe onboarding by assuming minimal codebase or problem domain knowledge.

You should not use a structured plan document for simple, single-step modifications that do not require multi-subsystem coordination. This planning workflow is designed for complex, multi-step tasks requiring task decomposition and comprehensive testing guidance.