
Semgrep Coderabbit
- 10 installs
- 22 repo stars
- Updated May 28, 2026
- acedergren/agentic-tools
semgrep-coderabbit is a Claude Code skill that orchestrates a two-stage pre-merge code review, running Semgrep pattern scanning before CodeRabbit semantic AI analysis.
About
This skill runs a two-stage code review before a commit or PR merge: fast deterministic Semgrep pattern scanning first, then CodeRabbit semantic AI analysis. It defines tool sequencing, severity priorities, batched fix ordering, and conflict resolution between the two tools. A developer uses it to gate pull requests on security and quality findings. Semgrep failures are treated as blockers rather than suggestions.
- Two-stage review: Semgrep pattern scan first, then CodeRabbit semantic AI analysis
- CRITICAL/HIGH/MEDIUM/LOW severity priorities with merge deadlines
- 3-pass rule: split the PR if review-fix-verify exceeds 3 cycles
Semgrep Coderabbit by the numbers
- 10 all-time installs (skills.sh)
- Ranked #816 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
semgrep-coderabbit capabilities & compatibility
Requires the Semgrep and CodeRabbit CLIs installed; the skill itself sequences the existing tools.
- Capabilities
- code review · security scan · pr gate · severity triage
- Use cases
- code review · security audit
- Pricing
- Bring your own API key
What semgrep-coderabbit says it does
Two-stage code review: fast deterministic pattern detection first, then semantic AI analysis. Order is non-negotiable.
Never run CodeRabbit before Semgrep passes — Semgrep failures are blockers, not suggestions.
npx skills add https://github.com/acedergren/agentic-tools --skill semgrep-coderabbitAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 10 |
|---|---|
| repo stars | ★ 22 |
| Last updated | May 28, 2026 |
| Repository | acedergren/agentic-tools ↗ |
What it does
Gate a commit or PR through a Semgrep scan then a CodeRabbit review, fixing findings by severity.
Who is it for?
Sequencing Semgrep and CodeRabbit on a PR and fixing findings by severity before merge.
Skip if: Basic useQuery-style setup or projects that use neither Semgrep nor CodeRabbit.
When should I use this skill?
When reviewing code changes before commit or PR merge.
What you get
PRs pass a deterministic Semgrep scan then a CodeRabbit review with critical and high findings fixed before merge.
- Passing Semgrep scan
- Resolved CodeRabbit findings by severity
By the numbers
- 4-level severity table (CRITICAL/HIGH/MEDIUM/LOW)
- 3-pass review cycle limit
Files
Semgrep + CodeRabbit Review
Two-stage code review: fast deterministic pattern detection first, then semantic AI analysis. Order is non-negotiable.
NEVER
- Never run CodeRabbit before Semgrep passes — Semgrep failures are blockers, not suggestions.
- Never skip re-running both tools after fixes — fixes can introduce new issues.
- Never treat LOW findings as blocking — they are optional polish.
- Never do more than 3 review cycles on the same PR — if still failing after 3, break the PR into smaller pieces.
- Never context-switch between issue types mid-fix — batch similar issues together.
Execution Order
Stage 1: Semgrep (10-20 seconds)
└─ FAIL → fix ALL violations → re-run until PASS
└─ PASS → proceed to Stage 2
Stage 2: CodeRabbit (5-30 minutes)
└─ Evaluate findings by priority
└─ Fix CRITICAL + HIGH before merge
└─ Consider MEDIUM if reasonable
└─ LOW is optional
Stage 3: Verify
└─ Re-run both tools after fixes
└─ Confirm no new issues introducedCommands
# Stage 1 — run on each changed file (loop required for Semgrep 1.146.0+)
for f in $(git diff --name-only HEAD); do
semgrep scan --config auto --json "$f" 2>/dev/null
done
# Stage 2
coderabbit review --diff uncommitted
# Verify after fixes (repeat both)
semgrep scan --config auto <changed-files>
coderabbit review --diff uncommittedIf a project has a .semgrep.yaml, use --config .semgrep.yaml instead of --config auto.
Priority Reference
| Priority | Level | Examples | Deadline |
|---|---|---|---|
| CRITICAL | Blocking | Hardcoded secrets, auth bypass, SQL injection, XSS, data leakage | Must fix before merge |
| HIGH | Architectural | Missing auth guards, schema mismatch, breaking changes, race conditions | Fix before merge |
| MEDIUM | Quality | Weak crypto, poor error handling, type safety violations, duplication | Fix if reasonable |
| LOW | Polish | Suggestions, optimization opportunities, style | Consider optional |
What Each Tool Catches (non-obvious)
Semgrep: Hardcoded secrets/API keys, missing auth guards on routes, weak crypto (MD5/SHA1), debug statements in prod, unsafe any types, SQL injection patterns.
CodeRabbit: N+1 query patterns, multi-tenant isolation gaps, API contract drift between services, test coverage gaps on behavioral changes — things that require semantic understanding of the codebase.
Fix Strategy
Batch by type, not by file. Fix all secrets issues, then all auth issues, then all injection issues. Run unit tests after each batch.
CRITICAL fixes first — security and auth bypass issues must be resolved before anything else. They are non-negotiable blockers.
3-pass rule — if the review-fix-reverify cycle exceeds 3 iterations, the PR scope is too large. Split it.
Conflict Resolution
When Semgrep and CodeRabbit give conflicting feedback on the same line: trust Semgrep. Its rules are deterministic and explicit. Validate CodeRabbit's concern with context before acting on it.
When to Use Each Mode
| Situation | Use |
|---|---|
| Pre-commit quick check | --semgrep-only (10-20s) |
| Before creating PR | (empty) full two-stage |
| Review specific recent commits | --since HEAD~3 |
| Only staged files (partial work) | --staged |
| CodeRabbit not installed/available | --semgrep-only + manual checklist |
Related skills
FAQ
Should Semgrep or CodeRabbit run first?
Semgrep runs first because its failures are blockers; only after Semgrep passes do you run CodeRabbit.
Which findings block a merge?
CRITICAL and HIGH findings such as hardcoded secrets, auth bypass, and SQL injection must be fixed before merge; LOW is optional polish.