planning-base

name	planning-base
description	Apply shared planning baseline (format, verifiability, assumptions) before creating any concrete change plan

Provide a universal change plan skeleton: short, verifiable, no hidden assumptions Define quality rules: what a good plan looks like and what not to do

<when_to_use> Always before producing a change plan When the task is ambiguous and questions/assumptions must be captured </when_to_use>

<core_principles> Separate facts, assumptions, and decisions The plan must be verifiable: every step can be confirmed by a test/observation Changes are incremental, with stop points Do not replace requirements with solutions: first "what", then "how" Write only relevant sections: do not fill the template for the sake of it </core_principles>

<default_output_format>

Goal

Constraints

Proposed change

Risks

Verification

Rollout / rollback (if needed)

Open questions

<quality_rules> The goal is stated as behavior/outcome, not as a list of actions Acceptance criteria exist (what "done" means) Boundaries are stated: what we explicitly do NOT do in this task A verification plan exists (at least: one quick signal + one regression check) Open questions are explicitly listed and affect the plan </quality_rules>

<do_not> Do not produce a plan built on hidden assumptions Do not mix independent goals into one change-set without a reason Do not add "nice-to-have improvements" without a clear goal </do_not>

Goal: remove 500s on /orders. Proposed change: add a guard for null tax and a regression test. Verification: the repro is gone, the test is green. Risks: may affect tax calculation. Open questions: do we have legacy clients without tax? Has a goal, a concrete change, verification, risks, and questions Do something and check manually. No verifiability and no specifics