$cd ../use-cases/
πΎ DeveloperBeta10 min setup
$ cat github-pr-auto-review.md
await reviewPullRequest(github, { style: 'strict' })
/** Every Pull Request gets a rigorous, context-aware code review within 60 seconds. Stop waiting for teammates, catch bugs earlier, and enforce coding standards automatically. */
architecture.md
βοΈ Architecture & Data Flow
01.
GitHub Webhook Trigger
A developer opens, reopens, or pushes new commits to a Pull Request. GitHub fires an HMAC-signed webhook payload to your self-hosted OpenClaw instance β reachable via ngrok, Cloudflare Tunnel, or a self-managed reverse proxy. The trigger fires in under 200ms from the push event.
02.
Differential Retrieval
OpenClaw authenticates the webhook signature, extracts the PR number and base/head refs, and fetches the precise git diff via the GitHub API. Large PRs are automatically split by file into parallel analysis chunks, so a 5,000-line PR is analyzed with the same latency as a 200-line one.
03.
LLM Analysis Pipeline
Each diff chunk is sent to your configured LLM β local Llama 3 via Ollama, or cloud-based Claude 3.5 Sonnet or GPT-4o. The model analyzes for logic errors, null pointer dereferences, security vulnerabilities across all OWASP Top 10 categories, missing test coverage for changed branches, performance anti-patterns, and style guide violations from your team's configured ruleset.
04.
Structured Feedback Delivery
OpenClaw aggregates findings across all chunks, deduplicates overlapping comments, and posts a single structured Markdown comment to the GitHub PR. Findings are sorted by severity (π΄ Blocker β π‘ Warning β π΅ Suggestion) with direct links to the affected line numbers for one-click navigation.
05.
Merge Gatekeeping (Optional)
When configured, OpenClaw calls the GitHub Checks API to block merges automatically for Blocker-level findings. A 'checks' badge appears on the PR showing pass/fail status. The block clears automatically when a developer pushes a fix that resolves the flagged issue β no manual approval required.
config_override.yaml
π Example Configuration Override
// You can deeply customize the LLM's reviewing persona in config.yaml
github_reviewer:
# The strictness level of the AI
strictness: high
# Inject custom team guidelines
custom_prompt: |
- You are a senior engineer at Stripe.
- We use camelCase for variables.
- Ban the use of 'any' in TypeScript.
- All API endpoints must have rate limits.
# Merge gatekeeping behavior
block_on:
- critical_security
- logic_errors
- performance_degradation
# Model routing for this specific task
model_override:
provider: anthropic
model: claude-3-5-sonnet-latestroi_analysis.csv
π Real-World ROI
Review latency
A first-pass review lands in roughly 45β90 seconds depending on diff size, instead of waiting for a human to have time. The value is that nothing sits in the queue, not that the review is better.
What it catches
The mechanical defects a human reviewer skims past β null dereferences, off-by-one errors, an unhandled branch. It will not catch a design mistake, and treating it as if it might is the way this setup goes wrong.
What it frees up
Senior reviewer attention, by taking the formatting and basic logic checks.
pr_comment.log
π¬ Example AI PR Comment
π€openclaw-botcommented just now
Security Review (OWASP Top 10)
π΄ Blocker: Potential SQL Injection
File: src/controllers/userController.ts (Line 47)
The user input req.body.username is concatenated directly into the raw SQL string. This makes the application vulnerable to SQL Injection attacks. Please use parameterized queries or an ORM like Prisma/TypeORM instead.
- const query = `SELECT * FROM users WHERE name = '${req.body.username}'`;
+ const query = 'SELECT * FROM users WHERE name = $1';
+ const result = await db.query(query, [req.body.username]);
Code Quality
π‘ Warning: Missing Error Boundary
File: src/components/Dashboard.tsx (Line 112)
The new fetchMetrics() async call is missing a try/catch block. If the API fails, it will cause an Unhandled Promise Rejection and crash the component tree.
π‘ Suggestion: Refactoring
File: src/utils/formatters.ts (Lines 22-45)
Consider extracting the date manipulation logic into a dedicated helper function to improve testability. Currently, it is tightly coupled with the formatting logic.
β FAQ
Q1. Does it replace human code reviewers?
No β it eliminates the mechanical 80% so humans can focus on the meaningful 20%. OpenClaw catches null dereferences, injection patterns, missing error handling, and formatting violations automatically. Senior engineers then focus exclusively on architecture decisions, business logic correctness, and product-level trade-offs that require genuine domain judgment.
Q2. Which programming languages does it support?
Any language the underlying LLM was trained on: TypeScript, JavaScript, Python, Go, Rust, Java, C#, Ruby, PHP, Swift, Kotlin, Scala, Elixir, and more. The review prompt is language-aware β it applies idiomatic style rules specific to each language rather than generic feedback.
Q3. Can it block merges for critical issues?
Yes. Using the GitHub Checks API, OpenClaw sets the PR commit status to 'failed' when Blocker-severity findings exist. The check clears automatically when the developer pushes a fix. Severity thresholds, affected file patterns, and bypass rules for specific GitHub teams are all configurable in config.yaml.
Q4. Is my source code sent to third parties?
Only if you configure cloud-based LLMs. With local models (Llama 3, Qwen 2.5, or DeepSeek Coder via Ollama), the diff text never leaves your server. With API-based models like Claude or GPT-4o, only the raw diff is transmitted β never your git history, secrets, or unmodified files.
Q5. How fast is the review?
Average: 45β90 seconds from PR open event to the review comment appearing, depending on diff size and model. With local Llama 3 on an M2 Mac Mini, median latency is 70 seconds for diffs under 500 lines. This compares to a 4.2-hour average human review latency on teams that participated in the original performance study.
Q6. Can I customize what the AI looks for?
Yes. The reviewing persona, focus areas, severity mapping, and output format are all defined in a YAML config file. You can tune it to enforce your team's specific style guide, prioritize security over style, or add project-specific rules like 'always require error handling for database calls.'
Q7. Does it work with GitLab or Bitbucket?
GitHub is the primary target with native Checks API integration. Community-contributed adapters exist for GitLab merge requests and Bitbucket pull requests via their respective webhook and comment APIs. The core analysis engine is platform-agnostic.