github-code-review

name	github-code-review
description	Review PRs: diffs, inline comments via gh or REST.
allowed-tools	["bash","read_file"]
enabled	true
related-skills	["requesting-code-review"]
license	MIT
author	Adapted from hermes-agent (Nous Research, MIT)

GitHub Code Review

Perform code reviews on local changes before pushing, or review open PRs on GitHub. Most of this skill uses plain git — the gh/curl split only matters for PR-level interactions.

Prerequisites

• Authenticated with GitHub (GITHUB_TOKEN env var or gh auth login)
• Inside a git repository

Setup (for PR interactions)

if command -v gh &>/dev/null && gh auth status &>/dev/null; then
  AUTH="gh"
else
  AUTH="git"
fi

REMOTE_URL=$(git remote get-url origin)
OWNER_REPO=$(echo "$REMOTE_URL" | sed -E 's|.*github\.com[:/]||; s|\.git$||')
OWNER=$(echo "$OWNER_REPO" | cut -d/ -f1)
REPO=$(echo "$OWNER_REPO" | cut -d/ -f2)

---

1. Reviewing Local Changes (Pre-Push)

This is pure git — works everywhere, no API needed.

Get the Diff

# Staged changes (what would be committed)
git diff --staged

# All changes vs main (what a PR would contain)
git diff main...HEAD

# File names only
git diff main...HEAD --name-only

# Stat summary (insertions/deletions per file)
git diff main...HEAD --stat

Review Strategy

1. Get the big picture first:

git diff main...HEAD --stat
git log main..HEAD --oneline

2. Review file by file — use read_file on changed files for full context:

git diff main...HEAD -- src/auth/login.py

3. Check for common issues:

# Debug statements, TODOs, console.logs left behind
git diff main...HEAD | grep -n "print(\|console\.log\|TODO\|FIXME\|HACK\|XXX\|debugger"

# Large files accidentally staged
git diff main...HEAD --stat | sort -t'|' -k2 -rn | head -10

# Secrets or credential patterns
git diff main...HEAD | grep -in "password\|secret\|api_key\|token.*=\|private_key"

# Merge conflict markers
git diff main...HEAD | grep -n "<<<<<<\|>>>>>>\|======="

4. Present structured feedback to the user.

Review Output Format

## Code Review Summary

### Critical
- **src/auth.py:45** — SQL injection: user input passed directly to query.
  Suggestion: Use parameterized queries.

### Warnings
- **src/models/user.py:23** — Password stored in plaintext. Use bcrypt or argon2.
- **src/api/routes.py:112** — No rate limiting on login endpoint.

### Suggestions
- **src/utils/helpers.py:8** — Duplicates logic in `src/core/utils.py:34`. Consolidate.
- **tests/test_auth.py** — Missing edge case: expired token test.

### Looks Good
- Clean separation of concerns in the middleware layer
- Good test coverage for the happy path

---

2. Reviewing a Pull Request on GitHub

View PR Details

With gh:

gh pr view 123
gh pr diff 123
gh pr diff 123 --name-only

With git + curl:

PR_NUMBER=123

# Get PR details
curl -s \
  -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER \
  | python3 -c "
import sys, json
pr = json.load(sys.stdin)
print(f\"Title: {pr['title']}\")
print(f\"Author: {pr['user']['login']}\")
print(f\"Branch: {pr['head']['ref']} -> {pr['base']['ref']}\")
print(f\"State: {pr['state']}\")"

# List changed files
curl -s \
  -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER/files \
  | python3 -c "
import sys, json
for f in json.load(sys.stdin):
    print(f\"{f['status']:10} +{f['additions']:-4} -{f['deletions']:-4}  {f['filename']}\")"

Check Out PR Locally for Full Review

This works with plain git — no gh needed:

# Fetch the PR branch and check it out
git fetch origin pull/123/head:pr-123
git checkout pr-123

# Now you can use read_file, bash grep, run tests, etc.
git diff main...pr-123

Leave Comments on a PR

General PR comment — with gh:

gh pr comment 123 --body "Overall looks good, a few suggestions below."

General PR comment — with curl:

curl -s -X POST \
  -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/$OWNER/$REPO/issues/$PR_NUMBER/comments \
  -d '{"body": "Overall looks good, a few suggestions below."}'

Leave Inline Review Comments

Single inline comment — with gh (via API):

HEAD_SHA=$(gh pr view 123 --json headRefOid --jq '.headRefOid')

gh api repos/$OWNER/$REPO/pulls/123/comments \
  --method POST \
  -f body="This could be simplified with a list comprehension." \
  -f path="src/auth/login.py" \
  -f commit_id="$HEAD_SHA" \
  -f line=45 \
  -f side="RIGHT"

Submit a Formal Review (Approve / Request Changes)

With gh:

gh pr review 123 --approve --body "LGTM!"
gh pr review 123 --request-changes --body "See inline comments."
gh pr review 123 --comment --body "Some suggestions, nothing blocking."

With curl — multi-comment review submitted atomically:

HEAD_SHA=$(curl -s \
  -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['head']['sha'])")

curl -s -X POST \
  -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews \
  -d "{
    \"commit_id\": \"$HEAD_SHA\",
    \"event\": \"COMMENT\",
    \"body\": \"Code review\",
    \"comments\": [
      {\"path\": \"src/auth.py\", \"line\": 45, \"body\": \"Use parameterized queries to prevent SQL injection.\"},
      {\"path\": \"src/models/user.py\", \"line\": 23, \"body\": \"Hash passwords with bcrypt before storing.\"}
    ]
  }"

Event values: "APPROVE", "REQUEST_CHANGES", "COMMENT"

The line field refers to the line number in the new version of the file. For deleted lines, use "side": "LEFT".

---

3. Review Checklist

When performing a code review (local or PR), systematically check:

Correctness

• Does the code do what it claims?
• Edge cases handled (empty inputs, nulls, large data, concurrent access)?
• Error paths handled gracefully?

Security

• No hardcoded secrets, credentials, or API keys
• Input validation on user-facing inputs
• No SQL injection, XSS, or path traversal
• Auth/authz checks where needed

Code Quality

• Clear naming (variables, functions, classes)
• No unnecessary complexity or premature abstraction
• DRY — no duplicated logic that should be extracted
• Functions are focused (single responsibility)

Testing

• New code paths tested?
• Happy path and error cases covered?
• Tests readable and maintainable?

Performance

• No N+1 queries or unnecessary loops
• Appropriate caching where beneficial
• No blocking operations in async code paths

Documentation

• Public APIs documented
• Non-obvious logic has comments explaining "why"
• README updated if behavior changed

---

4. Pre-Push Review Workflow

When the user asks you to "review the code" or "check before pushing":

1. git diff main...HEAD --stat — see scope of changes
2. git diff main...HEAD — read the full diff
3. For each changed file, use read_file if you need more context
4. Apply the checklist above
5. Present findings in the structured format (Critical / Warnings / Suggestions / Looks Good)
6. If critical issues found, offer to fix them before the user pushes

Decision: Approve vs Request Changes vs Comment

• Approve — no critical or warning-level issues, only minor suggestions or all clear
• Request Changes — any critical or warning-level issue that should be fixed before merge
• Comment — observations and suggestions, but nothing blocking (use when unsure or PR is draft)