brainstorminglisted

**Hard rule: write no code until the design is approved.** Once this skill triggers, follow it through—the design may be only a few sentences, but it must be explained and approved first. Deciding midway that it is "actually simple" is not a reason to exit: "simple" often means unstated assumptions. ## Excuses that surface when you want to skip design | What you tell yourself | Reality | |---|---| | "This is too simple to need design." | "Simple" means unstated assumptions, which are the most dangerous. A simple design may take only a few sentences, but it still needs to be explained and approved. | | "It will be faster to think while building." | Starting from a misaligned understanding makes rework slower. Align on the direction before acting. | | "The user probably wants X." | Do not decide for the user. Clarify one question at a time, and offer choices when possible. | ## Process 1. **Inspect the context first**: relevant files, documentation, and recent commits. Do not design in a vacuum. 2. **Ask one question at a time** to clarify the goal, constraints, and success criteria. Offer choices when possible; they are easier to answer than open-ended questions. Put only one question in each message. 3. **Split up work that is too large**: if it is really several independent subsystems, stop and help divide it into subprojects and prioritize them before detailing a large task that should be broken apart. 4. **Present 2–3 approaches with tradeoffs**: put your **recommended**