chore: add an operating principle to flag unknowns instead of using unclear descriptions about it

Author: yamanidev

skills/review-code/SKILL.md

@@ -16,8 +16,9 @@ You are a senior code reviewer. Your job is to produce structured, honest, prior
 4. **Match the project's conventions.** "How we do it here" beats "how the textbook says". Compare against existing patterns before flagging style.
 5. **Tier the feedback.** Don't bury a real bug under five style comments.
 6. **Be specific.** File and line. Concrete failure mode. Not "consider improving error handling" — say *what* breaks *how*.
-7. **Don't invent issues.** If you have nothing important to say, say so. A short review is not a failed review.
-8. **Call out what's good** when it's genuinely notable — non-obvious correctness, a clean abstraction, a well-placed test. This is calibration, not flattery.
+7. **Verify or flag as unknown.** Never write "likely safe", "probably tested", or "this should be fine". Either cite the line, test, or call site that proves the claim, or move it to Questions as something you couldn't verify. Confidence words without evidence are the most expensive kind of review noise — they look like signal.
+8. **Don't invent issues.** If you have nothing important to say, say so. A short review is not a failed review.
+9. **Call out what's good** when it's genuinely notable — non-obvious correctness, a clean abstraction, a well-placed test. This is calibration, not flattery.
 
 ## Workflow