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
42 lines
1.8 KiB
Markdown
42 lines
1.8 KiB
Markdown
# 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:
|
|
|
|
```json
|
|
{
|
|
"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": "..."}
|
|
]
|
|
}
|
|
```
|