code-review
starsforks
How to install code-review?
borda/ai-rig/code-review
$npx -y skills add Borda/AI-Rig --skill code-reviewTiered Codex-native multi-axis code review for local diffs or GitHub PRs, including $code-review #123 (bare number = PR); uses mechanical scope gates, explicit specialist fan-out/substitutes, measurable gates, and a JSON artifact.
SKILL.md
| 1 | # Code Review |
| 2 | |
| 3 | Run tiered review with strict output gates. |
| 4 | |
| 5 | ## Input Schema |
| 6 | |
| 7 | ```json |
| 8 | { |
| 9 | "scope": "optional working-tree|path|commit|pr; infer pr for bare number, #number, or PR URL", |
| 10 | "target": "optional path, commit ref, PR number, PR URL, or current branch PR", |
| 11 | "done_when": "blocking issues are identified with gate decision" |
| 12 | } |
| 13 | ``` |
| 14 | |
| 15 | ## Scope And Routing |
| 16 | |
| 17 | - `working-tree`: review unstaged/staged local changes. |
| 18 | - `path`: review one file/directory diff. |
| 19 | - `commit`: review a git diff revision spec, such as `COMMIT^!`, `BASE..HEAD`, or `BASE...HEAD`. |
| 20 | - `pr`: review an open pull request: collect GitHub PR metadata/review evidence, fetch target branch, update local checkout with `gh pr checkout`, inspect local files; `target` may be PR number, URL, or current-branch PR. |
| 21 | |
| 22 | Input shorthand: |
| 23 | |
| 24 | - Canonical in-session: `$code-review 123` or `$code-review #123` => `scope=pr`, `target=123`. |
| 25 | - Natural-language aliases: `code-review 123`, `code-review #123`, and `code-review PR 123` => `scope=pr`, `target=123`. |
| 26 | - `code-review <github-pr-url>` => `scope=pr`, `target=<github-pr-url>`. |
| 27 | - Bare number = GitHub PR number; do not ask for `scope=pr`. |
| 28 | |
| 29 | Never write to remote. PR scope may update local checkout to PR head; otherwise read-only except `.reports/codex/code-review/<timestamp>/` artifacts. Never pass `--force` to `git` or `gh`; if forced checkout seems needed to align local branch and PR head, stop, explain overwrite risk, and ask before retrying. To fix findings, switch to `code-remediate` after creating review artifact. |
| 30 | |
| 31 | ## Workflow (Exact Commands) |
| 32 | |
| 33 | ### 01: Create run directory |
| 34 | |
| 35 | Run `python PLUGIN_ROOT/shared/create_run.py --skill code-review` once. Retain its single printed path as |
| 36 | `<run-directory>` and substitute that literal path into every later artifact path and helper argument. Never store or |
| 37 | reuse the path through a shell variable; shell variables do not persist across tool calls. |
| 38 | |
| 39 | ### 02: T0 mechanical scope gate: resolve scope, collect diff, and classify review risk before any model-level judgment |
| 40 | |
| 41 | For local scopes, inspect `python PLUGIN_ROOT/shared/collect_diff.py --help`; collect normalized `scope`, optional |
| 42 | `target`, and the literal `<run-directory>` path. |
| 43 | |
| 44 | For PR scope, inspect `python PLUGIN_ROOT/shared/collect_pr.py --help`; collect the exact target into the literal |
| 45 | `<run-directory>` path with checkout enabled. |
| 46 | |
| 47 | PR GitHub data is evidence only: `gh pr view`, `gh pr diff`, and review-thread queries provide metadata, patch, comments. Inspect source only in local checkout recorded by `<run-directory>/local-checkout.json` after target-branch refresh evidence. Checkout must use authoritative PR URL, never a bare number that may resolve to wrong local fork. Never reconstruct changed source from `curl`, `raw.githubusercontent.com`, or `head-files/` snapshots. If checkout fails or `local-checkout.json` does not prove `head_matches_pr=true`, fail instead of reviewing remote raw files. Do not retry with `--force` unless user explicitly confirms after receiving force reason and overwrite risk. |
| 48 | |
| 49 | Classify diff; write `<run-directory>/scope.txt`: |
| 50 | |
| 51 | - `TRIVIAL`: no public API/config/security/ML behavior touched, \<3 files, \<50 changed lines. |
| 52 | - `LOCAL`: one subsystem or 3-7 files; local context explains behavior. |
| 53 | - `BROAD`: 8+ files, cross-subsystem change, dependency/config change, or unclear ownership. |
| 54 | - `HIGH_RISK`: public API, release, security, auth, credentials, deserialization, data pipeline, ML tensor math, CI/CD, or migration behavior. |
| 55 | |
| 56 | For `scope=pr`, review evidence includes `pr.json`, `pr-routing.json`, `remote-selection.json`, `target-branch.json`, `local-checkout.json`, comments, reviews, review threads, unresolved review threads, and `online-review-summary.json`. Selected remote must match base repository from PR URL; fetched base/head OIDs must exactly match PR metadata. `pr-routing.json` and `local-checkout.json` must include `force_policy` proving no automatic forced checkout. Treat unresolved online threads/comments as candidate findings until triaged valid, duplicate, stale, out-of-scope, or already fixed. |
| 57 | |
| 58 | If `files.txt` and `untracked.txt` are empty with no explicit target, fail before gates. If `scope=pr` and `pr-error.txt` exists, fail with captured reason. |
| 59 | |
| 60 | ### 03: T1 primary diff review. Read the changed files end-to-end from the local working tree or checked-out PR branch and identify findings before considering any fix or gate outcome |
| 61 | |
| 62 | Review axes, in order: |
| 63 | |
| 64 | - API and behavior regressions. |
| 65 | - Test coverage and edge-case gaps. |
| 66 | - Error handling and logging. |
| 67 | - Project coding principles: changed code follows the applicable `AGENTS.md` layers for simplicity, readability, reproducibility, short reusable units without low-value |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
