Code Review Partner

Purpose

Help developers get a structured, severity-graded code review before opening a pull request or sharing code with teammates. The skill reads a code snippet, diff, or file content — then analyzes it across four dimensions (security, performance, maintainability, style) and produces a GitHub-ready review report with concrete fix suggestions.

This is a prompt-only code review companion. It does not connect to repositories, execute code, run linters, access file systems, or make network calls. It works with whatever code the user pastes or describes.

Important limitation: AI code review cannot replace human review, security audit, or automated tests. Every finding is a suggestion that must be verified by a human reviewer.

Use This Skill When

Use this skill when the user wants to:

• Self-review code before opening a PR on GitHub, GitLab, or Bitbucket.
• Get a second opinion on a refactoring or new feature implementation.
• Check a code snippet for security vulnerabilities (OWASP Top 10, injection, auth issues).
• Identify performance bottlenecks (N+1 queries, unnecessary allocations, blocking I/O).
• Audit code for maintainability issues (coupling, naming, SOLID violations, missing error handling).
• Prepare for a team code review session by pre-identifying the most important issues.
• Review an open-source contribution before submitting it upstream.
• Learn best practices by seeing what a thorough review looks like on their own code.

Do not use this skill to:

• Replace mandatory peer review processes (SOC 2, compliance, regulated industries).
• Audit production security without a qualified security engineer.
• Validate cryptographic implementations or authentication protocols.
• Certify code as bug-free or production-ready.

Sample Prompts

Users can start with prompts like:

• "Review this Python function for security issues and performance problems."
• "Here's my PR diff — what should I fix before asking for review?"
• "Check this React component for accessibility, performance, and edge cases."
• "Review this SQL query for injection risks and indexing issues."
• "I'm refactoring this Java class. Check it against SOLID principles."
• "Audit this Express.js middleware for OWASP Top 10 vulnerabilities."
• "Here's 200 lines of Go — give me a structured review with severity levels."
• "Review this TypeScript type definitions file for correctness and completeness."

Best Inputs

To get the most useful review, provide:

• The code snippet, diff, or file content — paste it directly. Aim for 50-500 lines for a thorough review; longer submissions will still work but the review may be less granular.
• Language and framework — e.g., Python 3.12 / Django, TypeScript / Next.js 14, Go 1.22, Rust, Java 21 / Spring Boot.
• Context — what does this code do? Is it a new feature, a bug fix, a refactoring, or a library?
• Known concerns — are you worried about security, performance, correctness, readability, or test coverage?
• Target audience — is this for a team PR, an open-source contribution, a coding interview, or personal learning?
• Constraints — any style guides, lint rules, architectural patterns, or framework conventions that apply.

Workflow

1. Parse context. Identify the language, framework, and purpose from the user's description and code. Confirm before proceeding if context is unclear.
2. Security scan. Check for common vulnerability patterns: injection (SQL, command, LDAP, XPath), XSS, CSRF, path traversal, insecure deserialization, hardcoded secrets, missing input validation, broken authentication/authorization, sensitive data exposure, improper error handling, and dependency-related risks. Reference OWASP Top 10 where relevant.
3. Performance analysis. Identify: N+1 queries, unnecessary allocations or copies, blocking I/O on hot paths, missing caching opportunities, inefficient data structures, unbounded loops/recursion, missing pagination, excessive logging, and regex catastrophic backtracking.
4. Maintainability review. Check: naming clarity, function/method length, cyclomatic complexity, coupling/cohesion, SOLID principles, error handling completeness, logging adequacy, magic numbers/strings, dead code, commented-out blocks, and missing documentation for public APIs.
5. Style and consistency. Note: naming conventions, indentation, brace placement, import organization, type annotation usage, comment quality, and consistency with language idioms.
6. Test coverage notes. Flag: untestable code patterns, missing edge case handling, tight coupling that blocks mocking, and suggestions for test scenarios.
7. Grade severity. Assign every finding one of: Blocker (must fix before merge), Critical (should fix before merge), Major (should fix soon), Minor (nice to fix), Nit (style preference).
8. Suggest fixes. For Blocker/Critical/Major issues, provide concrete code suggestions showing the fix pattern. Never just flag — always show the direction.
9. Assemble report. Produce the structured output in the format below.

Output Format

Return the review in this structured order.

1. Review Summary

2. Severity Guide

Brief reminder of what each level means in a PR context:

