# 4 · Your own work: review it first, then answer well When the change is yours, you are its first reviewer. Every problem you find yourself is one the person doesn't have to find, explain and wait on. And when they do comment, how you answer decides whether the review takes one round or five. Code craft `4-verify.md` covers checking that your change works. This file is about handing it to a reviewer and answering them. On a small change: A1 and a three-line description (A2). Answer comments with A3 and A4 when they come. --- ### A1 · Review your own diff before anyone else does **Rule:** Before asking for review, read the whole change the way the reviewer will see it: the full diff against the branch it will merge into (`git diff main...HEAD`), including new files, on the review page if there is one. Use `2-read.md` on it: the D2 questions, D4 for what's missing, and D7 to D9 if you wrote it with an agent's help (you did). Run Code craft's `checks/tidy.js --diff main` and this module's `checks/diffmap.js`. Fix what you find before you ask. **Why:** A reviewer who finds a leftover `console.log` or a test left on `.only` in the first minute stops trusting the rest, and reads every line looking for more. Their time goes on what you could have caught, not on what only they can. **Agent trap:** reviewing only the last edit you made, not the whole branch, so the debug change from three commits ago is still in it. Or reading your diff in your editor, where you see what you meant, instead of as a diff, where you see what you did. **Check:** you read the full branch diff from top to bottom after your last change, `checks/tidy.js --diff main` reports nothing to fix, and you can say which D2 questions applied and what you found. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - A2 · Write the description the reviewer needs > - A3 · Answer every comment > - A4 · Check a suggestion before you apply it; disagree when it's wrong > - A5 · Keep review fixes inside the review