claude
fbec36cb67
Scaffold the course repo and author the full curriculum in dependency-chain order, following the settled build decisions in handoff.md. - Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5), _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config. - Modules 1-2: reference exemplars (locked for tone/depth/lab style). - Modules 3-27: full lessons + runnable labs, each following the template, respecting the chain, vendor/model-agnostic, with "feel the pain" labs. - Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22), not written from memory; expansion-zone modules carry Verify-before-publish. - Capstone: the full loop end to end on the running tasks-app example. Lab code syntax-checked (Python/shell/YAML); every module has the 7 core template sections. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
1.8 KiB
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
- 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.
- Missing tests. New behavior with no test in the suite (Module 13). Name the specific case.
- Security smells (Module 15). Hardcoded secrets, shelling out on unsanitized input, a new dependency that doesn't obviously exist.
- Correctness on edge cases. Empty input, bad index, missing file.
- 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, ornit. - 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": "..."}
]
}