• Blocker: Security vulnerability, data loss, crash, or logic error that must be fixed.
• Critical: Significant bug, performance regression, or design flaw that should be fixed.
• Major: Code smell, missing error handling, or maintainability issue that should be addressed.
• Minor: Style inconsistency, minor readability issue, or missing comment.
• Nit: Personal preference. Consider but feel free to ignore.

3. Findings

For each finding, use this format:

[SEVERITY] [Category] Short title (line ~N)

Problem: 1-2 sentence explanation.
Risk: Why this matters.
Fix: Concrete code suggestion or direction.

Group findings by severity: Blocker → Critical → Major → Minor → Nit.

4. Positive Observations

Acknowledge what the code does well — clear naming, good error handling, elegant patterns, strong test coverage. This builds trust and makes the review constructive.

5. Suggested Test Scenarios

2-5 test cases that would catch the most likely regressions. Focus on boundary conditions, error paths, and edge cases.

6. PR Description Draft (Optional)

If the user is preparing a PR, draft a description following the What / Why / How / Testing format.

Real Task Examples

Example 1: Python Express — SQL Injection + N+1 Query

Input:

Language: Python 3.12 / Flask + SQLAlchemy
Context: API endpoint that looks up orders by customer email.

@app.route('/api/orders')
def get_orders():
    email = request.args.get('email')
    query = f"SELECT * FROM orders WHERE customer_email = '{email}'"
    result = db.session.execute(query)
    orders = []
    for row in result:
        order = dict(row)
        customer = db.session.execute(f"SELECT * FROM customers WHERE id = {order['customer_id']}")
        order['customer_name'] = dict(customer.fetchone())['name']
        orders.append(order)
    return jsonify(orders)

Steps (following the 9-step workflow):

1. Parse context: Python/Flask with SQLAlchemy. REST API endpoint. Purpose: customer order lookup.
2. Security scan: Raw f-string SQL construction is SQL injection (Blocker). No input validation on email parameter.
3. Performance: N+1 query — each order triggers a separate SELECT for customer data (Major). No LIMIT/pagination.
4. Maintainability: Mixed use of ORM and raw SQL is confusing. No error handling around DB queries. Missing docstring.
5. Style: Route decorator without methods specification.
6. Test: No testability for the N+1 pattern or the raw SQL.
7. Grading: Blocker (SQL injection), Major (N+1, missing pagination), Minor (style).
8. Fix suggestions provided inline.
9. Report assembled.

Output (abbreviated report):

## Review Summary

| Language / Framework | Python 3.12 / Flask + SQLAlchemy |
| Lines reviewed        | 12 |
| Blocker               | 1 |
| Critical              | 0 |
| Major                 | 2 |
| Minor                 | 1 |
| Nit                   | 1 |
| Overall risk          | High |

## Findings

### Blocker

[BLOCKER] [Security] SQL Injection via raw f-string query (line 3)

Problem: The email parameter is interpolated directly into a SQL string. An attacker can inject arbitrary SQL.
Risk: Full database compromise — data exfiltration, modification, or deletion.
Fix: Use parameterized queries or ORM filtering:
  order = Order.query.filter(Order.customer_email == email).all()

### Major

[MAJOR] [Performance] N+1 query problem (lines 5-7)

Problem: Each order triggers an additional SELECT for customer data.
Risk: For 100 orders, this makes 101 queries instead of 1-2. Linear degradation to seconds.
Fix: Use a JOIN or eager loading:
  orders = db.session.query(Order).join(Customer).filter(Order.customer_email == email).all()

[MAJOR] [Performance] No LIMIT/pagination (line 3)

Problem: The query returns all matching rows with no cap.
Risk: A customer with 50,000 orders times out the response.
Fix: Add .limit(100) and support page/offset parameters.

Example 2: React Component — Accessibility + Missing Edge Cases

Input:

Language: TypeScript / React 18
Context: A reusable search input component for a dashboard.

const SearchInput = ({ onSearch }: { onSearch: (q: string) => void }) => {
  const [query, setQuery] = useState('');
  return (
    \x3Cdiv className="search-box">
      \x3Cinput
        type="text"
        value={query}
        onChange={e => setQuery(e.target.value)}
        onKeyDown={e => {
          if (e.key === 'Enter') onSearch(query);
        }}
        placeholder="Search..."
      />
      \x3Cbutton onClick={() => onSearch(query)}>Go\x3C/button>
    \x3C/div>
  );
};

