5.0 KiB
name, description
| name | description |
|---|---|
| repo-code-review | Review a repository in its current state for bugs, security issues, and guidance-doc (AGENTS.md/CLAUDE.md) compliance. Use when asked to review code, audit the repo/project, or check it before making changes. |
Repo Code Review
Provide a rigorous, structured code review of the repository in its current state. Follow these steps precisely:
1. Eligibility check
Skip (report "No review needed") if any apply: there is nothing meaningful to review (no source files / empty repo), or this exact scope was already reviewed in this session. Otherwise proceed.
2. Load guidance docs
Find and read the project's guidance docs — root AGENTS.md, CLAUDE.md, and any in directories the review covers. Use Glob/Grep to locate them (e.g. **/{AGENTS,CLAUDE}.md). Treat these as explicit review criteria; cite them when an issue maps to a rule.
3. Summarize the repo
Get a concise summary of what the repository is about and its structure, so reviewers share context before diving into code.
4. Parallel independent reviews
Launch parallel subagents via the task tool (they use whatever model this session was called with; the explore agent is read-only). Each subagent reviews one angle and returns a list of issues plus the reason each was flagged (e.g. guidance-doc adherence, bug, historical git context, security):
- Guidance-doc compliance: audit the code against AGENTS.md / CLAUDE.md. Guidance docs address the model as it writes code, so not all instructions apply during review.
- Bug scan: read only the relevant files; do a shallow scan for obvious bugs and security issues. Focus on large bugs; avoid small issues and nitpicks; ignore likely false positives.
- Historical context: read the git blame and history of the relevant code (
git blame,git log) to identify bugs in light of how it evolved. - Comments/intent: read code comments in the relevant files and ensure the code complies with the guidance in those comments.
5. Confidence scoring
For each issue found in step 4, launch a parallel subagent that takes the issue description and the guidance docs (from step 2) and scores its confidence on a scale from 0–100, using this rubric verbatim:
- 0 — Not confident at all. False positive that doesn't stand up to light scrutiny, or a pre-existing issue.
- 25 — Somewhat confident. Might be real but unverified; stylistic issues not explicitly called out in the guidance docs don't count here.
- 50 — Moderately confident. Verified as real but possibly a nitpick or rare in practice. Relative to the rest of the repo, it's not very important.
- 75 — Highly confident. Double-checked and very likely to matter in practice; directly impacts functionality, or is explicitly mentioned in the relevant guidance doc.
- 100 — Absolutely certain. Double-checked and confirmed real; happens frequently; evidence directly confirms it.
For issues flagged due to a guidance-doc rule, double-check that the guidance doc actually calls out that issue specifically.
6. Filter
Drop any issue scored <80. If none remain at >=80, report no blocking issues.
7. Re-check eligibility
Confirm the review is still warranted before writing up.
8. Report
Present findings concisely in chat. Cite each bug by file path and line range, with 1–2 lines of surrounding context; when an issue maps to a guidance-doc rule, quote the rule. Format:
### Code review
Found N issues:
1. <brief description of issue> (guidance doc path says "<...>")
path/to/file.ext:12-18
2. <brief description of issue> (bug due to <file and code snippet>)
path/to/file.ext:40-45
Or, if nothing met the threshold:
### Code review
No blocking issues found. Checked for bugs and AGENTS.md/CLAUDE.md compliance.
Examples of false positives (for steps 4 and 5):
- Pre-existing issues
- Something that looks like a bug but is not actually a bug
- Pedantic nitpicks that a senior engineer wouldn't call out
- Issues that a linter, typechecker, or compiler would catch (e.g. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself — it is safe to assume they will be run separately as part of CI.
- General code quality issues (e.g. lack of test coverage, general security issues, poor documentation), unless explicitly required in a guidance doc
- Issues that are called out in a guidance doc, but explicitly silenced in the code (e.g. due to a lint ignore comment)
- Changes in functionality that are likely intentional or are directly related to the broader change
- Real issues, but on lines that are outside the review scope
Notes:
- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
- Do not fetch anything from the web (no web search or fetch). Use git commands via Bash for history and context instead.
- You must cite each bug by file path and line range.
- Keep output brief.