Manual code review with BeforeMerge
BeforeMerge gives your team a shared library of code review rules, organized by skill and technology. This guide walks you through setting up a structured review workflow — from browsing the knowledge base to running scans and acting on findings.
Getting started with code review
BeforeMerge organizes code review knowledge into three layers. Understanding these layers will help you build an effective review process for any team size.
Rules
A ruleis a single, focused check — for example, "Avoid raw SQL in Server Actions" or "Never expose service_role keys in client code." Each rule includes a description, impact level (Critical / High / Medium / Low), detection patterns, and good/bad code examples. Rules are the atomic unit of a review.
Skills
A skillis a bundle of related rules scoped to a framework or domain — like "Next.js Security" or "React Performance." Installing a skill gives your team all of its rules at once, making it easy to adopt best practices for a specific technology stack.
Collections & projects
Collectionsare curated lists of rules across different skills — like an "OWASP Top 10" checklist. Projects go further by grouping repositories, rules, and team-specific overrides into a single workspace. Use projects to tailor severity levels and suppress rules that don't apply to a particular codebase.
Step-by-step walkthrough
Follow these steps to go from zero to a fully structured code review workflow.
Browse the Explore page for relevant rules
Head to the Explore page and filter by category (security, performance, architecture, quality) or search for your tech stack. Each rule shows its impact level and effort required so you can prioritize what matters most.
Fork and customize rules for your team
Found a rule that almost fits? Fork it into your workspace and adjust the description, severity, or detection patterns to match your team's standards. Forked rules stay private to your organization while the original continues to receive community updates.
Organize rules into collections
Group related rules into collections. A collection can span multiple skills — for example, a "Pre-deploy checklist" might include security rules from one skill and performance rules from another. Collections make it easy to share a curated set of checks with your team.
Create a project to group repos, rules, and overrides
Projects tie everything together. Link one or more repositories, attach the rules and collections you want enforced, and set per-project overrides (e.g., downgrade a rule's severity for a legacy codebase, or suppress a rule entirely). Each project acts as a self-contained review configuration.
Run a scan to automatically check code
Trigger a scan from your project dashboard. The scanner evaluates your repository against all attached rules, runs grep and semgrep detection patterns, and produces a list of findings. Each finding maps back to a specific rule so you know exactly what to fix and why.
Review findings and suppress false positives
Walk through each finding in the scan results. Accept findings that need fixing, and suppress false positives with a reason so they don't reappear. Over time, your suppression list becomes a living record of intentional deviations from the rules.
Best practices
Teams get the most out of BeforeMerge when they follow a few key principles.
Start with security rules
Security rules have the highest impact and the clearest pass/fail criteria. Begin with categories like SQL injection, auth bypass, and secret exposure before moving to architecture and style rules.
Customize severity levels
Not every rule is equally important for every project. Use project-level overrides to promote critical rules and downgrade ones that are less relevant to your stack. This keeps scan results actionable.
Use rule overrides per project
A monorepo backend may need different rules than a mobile app. Create separate projects for each codebase and apply team-specific overrides instead of disabling rules globally.
Integrate with PR workflow
Review scan results as part of your pull request process. Automated PR comments are coming soon — in the meantime, run scans before merging and reference findings in your review comments.
Example: Reviewing a Next.js PR
Here is a concrete walkthrough of reviewing a pull request for a Next.js application using BeforeMerge.
Scenario
A teammate opens a PR that adds a new Server Action for updating user profiles. The action accepts form data, writes to Supabase, and revalidates the cache. You want to review it for security, performance, and architecture best practices.
1. Skills to enable
For a Next.js + Supabase project, install these skills:
2. What findings to expect
Running a scan against the PR branch, you might see findings like:
CRITICAL Validate Server Action inputs
app/actions/update-profile.ts:12
Form data is used directly without Zod validation.
HIGH Avoid raw SQL in Server Actions
app/actions/update-profile.ts:28
Template literal used in .rpc() call.
MEDIUM Use createAdminClient() for mutations
app/actions/update-profile.ts:8
createClient() is used for a write operation.
Writes should use service_role via createAdminClient().
LOW Add revalidation after mutation
app/actions/update-profile.ts:35
No revalidatePath() or revalidateTag() after database write.3. How to act on findings
Start reviewing with structure
Browse the knowledge base, build your rule set, and bring consistency to every pull request.