1. Make the goal testable. “Working” is vague; define what success looks like.
  2. Constrain the change. Prefer small, reviewable edits over rewrites.
  3. Keep sources of truth explicit. Decide what is authoritative: code, docs, config, tests.
  4. Ask for trade-offs, not just answers. Alternatives reveal constraints and risks.
  5. Separate discovery from delivery. Explore broadly, then switch to surgical execution.
  6. Verify in the loop. Run the narrowest test that can falsify the current assumption.
  7. Treat generated code as a hypothesis. Read it like you didn’t write it.
  8. Preserve intent and naming. Don’t “improve” structure unless asked.
  9. Make decisions reversible. Prefer changes you can roll back quickly.
  10. Write down the why. Lightweight notes prevent re-deciding the same thing later.