Code Review Engine
v1.0.0Enterprise-grade code review agent. Reviews PRs, diffs, or code files for security vulnerabilities, performance issues, error handling gaps, architecture smells, and test coverage. Works with any language, any repo, no dependencies required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The skill claims enterprise-grade reviews across PRs, local diffs, and GitHub integration, and advertises features like 'heartbeat/cron ready' and 'works with gh CLI'. However the registry metadata declares no required binaries, no environment variables, no install spec, and no code — so GitHub/cron integration would require external credentials/tools that the skill does not request or document. This is potentially misleading (could be an instruction-only skill that expects the user to supply PR text), but the README implies tighter integration than the manifest supports.
Instruction Scope
SKILL.md contains detailed, bounded instructions for analyzing code and a clearly defined SPEAR review framework. It instructs the agent to review pasted code, diffs, or provided PR content, and to look for malicious behavior and exfiltration in reviewed sources. It does not instruct the agent to read system files, environment variables, or any unrelated data sources. The only scope ambiguity is how the agent should fetch remote PRs (no credential or fetch procedure specified).
Install Mechanism
This is an instruction-only skill with no install spec or code files — lowest-risk install profile. Nothing will be written to disk or downloaded by the skill itself according to the manifest.
Credentials
The skill requests no environment variables or credentials, which is consistent with an instruction-only reviewer that operates on user-supplied text. However the README/SKILL.md mention GitHub/gh CLI integration and automated cron/heartbeat reviews without declaring any required tokens or tools. That omission is a mismatch: real GitHub integration normally requires a GH token and/or gh CLI binary.
Persistence & Privilege
always:false and no install means the skill does not request permanent presence or elevated platform privileges. It is user-invocable and can be invoked autonomously by agents (platform default) but nothing in the manifest gives it special permanent privileges or cross-skill modifications.
What to consider before installing
This skill appears to be a self-contained instruction set for reviewing code you supply (pasted code, diffs, or PR text). Before installing or enabling it: 1) Verify the origin — there is no homepage or source repository and the owner ID looks non-descriptive. 2) Do not provide repository credentials, API tokens, or secrets to the skill unless the skill explicitly requests them and you trust the author; the manifest does not declare any GH token or binaries even though the README mentions GitHub integration. 3) Prefer using it on pasted code or local diffs first; avoid granting automated/cron access to production repos until you confirm how the skill fetches PRs and where credentials would be stored. 4) If you need GitHub integration, request clear documentation from the publisher describing required binaries, env vars (e.g., GH_TOKEN), and how tokens are handled/stored. 5) Because source/homepage are missing, treat outputs as advisory — validate any high-severity findings manually or with additional tools before acting. If the publisher can provide a source repo or clarify how remote PR access is authorized, re-evaluate once that information is available.Like a lobster shell, security has layers — review code before you run it.
code-reviewdevtoolsgithublatestpr-reviewsecurity
Code Review Engine
Enterprise-grade automated code review. Works on GitHub PRs, local diffs, pasted code, or entire files. No dependencies — pure agent intelligence.
Quick Start
Review a GitHub PR
Review PR #42 in owner/repo
Review a local diff
Review the staged changes in this repo
Review a file
Review src/auth/login.ts for security issues
Review pasted code
Just paste code and say "review this"
Review Framework: SPEAR
Every review follows the SPEAR framework — 5 dimensions, each scored 1-10:
🔴 S — Security (Weight: 3x)
| Check | Severity | Example |
|---|---|---|
| Hardcoded secrets | CRITICAL | API keys, passwords, tokens in source |
| SQL injection | CRITICAL | String concatenation in queries |
| XSS vectors | HIGH | Unsanitized user input in HTML/DOM |
| Path traversal | HIGH | User input in file paths without validation |
| Insecure deserialization | HIGH | eval(), pickle.loads(), JSON.parse on untrusted input |
| Auth bypass | CRITICAL | Missing auth checks on endpoints |
| SSRF | HIGH | User-controlled URLs in server requests |
| Timing attacks | MEDIUM | Non-constant-time string comparison for secrets |
| Dependency vulnerabilities | MEDIUM | Known CVEs in imported packages |
| Sensitive data logging | MEDIUM | PII, tokens, passwords in log output |
| Insecure randomness | MEDIUM | Math.random() for security-sensitive values |
| Missing rate limiting | MEDIUM | Auth endpoints without throttling |
🟡 P — Performance (Weight: 2x)
| Check | Severity | Example |
|---|---|---|
| N+1 queries | HIGH | DB call inside a loop |
| Unbounded queries | HIGH | SELECT * without LIMIT on user-facing endpoints |
| Missing indexes (implied) | MEDIUM | Frequent WHERE/ORDER on unindexed columns |
| Memory leaks | HIGH | Event listeners never removed, growing caches |
| Blocking main thread | HIGH | Sync I/O in async context, CPU-heavy in event loop |
| Unnecessary re-renders | MEDIUM | React: missing memo, unstable refs in deps |
| Large bundle imports | MEDIUM | import _ from 'lodash' vs import get from 'lodash/get' |
| Missing pagination | MEDIUM | Returning all records to client |
| Redundant computation | LOW | Same expensive calc repeated without caching |
| Connection pool exhaustion | HIGH | Not releasing DB/HTTP connections |
🟠 E — Error Handling (Weight: 2x)
| Check | Severity | Example |
|---|---|---|
| Swallowed errors | HIGH | Empty catch blocks, Go _ := on error |
| Missing error boundaries | MEDIUM | React components without error boundaries |
| Unchecked null/undefined | HIGH | No null checks before property access |
| Missing finally/cleanup | MEDIUM | Resources opened but not guaranteed closed |
| Generic error messages | LOW | catch(e) { throw new Error("something went wrong") } |
| Missing retry logic | MEDIUM | Network calls without retry on transient failures |
| Panic/exit in library code | HIGH | panic(), os.Exit(), process.exit() in non-main |
| Unhandled promise rejections | HIGH | Async calls without .catch() or try/catch |
| Error type conflation | MEDIUM | All errors treated the same (4xx vs 5xx, retriable vs fatal) |
🔵 A — Architecture (Weight: 1.5x)
| Check | Severity | Example |
|---|---|---|
| God functions (>50 lines) | MEDIUM | Single function doing too many things |
| God files (>300 lines) | MEDIUM | Monolithic module |
| Tight coupling | MEDIUM | Direct DB calls in request handlers |
| Missing abstraction | LOW | Repeated patterns that should be extracted |
| Circular dependencies | HIGH | A imports B imports A |
| Wrong layer | MEDIUM | Business logic in controllers, SQL in UI |
| Magic numbers/strings | LOW | Hardcoded values without named constants |
| Missing types | MEDIUM | any in TypeScript, missing type hints in Python |
| Dead code | LOW | Unreachable branches, unused imports/variables |
| Inconsistent patterns | LOW | Different error handling styles in same codebase |
📊 R — Reliability (Weight: 1.5x)
| Check | Severity | Example |
|---|---|---|
| Missing tests for changes | HIGH | New logic without corresponding test |
| Test quality | MEDIUM | Tests that only check happy path |
| Missing edge cases | MEDIUM | No handling for empty arrays, null, boundary values |
| Race conditions | HIGH | Shared mutable state without synchronization |
| Non-idempotent operations | MEDIUM | Retrying could cause duplicates |
| Missing validation | HIGH | User input accepted without schema validation |
| Brittle tests | LOW | Tests depending on execution order or timing |
| Missing logging | MEDIUM | Error paths with no observability |
| Configuration drift | MEDIUM | Hardcoded env-specific values |
| Missing migrations | HIGH | Schema changes without migration files |
Scoring System
Per-Finding Severity
CRITICAL → -3 points from dimension score
HIGH → -2 points
MEDIUM → -1 point
LOW → -0.5 points
INFO → 0 (suggestion only)
Overall SPEAR Score Calculation
Raw Score = (S×3 + P×2 + E×2 + A×1.5 + R×1.5) / 10
Final Score = Raw Score × 10 (scale 0-100)
Verdict Thresholds
| Score | Verdict | Action |
|---|---|---|
| 90-100 | ✅ EXCELLENT | Ship it |
| 75-89 | 🟢 GOOD | Minor suggestions, approve |
| 60-74 | 🟡 NEEDS WORK | Address findings before merge |
| 40-59 | 🟠 SIGNIFICANT ISSUES | Major rework needed |
| 0-39 | 🔴 BLOCK | Critical issues, do not merge |
Review Output Template
Use this structure for every review:
# Code Review: [PR title or file name]
## Summary
[1-2 sentence overview of what this code does and overall quality]
## SPEAR Score: [X]/100 — [VERDICT]
| Dimension | Score | Key Finding |
|-----------|-------|-------------|
| 🔴 Security | X/10 | [worst finding or "Clean"] |
| 🟡 Performance | X/10 | [worst finding or "Clean"] |
| 🟠 Error Handling | X/10 | [worst finding or "Clean"] |
| 🔵 Architecture | X/10 | [worst finding or "Clean"] |
| 📊 Reliability | X/10 | [worst finding or "Clean"] |
## Findings
### [CRITICAL/HIGH] 🔴 [Title]
**File:** `path/to/file.ts:42`
**Category:** Security
**Issue:** [What's wrong]
**Impact:** [What could happen]
**Fix:**
```[lang]
// suggested fix
[MEDIUM] 🟡 [Title]
...
What's Done Well
- [Genuinely good patterns worth calling out]
Recommendations
- [Prioritized action items]
---
## Language-Specific Patterns
### TypeScript / JavaScript
- `any` type usage → Architecture finding
- `as` type assertions → potential runtime error
- `console.log` in production code → Style
- `==` instead of `===` → Reliability
- Missing `async/await` error handling
- `useEffect` missing cleanup return
- Index signatures without validation
### Python
- Bare `except:` or `except Exception:` → Error Handling
- `eval()` / `exec()` → Security CRITICAL
- Mutable default arguments → Reliability
- `import *` → Architecture
- Missing `__init__.py` type hints
- f-strings with user input → potential injection
### Go
- `_ :=` discarding errors → Error Handling HIGH
- `panic()` in library code → Reliability HIGH
- Missing `defer` for resource cleanup
- Exported functions without doc comments
- `interface{}` / `any` overuse
### Java
- Catching `Exception` or `Throwable` → Error Handling
- Missing `@Override` annotations
- Mutable static fields → thread safety
- `System.out.println` in production
- Missing null checks (pre-Optional code)
### SQL
- String concatenation in queries → Security CRITICAL
- `SELECT *` → Performance
- Missing WHERE on UPDATE/DELETE → Security CRITICAL
- No LIMIT on user-facing queries → Performance
- Missing indexes for JOIN columns
---
## Advanced Techniques
### Reviewing for Business Logic
Beyond code quality, check:
- Does the code match the PR description / ticket requirements?
- Are there edge cases the spec didn't mention?
- Could this break existing functionality?
- Is there a simpler way to achieve the same result?
### Reviewing for Operability
- Can this be debugged in production? (logging, error messages)
- Can this be rolled back safely?
- Are feature flags needed?
- What monitoring should accompany this change?
### Reviewing Database Changes
- Is the migration reversible?
- Will it lock tables during migration?
- Are there indexes for new query patterns?
- Is there a data backfill needed?
### Security Review Depth Levels
| Level | When | What |
|-------|------|------|
| Quick | Internal tool, trusted input | OWASP Top 10 patterns only |
| Standard | User-facing feature | + auth, input validation, output encoding |
| Deep | Payment, auth, PII handling | + crypto review, session management, audit logging |
| Threat Model | New service/API surface | + attack surface mapping, trust boundaries |
---
## Integration Patterns
### GitHub PR Review
```bash
# Get PR diff
gh pr diff 42 --repo owner/repo
# Get PR details
gh pr view 42 --repo owner/repo --json title,body,files,commits
# Post review comment
gh pr review 42 --repo owner/repo --comment --body "review content"
Local Git Review
# Review staged changes
git diff --cached
# Review branch vs main
git diff main..HEAD
# Review last N commits
git log -5 --oneline && git diff HEAD~5..HEAD
Heartbeat / Cron Integration
Check for open PRs in [repo] that I haven't reviewed yet.
For each, run a SPEAR review and post the results as a PR comment.
Edge Cases & Gotchas
- Large PRs (>500 lines): Break into logical chunks. Review file-by-file. Flag the PR size itself as a finding (Architecture: "PR too large — consider splitting").
- Generated code: Skip generated files (proto, swagger, migrations from ORMs). Note that you skipped them.
- Dependency updates: Focus on breaking changes in changelogs, not the lockfile diff.
- Merge conflicts markers: Flag immediately as CRITICAL —
<<<<<<<in code means broken merge. - Binary files: Note presence, can't review content.
- Config changes: Extra scrutiny — wrong env var = production outage.
- Refactors: Verify behavior preservation. Check if tests still pass conceptually.
Review Checklist (Quick Mode)
For fast reviews when full SPEAR isn't needed:
- No hardcoded secrets or credentials
- No SQL injection / XSS / path traversal
- All errors handled (no empty catch, no discarded errors)
- No N+1 queries or unbounded operations
- Tests exist for new/changed logic
- No
console.log/print/fmt.Printleft in - Functions under 50 lines, files under 300 lines
- Types are specific (no
any/interface{}) - PR description matches the actual changes
- No TODOs without linked issues
Comments
Loading comments...
