| name | sdlc-review |
| description | Grade agent output before it ships, and log it. Use when agent-produced code is about to ship - a PR, a merge, a deploy, or "is this ready". Runs deterministic gates first, then grades the change against a short rubric (spec adherence, error handling, approach, reviewability), and logs the run so the self-improvement loop has data. This is the ONLY place an LLM judge is allowed, and only for code review. Make sure to use this whenever you say "review this", "before I ship/merge", "is this ready", or hands over a diff/PR. Fifth step of the SDLC loop. |
sdlc-review - gate, grade, and log
Fifth beat of the SDLC loop. Two jobs: make sure the change is safe to ship, and capture data about how the agent did so sdlc-learn can compound. Deterministic checks do the heavy lifting; a judge is used only for what they can't see.
Why this matters
AI-generated code needs equal or greater scrutiny than human code, with extra attention to hallucinated dependencies, weak error handling, and subtle correctness gaps that look right at a glance. And the review is where you generate the signal - first-pass success, recurring failure modes - that drives self-improvement. A review you don't log is a lesson you lose.
Procedure
- Deterministic gates first (free, fast). Tests pass, lint clean, no secrets, imports are real packages, the change matches the spec's scope. If any fail, stop - fix before grading.
- Grade against the rubric (1-5 each). Only the dimensions a test can't check:
- Spec adherence - did it build what the spec actually asked for?
- Error handling - are realistic failure modes covered, not just the happy path?
- Approach - sane structure and dependencies, or clever-but-fragile?
- Reviewability - could you or a teammate understand and maintain this?
- Run the Thermo-Nuclear pass for Approach + Reviewability. These two dimensions are graded against a strict maintainability standard in
references/thermo-nuclear-code-quality-review.md - read it and apply it. It is ambitious by design: don't stop at "could be cleaner," hunt for the "code judo" move that deletes whole categories of complexity. Its presumptive blockers (file crossing 1000 lines, ad-hoc branching tangling an existing flow, feature logic scattered across shared code, unnecessary wrappers/casts, canonical-helper duplication, a missed obvious decomposition) feed directly into the gate below. This is where Approach/Reviewability scores of <=2 come from.
- Optional single judge call. For the rubric (especially the Thermo-Nuclear Approach/Reviewability read) on judgment-heavy diffs, you may make ONE LLM-judge call: give it (the diff + the spec + the Thermo-Nuclear standard as the rubric) -> scores + reasons. Use a cheap model. This is the only sanctioned judge use; it never replaces the deterministic gates.
- Log the run. Append a row to the agent-run log (KPI tracker tab): date, task, model, first-pass success (Y/N), correction rounds, any failure mode, gate result. This is the observability that feeds the KPIs.
Output
A verdict (ship / fix first) with the rubric scores and the specific fixes, plus the logged run row.
Gate
Ship only on clean deterministic gates + acceptable rubric scores. Recurring low scores or failure modes flow to sdlc-learn.
References
Load these as needed: