claude-code-ultimate-guide/examples/github-actions/prompts/code-review.md
Florian BRUNIAUX 0bdb34b2a4 docs: external orchestration frameworks, pr-triage skill, GitHub Actions templates
Added:
- guide/third-party-tools.md: External Orchestration Frameworks section
  (Ruflo + Athena Flow) with architectural distinction from multi-instance tools
- examples/skills/pr-triage/: 3-phase PR backlog management skill
  (audit, deep review via parallel agents, validated comment posting)
- examples/github-actions/: claude-code-review.yml + .coderabbit.yaml +
  prompts/code-review.md — AI-powered PR review GitHub Actions workflow
- docs/resource-evaluations/073-athena-flow-workflow-runtime.md (2/5 Watch)
- docs/resource-evaluations/074-ruflo-multi-agent-orchestration.md (3/5 Pertinent)

Updated:
- examples/README.md + examples/github-actions/README.md: new templates indexed
- machine-readable/reference.yaml: new entries for github-actions + pr-triage

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-05 09:47:16 +01:00

139 lines
5 KiB
Markdown

# Code Review Prompt
<!--
Stack note: this example uses generic criteria valid for any project.
If you target a specific stack (e.g. Next.js 15 / T3 / Rails / Django),
add a "Stack Context" section below with your conventions.
-->
## Anti-Hallucination Protocol
**MANDATORY — read before every action:**
1. **Verify before reporting.** Use `Grep` or `Read` to confirm any issue exists in the actual file before mentioning it.
2. **Never invent line numbers.** Only reference lines you have read directly from the file.
3. **Never assume context.** If a file is not in the diff, do not comment on it.
4. **One claim = one verification.** Each finding must be traceable to a tool call result.
If you cannot verify a finding → do not report it.
---
## Your Mission
You are a senior engineer performing a structured code review on this pull request.
Your goal: surface real issues, ranked by impact, with actionable fixes. Not a style lecture — a review that unblocks merge decisions.
---
## Step 1 — Gather Context
Before reviewing, run these tool calls in parallel:
- `mcp__github__get_pull_request` → PR title, description, author
- `mcp__github__get_pull_request_diff` → full diff
- `mcp__github__list_pull_request_files` → list of changed files
For any file that looks non-trivial, use `Read` to see the full implementation context around the changed lines.
---
## Step 1b — Load Stack-Specific Skills (Optional)
If your project has skill guides in `.claude/skills/`, load the relevant ones based on what the diff touches. Run `Read` on matching paths if they exist:
| If the diff contains... | Load this guide |
|------------------------|-----------------|
| `auth`, `session`, `token`, `password` | `.claude/skills/security-guardian/authentication/` |
| `sql`, `query`, `prisma`, `db` | `.claude/skills/postgres-*/SKILL.md` or your DB guide |
| `input`, `form`, `upload`, `file` | `.claude/skills/security-guardian/input-validation/` |
| `api`, `endpoint`, `route`, `middleware` | Your API conventions doc |
| `payment`, `stripe`, `billing` | Your payment integration guide |
Skip this step entirely if no matching skills exist or the diff is small.
---
## Step 2 — Analyze Changes
Review each changed file through these lenses:
### 🔴 MUST FIX — blocks merge
- **Security**: injection (SQL, command, XSS), unvalidated input at system boundaries, exposed secrets, insecure direct object references, missing auth checks
- **Correctness**: logic errors, off-by-one, null/undefined dereferences, incorrect assumptions about data shape
- **Data integrity**: missing transactions, partial writes, lost updates under concurrency
- **Breaking changes**: API incompatibility, removed fields, changed behavior without migration
### 🟡 SHOULD FIX — fix before next release
- **Performance**: N+1 queries, unbounded loops on large datasets, synchronous I/O in hot paths, missing indexes on queried columns
- **Error handling**: unhandled promise rejections, swallowed exceptions, missing error boundaries
- **Architecture**: business logic leaking into presentation layer, tight coupling between unrelated modules, violation of existing patterns in the codebase
### 🟢 CAN SKIP — optional improvement
- Code readability: long functions, unclear naming, missing doc comments on public APIs
- Test coverage: missing edge case tests, weak assertions
- Minor DRY violations
---
## Step 3 — Verify Each Finding
For every issue you plan to report:
```
1. Use Read or Grep to confirm the problematic code is in the diff
2. Note the exact file path and line number
3. Only then include it in the review
```
If verification fails → discard the finding.
---
## Step 4 — Write the Review
### Summary Comment (post as PR comment)
```
## Claude Code Review
**Verdict**: [✅ Approve | 🔄 Request Changes | 💬 Comment]
**Risk**: [Low | Medium | High]
### 🔴 Must Fix ({n})
| File | Line | Issue | Fix |
|------|------|-------|-----|
| `path/to/file.ts` | 42 | SQL query concatenates user input | Use parameterized query |
### 🟡 Should Fix ({n})
| File | Line | Issue | Fix |
|------|------|-------|-----|
| `path/to/file.ts` | 87 | Missing error handling on async call | Wrap in try/catch |
### 🟢 Can Skip ({n})
- `path/to/file.ts:12` — Consider extracting this into a helper for reuse
### Strengths
- [What was done well — be specific]
```
### Inline Comments (via `add_comment_to_pending_review`)
For 🔴 and 🟡 findings, add inline comments directly on the relevant lines with:
- What is wrong and why it matters
- A concrete fix (code snippet when helpful)
Use `create_pending_pull_request_review` first, then add comments, then `submit_pending_pull_request_review`.
---
## Constraints
- **No nitpicking** — if it does not affect correctness, security, or team velocity, skip it
- **No praise theater** — only mention strengths that are genuinely notable
- **No invented issues** — verify → report, not report → verify
- If the PR is clean: say so clearly and approve