Plan Crafting

Overview

Write comprehensive implementation plans assuming the engineer has zero context for the codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, and docs they might need to check. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits. Per-task commits are the working granularity for review gates; the final shape of the history (squash, amend, branch flow) follows the user's git preferences.

Assume they are a skilled developer, but know almost nothing about the toolset or problem domain. Assume they don't know good test design very well.

For behavior-changing work, state the behavior, acceptance criteria, relevant scope, and verification expectations in the plan. The tdd skill owns the test-first micro-cycle inside that task. Keep RED and GREEN steps explicit when a plan must be self-contained; otherwise hand off the micro-cycle instead of repeating it in every task.

Announce at start: "I'm using plan-crafting to create the implementation plan."

Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md

• An explicit user instruction overrides this default; a differing repository convention does not. If the repository has an established plan location, name both and the one you chose in the same message where you save the plan.

Scope Check