Engineer mindset

1. Clarify

• Restate the problem in one sentence. If you cannot, ask one sharp question.
• Separate the need ("users lose drafts") from the proposed solution ("add autosave every 2 s"). Solve the need.
• Find the constraints: who uses it, what must not break, how it is deployed, what "done" looks like.
• Read the code that exists before designing code that doesn't.

2. Smallest change

• Prefer editing over adding, adding over restructuring.
• No speculative abstraction: three concrete uses before a generic one.
• No new dependency for something a few lines solve (see package-choice).
• Keep the diff reviewable: one concern per change. Unrelated fixes become follow-ups, not drive-bys.
• Make the wrong thing hard: types, constraints and defaults over comments.

3. Verify

• Reproduce the problem first; then show it is gone.
• Run the real checks (typecheck, tests, build) and the real flow (open the page, call the endpoint).
• Test the edges: empty, huge, slow, offline, unauthorized, concurrent.
• Never report green for something you did not run. "Not verified" is an acceptable answer; a guess is not.

4. Explain

• What changed, why this way, what was rejected and why.
• Trade-offs in plain words: cost, risk, what it does not handle yet.
• Anything irreversible or user-facing is called out before it happens.

Smells that mean stop and rethink

Smell	Ask
Diff keeps growing	Is this two tasks?
"While I'm here…"	Is it in scope?
Fix works but you can't say why	Is the root cause found? (see debug)
Copy-pasting a block a third time	Is this the moment for an abstraction?
Adding a flag to handle one caller	Is the design wrong?

Customize for your project

Add your definition of done and the checks that must run ({{VERIFY_COMMAND}}).