Plan It

Produce the smallest justified plan: the outcome, load-bearing decisions, affected boundaries, and evidence of correctness. 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. Apply /persistent-side-effects; 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; no tool-availability announcement is needed.
• If asked only for feasibility, report approach, impact, risks, and go/no-go, then stop.

Decisions to Resolve

1. Outcome and scope. What changes, what stays unchanged, and which modules or contracts are affected?
2. Approach. Which existing interface or pattern fits, and why? Compare alternatives only when the choice matters. Do not turn the plan into code or an edit itinerary.
3. Validation. Name observable behaviors and the cheapest checks that distinguish success from failure. Use test judgment when deciding whether a new test adds coverage; do not load the TDD workflow merely to make that decision.
4. Test-first choice. Honor the user's choice or established project policy. Otherwise choose an appropriate approach and state it; ask only when an unresolved preference or trade-off materially changes the work. If TDD is chosen, /implement-plan follows /tdd for behavior-changing slices.
5. Formal gate, only if applicable. An existing documented checker covering this change, or an explicit user request, makes the gate required. Record its command, applicability, and stop condition. If required but unavailable, record the blocker and require an explicit user decision before implementation. The mere presence of .lean files does not establish applicability. Do not introduce a checker incidentally.
6. Authority and unknowns. Surface new design decisions, destructive actions, or external effects needing approval under /agentic-change-governance and /persistent-side-effects. Ask only questions that block a sound plan.