Plan It

Plan from the reason outward: Why the change matters to its users, How it fits the current system, and What will be delivered in verifiable slices. Leave exact code, filenames, edit ordering, and naming to implementation unless they are part of the contract.

Boundaries

• Inspect only the instructions, code, tests, and configuration needed to resolve the planning decisions. Reuse current context rather than rereading it ceremonially.
• Planning alone does not authorize product edits or persistent artifacts. Keep the plan in the conversation unless another location is approved.
• Use the harness's planning support when it helps or is required. A short conversational plan is sufficient for a small, clear, low-risk change.
• If asked only for feasibility, report approach, impact, risks, and go/no-go, then stop.

1. Establish the Why

Before anything else, state who the change is for, what problem it solves for them, and what success looks like from their side. The Why is the source of the acceptance criteria and the test for scope.

The request must supply three things: the desired capability, the acceptance standard, and the user value. Ask only for what is missing; do not re-ask what the user already stated. When the user gives only a How ("add a column", "switch to X"), ask what it is for.

2. Decide the How