elliottlawson Review
Review the change against the passes, then weigh them into a verdict.
If a referenced skill isn't available locally, fetch it from the open-review repo at runtime — the whole directory, subdirectories included. Use npx skills use elliottlawson/open-review@<name> if npx is available; otherwise fetch the directory from GitHub.
Scope
The change is the diff against the merge-base with the base branch (git diff origin/main...HEAD, or the base/range the caller gives). Confirm the ref resolves; if the diff is empty, say so and stop. Skip generated and vendored files.
Step 0 — Find the project's reference material
Find the project's standards and stack with /infer-conventions; use what it loads throughout the passes. If the project has no documented standards, say so in the verdict instead of inventing any.
Passes
Run in order: mission → architecture → implementation → craft → security → performance. Then weigh them into a verdict:
- Approve — mission met, no blocking findings.
- Changes needed — real issues found; name them.
- Hold — mission unclear, or an architectural concern needs discussion first.
Depth calibration. Match depth to scope — a 2-file bugfix is brief; a 30-file feature gets deep coverage.
Verify before you flag. A finding must point at a concrete line and a concrete consequence. If you can't verify it, ask a question instead.
Reporting
Report your findings in prose — severity (critical / warning / info), the pass that found it, the file and line, and why it matters.
- Judge the change, not the codebase. Blocking findings only on new or meaningfully changed code; a pre-existing violation is advisory at most.
- Cite the standard, state the target pattern. When the project has documented standards, name the doc a finding violates and the pattern to follow instead.
- Report repeated issues once. The same issue across multiple files is one finding — note that it applies broadly.
Under CI, /review-as-json wraps this review and shapes the output as JSON.