AI coding tools made me 3x faster at writing code. But I'm not shipping 3x faster. I spend more time than ever waiting for reviews and handling review feedback. The bottleneck moved.
This is the second article in a series about how I use Claude Code. The first covered persistent execution plans and external memory.
Code Review tools handle the automated side well. Claude Code's built-in review dispatches multiple agents to catch bugs and flag style issues when a PR opens. That's useful, but it's not where the time goes. The time goes to the human review cycle: giving thoughtful feedback on a colleague's design decisions, responding to comments on your own PR, the back-and-forth that turns a draft into something mergeable. Some of that is pure wait time: a PR sits idle while reviewers are busy. The skills in this article speed up the other part, what happens when you actually sit down to review or respond.
The answer isn't to review faster. It's to change what you're reviewing. Instead of reading diffs line by line, I review Claude's assessment of the changes in context of the full codebase. I focus on whether the analysis is right, whether it missed something, and whether the design makes sense. Two custom Claude Code skills handle the mechanics, one for each side of the review cycle.
Reviewing others' PRs
I run /gh-review-pr owner/repo#123. Claude checks out the PR branch, reads the diff with full codebase access (it can follow imports, check how changed functions are used, and understand how the PR fits into the larger architecture), and presents findings grouped by severity:
Must fix
- src/api/handlers.go:47: Missing auth check on the new endpoint.
All existing endpoints use requireAuth middleware.
Should fix
- src/api/handlers.go:62: Similar pagination logic exists in listUsers.
Consider extracting a shared helper.
Nit
- Test name on line 15 could be more descriptive.
Praise
- Clean error handling throughout. The custom error types are well done.
The most useful thing the skill does is search the repo and the broader GitHub org for prior art before forming its review. If someone adds a caching layer, it checks whether there's already an established pattern elsewhere in the org. This catches the "we already have a way to do this" issues that are invisible from a diff alone, and it's the biggest gap in existing review tools, including the built-in ones.
That cross-repo context is what makes reviewing at a higher level possible. I'm not scanning the diff for problems. I'm reading a structured assessment and deciding whether the analysis is right, whether it missed anything, and which findings are worth posting.
A few other details that compound over time. If I'm the PR author (self-review before requesting others), the skill detects that and keeps findings in the conversation instead of posting comments on the PR. If I've already reviewed and the author pushed fixes, it focuses on what changed since my last review rather than re-reviewing everything. I confirm which comments to post and what review action to take. Claude submits them as a single batched review.
Responding to review feedback
The other side of the bottleneck. Someone reviewed my PR and left comments. Before this skill, handling that meant reading each comment, context-switching to the code, making the fix, writing a reply, going back to GitHub to resolve the thread, then doing it again for the next comment.
Now I run /gh-review-respond. Claude reads all unresolved threads and presents them in three categories:
Fix needed (2)
- @sarah: "Missing null check on line 34" → add guard clause
- @sarah: "This query needs an index" → add database index
Discussion (1)
- @sarah: "Why not use the existing UserService here?"
Disagree (1)
- @sarah: "This should be a separate microservice"
The categorization is the key step. I review Claude's assessment: yes, fix those two, they're real issues. The UserService question needs context, so I explain my reasoning and Claude drafts the reply. For the microservice suggestion, I disagree. The current approach is simpler and we can extract later if the need becomes clear. Claude writes a response that acknowledges the concern and explains the tradeoff.
Getting the tone right on disagreements matters. A dismissive response can derail a productive review. The skill handles the diplomacy; I focus on the substance.
After I confirm, Claude applies the code fixes, replies to each comment on the PR, and resolves all addressed threads in a single batch. Then it commits. One detail that matters more than you'd expect: for human reviewers, it always creates a new commit so the reviewer can see exactly what changed. For bot reviewers (like Copilot), it squashes into existing commits since nobody needs those diffs.
The mechanics change. The judgment doesn't.
These skills automate the mechanical parts of the review cycle: reading diffs in context, posting comments, resolving threads, choosing commit strategies. What they don't automate is the judgment. Deciding that a missing auth check is a blocker but a naming suggestion isn't. Recognizing when feedback improves the design vs. when it's a preference. Knowing when to push back and how to frame it. The time I used to spend on mechanics, I now spend on those decisions.
In the first article in this series, I described the core pattern as "the edge is judgment, not config." The same applies here. The skills handle the cycle. The decisions are still yours.
I've published both skills at claude-review-skills. If your review workflow is different, or you review in a domain with specific requirements (security, API compatibility, accessibility), Claude Code's /skill-creator can build custom review skills from a description of your process.
I'll cover more patterns in future posts.
Top comments (0)