mcpbeat

Github Code Review

hezaohezao/github-code-review

Review PRs: diffs, inline comments via gh or REST.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
117
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/HezaoHezao/poirot --skill github-code-review

What it tells the agent to use

found in the instruction text
Read reads your files

The instruction itself

22 sections, as written by the author

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

  • Get the big picture first:
git diff main...HEAD --stat
git log main..HEAD --oneline
  • Review file by file — use read_file on changed files for full context:
git diff main...HEAD -- src/auth/login.py
  • 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 "<<<<<<\|>>>>>>\|======="
  • 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":

  • git diff main...HEAD --stat — see scope of changes
  • git diff main...HEAD — read the full diff
  • For each changed file, use read_file if you need more context
  • Apply the checklist above
  • Present findings in the structured format (Critical / Warnings / Suggestions / Looks Good)
  • 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)

How to use it

Copy the folder

Take hezaohezao/github-code-review from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.