The Gap That Claude Code Fills in Code Review
Code review is one of the most valuable things a team does — and one of the most time-consuming. Reviewers catch real bugs, but they also spend energy on things that could be automated: spotting forgotten null checks, flagging coroutine scope misuse, noticing that a ViewModel leaks a reference to Context. Claude Code can handle that category of mechanical review entirely, leaving your human reviewers free to focus on architecture decisions, naming, and logic that actually requires judgement.
Using Claude Code for Android code review doesn’t replace your teammates — it means you arrive at review having already fixed the obvious issues, so the conversation is higher quality from the start.
The Basic Self-Review Workflow
The simplest way to use Claude Code for review is to stage your changes with Git and then invoke the built-in review command:
# Stage everything you want reviewed git add -p # Start Claude Code and review staged changes claude > /review
Claude Code reads the diff of your staged files, cross-references it with your CLAUDE.md conventions, and returns a structured critique. With a good CLAUDE.md (see the setup post in this series), it knows to flag LiveData where you’ve said to use StateFlow, or field injection where you’ve said to use constructor injection.
You can also point it at a specific file or directory without staging:
> Please review feature/home/HomeViewModel.kt for coroutine safety, memory leaks, and adherence to our CLAUDE.md conventions.
Building a Dedicated Android Review Skill
For more targeted, repeatable reviews, a skill gives you a checklist that Claude Code runs every time. Create .claude/skills/android-review/SKILL.md:
# Android Code Review Review the provided files or staged diff for the following Android-specific issues. Return findings grouped by severity: Critical, Warning, and Suggestion. ## Critical (must fix before merge) - !! operator used in production code - Context reference stored in a ViewModel - Coroutine launched with GlobalScope - Network or disk call on the main thread - Missing null safety on API response fields ## Warning (should fix) - LiveData used where StateFlow is the project convention - Field injection via @Inject (use constructor injection) - Hardcoded strings that should be in strings.xml - Catching generic Exception or Throwable without rethrowing CancellationException - StateFlow or SharedFlow created with no explicit initial value ## Suggestion (nice to have) - ViewModel exposes mutable state publicly (_uiState should be private) - Missing loading/error states in UiState - Magic numbers without named constants - Functions longer than 40 lines that could be extracted Ask the user which files or diff to review before starting.
Now /android-review is a consistent, team-agreed checklist. Every developer runs the same review every time, regardless of experience level.
Reviewing a Pull Request Diff
When reviewing someone else’s PR, paste the diff directly into the Claude Code session or copy the PR URL if you have a tool that fetches it:
# Get the diff from the PR branch git fetch origin git diff main...origin/feature/user-profile > pr_diff.txt # Then in Claude Code: > /android-review > [paste or reference pr_diff.txt]
Claude Code will work through your skill’s checklist against the actual diff and return findings with line-level specificity. You can then ask it to generate the review comment text in the format your team uses:
> For each Critical and Warning finding, write a GitHub PR review comment in this format: > "**[Severity]** [Finding]. [One sentence explaining why it matters]. [Suggested fix if applicable."
Catching Architecture Drift
One of the most subtle things code review should catch is architecture drift — code that technically works but starts pulling the project away from its established patterns. This is where a Claude Code prompt beats a linter: you can describe intent, not just syntax.
> Look at the diff in feature/payments/. Our rule is that the UI layer (Screen + ViewModel) never imports anything from :core:network directly — it must go through a UseCase. Does this PR violate that? If so, show me the import lines and suggest the fix.
No static analysis tool knows your module boundary rules unless you’ve written custom Lint checks. Claude Code understands them from your CLAUDE.md description alone.
Making It a Git Hook
If you want the review to run automatically before every commit, wire it into a pre-commit hook:
#!/bin/bash echo "Running Claude Code review on staged changes..." claude -p "/android-review of staged changes, output only Critical findings" \ && exit 0 \ || exit 1
The -p flag (short for –print) runs Claude Code non-interactively and exits with a non-zero code if it finds Critical issues, blocking the commit. Keep the hook fast by restricting it to Critical findings only — the Warnings and Suggestions can wait for the full interactive review session.
Summary
Using Claude Code as a pre-review step on your Android work catches the mechanical issues — null safety, coroutine misuse, architectural violations — before they reach your teammates. A dedicated /android-review skill turns an ad-hoc prompt into a consistent team checklist. Combine it with a Git pre-commit hook for the most critical checks and you’ll ship cleaner code with no extra discipline required.
This post was written by a human with the help of Claude, an AI assistant by Anthropic.