diff options
| -rw-r--r-- | review-code/SKILL.md | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/review-code/SKILL.md b/review-code/SKILL.md index 95ac053..3e63b4a 100644 --- a/review-code/SKILL.md +++ b/review-code/SKILL.md @@ -370,6 +370,8 @@ The structured report above stays local. When the verdict is posted as a GitHub Name the good thing and stop: do not explain *why* it's good. The author made the change and already knows the rationale, so justifying the praise reads as sycophantic. "Clean migration off the window globals, tests cover the right edges" lands; appending "...because there are no stragglers and the provider, mocks, and Normal/Boundary/Error cases are all covered" turns a compliment into padding. Elaboration is for findings (something is wrong, here's the failure mode and the fix), never for compliments. +This holds for re-review approvals too. A re-review confirming requested changes is just "Approving." Mechanical rule: an approve summary is the verdict plus at most a bare positive ("Clean.", "Solid fix."). It must contain no clause that says what the change does or why it works. "The hoist to App fixes the crash, and the new test locks it in" is the banned pattern — it describes and justifies the change on an approve. If a clause references the code's behavior, cut it. + Good: - "Nice, clean, good coverage. One small naming nit inline. Approving." - "Clean shape, tests cover the right edges. Approving." |