Key findings in output:

• [MAJOR] [Accessibility] Missing label — screen reader association needed (aria-label or \x3Clabel>)
• [MAJOR] [UX] No debounce — rapid typing fires excessive search calls
• [MINOR] [UX] Button text "Go" is not descriptive
• [NIT] [Performance] Inline onChange handler recreated on every render (could use useCallback if query state were complex)

Example 3: Go — Missing Error Handling + Concurrency Issue

Input:

Language: Go 1.22
Context: HTTP handler that concurrently fetches data from multiple downstream services.

func fetchUserData(userID string) (*UserData, error) {
    resp, _ := http.Get("https://api.internal/users/" + userID)
    defer resp.Body.Close()
    // ... parse
}

func handleRequest(w http.ResponseWriter, r *http.Request) {
    userID := r.URL.Query().Get("user_id")
    var wg sync.WaitGroup
    results := make(map[string]interface{})
    
    wg.Add(1)
    go func() {
        defer wg.Done()
        results["profile"], _ = fetchUserData(userID)
    }()
    wg.Wait()
    json.NewEncoder(w).Encode(results)
}

Key findings in output:

• [BLOCKER] [Security] Unsafe userID concatenation into URL — path traversal / SSRF risk
• [CRITICAL] [Correctness] All errors silently swallowed (_ on function return, HTTP response status unchecked)
• [MAJOR] [Concurrency] Unsynchronized map write from goroutine (results["profile"] — data race)
• [MAJOR] [Observability] No request logging, no timeout context
• [MINOR] [Style] Hardcoded internal API URL — should be config

Safety Boundaries

• AI review is not human review. Every finding is a suggestion. A human must verify before merging.
• AI review is not a security audit. This skill cannot certify code as secure. It can flag common patterns but may miss sophisticated attacks, supply-chain issues, or business-logic vulnerabilities. For production systems, always involve a qualified security engineer.
• AI review is not a replacement for tests. Passing a code review does not mean the code works. Always run your test suite and consider adding tests for the scenarios flagged.
• Do not paste secrets, tokens, API keys, or credentials. If the code contains hardcoded secrets, the skill will flag it but the user should rotate any exposed credentials.
• Do not paste proprietary code into shared sessions. This skill processes text in the current AI session context. If your session is shared (Discord, group chat), the code will be visible to all participants.
• Do not rely on AI review for compliance. SOC 2, HIPAA, PCI-DSS, and similar frameworks require qualified human review with documented processes.
• The skill does not execute, compile, or test code. It performs static analysis through the AI model's understanding only. No linters, SAST tools, or compilers are invoked.
• Language and framework coverage is not exhaustive. The skill works best with popular languages (Python, JavaScript/TypeScript, Go, Java, Rust, C#, Ruby, PHP) and mainstream frameworks. Niche or proprietary languages may produce lower-quality reviews.

Install-First Success Path

1. Copy this skill directory into ~/.openclaw/skills/code-review-partner/.
2. Restart your OpenClaw session or run the skill reload command.
3. Verify the skill is loaded: check that "Code Review Partner" appears in your available skills.
4. Test with a simple prompt: "Review this Python function for security issues:" followed by a short code snippet.
5. Iterate — try reviews in different languages, with diffs, and for different review dimensions.

Clean Scan Evidence

Before publishing or sharing this skill, verify it passes basic integrity checks:

# Verify only skill files exist (no credentials, logs, or internal documents)
ls -la /path/to/code-review-partner/
# Expected output: SKILL.md, skill.json, ACCEPTANCE.md (3 files)

# Verify no CJK text (English-only requirement)
grep -rP '[\x{4e00}-\x{9fff}\x{3400}-\x{4dbf}]' SKILL.md && echo "FAIL: CJK found" || echo "PASS: no CJK"

# Verify no secrets or credentials
grep -riE '(api.?key|token|secret|password|credential)\s*[:=]\s*[\x27\x22]?[a-zA-Z0-9_-]{8,}' . && echo "FAIL: possible secret" || echo "PASS: no secrets"

# Validate JSON
python3 -c "import json; json.load(open('skill.json'))" && echo "PASS: valid JSON" || echo "FAIL: invalid JSON"

# Count published files (max 10)
find . -not -path './.git/*' -not -name '.git' -type f | wc -l

Version History