Review a PR with full codebase context. Use proactively: after creating a nontrivial PR, spawn a subagent with this skill for a fresh-eyes review before presenting to the user.
From mxnpx claudepluginhub maxwolf-01/agents --plugin mxThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Review a pull request with full codebase understanding. Arguments: $ARGUMENTS
gh pr view <number> for title, description, author contextgh pr diff <number> for the full diffgh pr view <number> --comments if there's prior discussionRead every file touched by the PR — in full, not just the changed lines. Then follow references outward until you can answer:
Specifically:
agent/knowledge/) if the PR touches a documented domainDo not form opinions during this phase. You are building understanding, not evaluating.
Two passes: correctness, then quality. Both matter.
For each potential finding, ask yourself before writing it down:
Things that are almost never issues:
Read the new/changed code line by line. Apply these lenses:
as any, ! non-null assertions on nullable values, arrays typed T[] that contain nulls)? Dishonest types hide bugs.found flags where a function extraction or direct return would be cleaner?Watch for LLM anti-patterns — patterns that AI-generated code tends to introduce. Flag these in the reviewed code, and do NOT suggest them in your review:
# set x to 5 / x = 5), narrate the obvious, or add meta-commentaryZen of Python applies broadly (not just Python):
## <PR title>
**What it does**: 1-2 sentences, end-to-end.
### Architecture
Is the approach sound? Skip if straightforward.
### Bugs
Incorrect behavior. Each with: scenario that breaks, where (file:line), fix.
### Code Quality
Type honesty, structure, naming, unnecessary complexity, dead weight.
Each with: what's wrong, where (file:line), concrete fix.
"I'd write it differently" is not an issue — name the actual cost.
### Considerations
Non-blocking observations: trade-offs worth noting, things to watch for,
potential follow-ups. Not issues, just context.
Omit empty sections.
A clean PR gets a short review. Don't invent concerns to fill space.