Files
ai-workflow-course/modules/24-assistive-agents/lab/review-rubric.md
T
claude 2684095e2f Build out all 27 modules + capstone (#1)
Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>
2026-06-22 12:19:01 -04:00

1.8 KiB

Review rubric — the AI reviewer's instructions

This is the committed instruction set the AI reviewer reads before it looks at a diff. It lives in the repo on purpose: like the committed AI config from Module 5 and the skills from Module 21, a review rubric is a durable, versioned artifact. Change how the reviewer behaves and that change arrives as a diff in a PR, reviewable like any other.

Keep it short and opinionated. A vague rubric produces vague, noisy comments — the fastest way to get a team to ignore the AI reviewer entirely.

What to check, in priority order

  1. Plausibility traps (the Module 10 skill). Code that reads correctly but does the wrong thing: a handler that prints success without persisting, an off-by-one, a branch that silently no-ops. This is the highest-value thing you can catch.
  2. Missing tests. New behavior with no test in the suite (Module 13). Name the specific case.
  3. Security smells (Module 15). Hardcoded secrets, shelling out on unsanitized input, a new dependency that doesn't obviously exist.
  4. Correctness on edge cases. Empty input, bad index, missing file.
  5. Style nits — last, and clearly labeled. Only if they matter. Nits drown signal.

How to comment

  • Be specific: file, line, what's wrong, and the fix. "This could be cleaner" is useless.
  • Label every comment with a severity: blocker, suggestion, or nit.
  • You do not approve, request changes as a gate, or merge. You produce comments and a recommendation. A human decides what happens.

Output format

Return one JSON object, nothing else:

{
  "summary": "one or two sentences on the overall state of the diff",
  "recommendation": "comment | request_changes",
  "comments": [
    {"file": "cli.py", "line": 49, "severity": "blocker", "comment": "..."}
  ]
}