Review along two independent axes:
Standards: defects, maintainability risks, hidden coupling, misleading structure, and documented convention violations.Spec: missing, partial, incorrect, ambiguous, or unrequested behavior relative to the agreed requirements.
Workflow
- Use the fixed point named by the user. Otherwise infer the base branch or use the current staged and unstaged diff; ask only when the review
surface cannot be determined safely.
- Resolve the comparison and confirm it has a non-empty diff. Use
git diff <fixed-point>...HEAD for branch-style comparisons.
- Resolve the spec from the user's request or linked issue, PRD, plan, PR, or project documentation. If none exists, skip that axis and report
No spec available.
- Read applicable repository instructions and conventions, then review Standards and Spec independently. Documented project standards override
general judgment; do not report issues already enforced by tooling unless the change bypasses that tooling.
- Ground every finding in a concrete file or hunk. Keep the axes separate and report counts and the worst finding for each.
Finding format
Severity: CRITICAL is exploitable, destructive, or release-blocking; HIGH is serious; MEDIUM is contained; LOW is minor. Every finding must
name the problem, location, concrete impact, and actionable fix:
- **<CRITICAL | HIGH | MEDIUM | LOW>: <problem>** (`<file>:<line>`)
- **Impact:** <impact>
- **Fix:** <fix>
Output
## Standards
<findings in the required format, or "No findings">
## Spec
<findings in the required format, "No findings", or "No spec available">
Summary: Standards <count>; Spec <count>. Worst Standards issue: <item or none>. Worst Spec issue: <item or none>.
1---2name: code-review3description: Code review of a diff, branch, PR, commit range, or working tree against standards and agreed requirements.4---56Review along two independent axes:78- `Standards`: defects, maintainability risks, hidden coupling, misleading structure, and documented convention violations.9- `Spec`: missing, partial, incorrect, ambiguous, or unrequested behavior relative to the agreed requirements.1011## Workflow12131. Use the fixed point named by the user. Otherwise infer the base branch or use the current staged and unstaged diff; ask only when the review14 surface cannot be determined safely.152. Resolve the comparison and confirm it has a non-empty diff. Use `git diff <fixed-point>...HEAD` for branch-style comparisons.163. Resolve the spec from the user's request or linked issue, PRD, plan, PR, or project documentation. If none exists, skip that axis and report17 `No spec available`.184. Read applicable repository instructions and conventions, then review Standards and Spec independently. Documented project standards override19 general judgment; do not report issues already enforced by tooling unless the change bypasses that tooling.205. Ground every finding in a concrete file or hunk. Keep the axes separate and report counts and the worst finding for each.2122## Finding format2324Severity: `CRITICAL` is exploitable, destructive, or release-blocking; `HIGH` is serious; `MEDIUM` is contained; `LOW` is minor. Every finding must25name the problem, location, concrete impact, and actionable fix:2627```md28- **<CRITICAL | HIGH | MEDIUM | LOW>: <problem>** (`<file>:<line>`)29 - **Impact:** <impact>30 - **Fix:** <fix>31```3233## Output3435```md36## Standards3738<findings in the required format, or "No findings">3940## Spec4142<findings in the required format, "No findings", or "No spec available">4344Summary: Standards <count>; Spec <count>. Worst Standards issue: <item or none>. Worst Spec issue: <item or none>.45```
MuhammedAlkhudiry