code-review

Files (8)

• SKILL.md
• code-reviewer.md
• dependency-bumps.md · modes/
• giving.md · modes/
• post-merge-audit.md · modes/
• pr-audit.md · modes/
• pr-inline.md · modes/
• receiving.md · modes/

SKILL.md (first lines)

# Code Review

Six modes; full detail in `modes/<mode>.md`. Read it when you enter the
mode. `code-reviewer.md` is the reviewer subagent brief.

| Mode | When | Detail |
|---|---|---|
| **Giving** | Completing a task, reviewing a branch/PR, before merge, "review since X" | `modes/giving.md` |
| **PR-inline** | Publishing a GitHub review with inline ` ```suggestion ` comments | `modes/pr-inline.md` |
| **Receiving** | Deciding how to act on review feedback you received | `modes/receiving.md` |
| **PR-audit** | Auditing an untrusted contributor PR before merge: claim verification, prompt-injection resistance, hostile-change and supply-chain review | `modes/pr-audit.md` |
| **Post-merge audit** | Auditing the combined default-branch tree after merges, before deploy/release | `modes/post-merge-audit.md` |
| **Dependency bumps** | Fast-path merge of bot-authored dependency-only PRs | `modes/dependency-bumps.md` |

## Giving — essentials

- Review the diff against the spec, not your memory of it.
- Two-axis review where the repo defines it (Standards vs Spec).
- Every finding cites file:line and the rule it violates.
- Verify claims with tools before reporting — no "looks fine" without evidence.
- Independent reviewer subagent (`reviewer`/`qa-ci`) for unbiased assessment
  on high-risk diffs.

## PR-inline — essentials

- Cycle: CHECK → COMMENT/SUGGEST → NEXT. One concern per cycle; never post
  before confirming the target line in the PR head.
- `gh api` with `--field` for per-line positioning (not `gh pr review`).
- ` ```suggestion ` blocks must be applicable in one click.
- Don't edit the PR's code locally; comments only.
- Comment language follows the repository.
- Every comment gets a gate in the ledger (see `gates`).

## Receiving — essentials

Verify before implementing; ask before assuming; technical correctness over
social comfort.

1. READ the feedback completely without reacting.
2. UNDERSTAND — restate the requirement or ask.
3. VERIFY against codebase reality.
4. EVALUATE — technically sound for THIS codebase?
5. RESPOND — technical acknowledgment or reasoned pushback.
6. IMPLEMENT — one item at a time, test each.

Classify each item: **pushed** (reviewer cites a concrete violation → verify
against the cited source, fix, test) vs **pulled** (reviewer points to a
skill/convention/gate you should have used → pull that source first, apply,
verify). Repeated missing pulled patterns → add to your pre-review checklist.

## Cross-skills

- `security` — escalate to the security skill when the diff touches auth, secrets, input handling, or public endpoints.
- `a11y-audit` — escalate when the diff touches frontend markup/ARIA/keyboard paths.

From Leostruka/devin-bundle, MIT.

More from Leostruka/devin-bundle