CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Use when code has been written and needs validation before committing, or when the user asks for a code review or security check.

56

Quality

63%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./plugins/claude-code/skills/code-review/SKILL.md
SKILL.md
Quality
Evals
Security

Code Review

Overview

Review code for security, correctness, and quality. Runs in isolated code-reviewer context with pre-loaded standards.

Announce at start: "I'm using the code-review skill to validate [files/feature]."

The Process

Step 1: Pre-Load Context (Main Agent)

Load standards BEFORE invoking review:

Read: .opencode/context/core/standards/code-quality.md
Read: .opencode/context/core/standards/security-patterns.md

Step 2: Invoke Review

/code-review path/to/file.ts
/code-review src/auth/*.ts
/code-review $(git diff --name-only HEAD~1)

Step 3: Analyze Report

Code-reviewer returns structured findings:

## Code Review: Auth Service

### 🔴 CRITICAL (Must Fix)
1. **SQL Injection Risk** — src/db/query.ts:42
   - Problem: Unparameterized query with user input
   - Risk: Database compromise
   - Fix:
     ```diff
     - db.query(`SELECT * FROM users WHERE id = ${userId}`)
     + db.query('SELECT * FROM users WHERE id = ?', [userId])
     ```

### 🟠 HIGH (Correctness)
2. **Missing Error Handling** — src/auth/service.ts:28
   - Problem: Async function without try/catch
   - Risk: Unhandled promise rejection
   - Fix: Wrap in try/catch with proper logging

### 🟡 MEDIUM (Style)
3. **Naming Convention** — src/auth/middleware.ts:15
   - Problem: snake_case instead of camelCase
   - Fix: Rename verify_token → verifyToken

### Summary
Total Issues: 3 (1 Critical, 1 High, 1 Medium)
Recommendation: REQUEST CHANGES

Step 4: Take Action

If CRITICAL or HIGH issues:

  1. STOP—do not commit
  2. Fix issues using suggested diffs
  3. Re-run /code-review to verify
  4. Proceed only when clean

If only MEDIUM or LOW issues:

  1. Evaluate whether to fix now or later
  2. Apply quality improvements
  3. Safe to commit

If no issues:

  1. Commit with confidence
  2. Note positive patterns

Review Checks

🔴 CRITICAL (Security):

  • SQL injection, XSS, command injection
  • Hardcoded credentials or secrets
  • Path traversal, auth bypass

🟠 HIGH (Correctness):

  • Missing error handling
  • Type mismatches
  • Null/undefined gaps
  • Logic errors, race conditions

🟡 MEDIUM (Maintainability):

  • Naming violations
  • Code duplication
  • Poor organization

🟢 LOW (Suggestions):

  • Performance optimizations
  • Documentation improvements

Error Handling

Review fails:

  • Ensure context files pre-loaded

Too many findings:

  • Fix CRITICAL first, then re-review

Unclear findings:

  • Request clarification in report

Red Flags

If you think any of these, STOP and re-read this skill:

  • "The code looks fine, a review is overkill"
  • "I wrote it, I know it's correct"
  • "We're in a hurry, we can review later"
  • "It's a small change, no security risk"

Common Rationalizations

ExcuseReality
"I just wrote it so I know it's right"The author is the worst reviewer. Fresh eyes catch what familiarity hides.
"It's a small change"Security vulnerabilities are almost always in small, "obvious" changes.
"We can review after merging"Post-merge review finds bugs in production. Pre-merge review finds them for free.
"There's no user input so no injection risk"Internal data becomes user input when requirements change. Review now.

Remember

  • Pre-load standards BEFORE invoking review
  • CRITICAL and HIGH issues BLOCK commits
  • Apply suggested fixes with code diffs
  • Re-review after fixing blocking issues
  • Review does NOT modify code—only suggests changes
  • Review does NOT run tests—use test-generation for that

Related

  • context-discovery
  • code-execution
  • test-generation

Task: Review the following files: $ARGUMENTS

Instructions for code-reviewer subagent:

  1. Read all files in $ARGUMENTS
  2. Apply pre-loaded standards (code quality, security, conventions)
  3. Scan for: Security (HIGHEST PRIORITY) → Correctness → Style → Performance
  4. Structure findings by severity: CRITICAL → HIGH → MEDIUM → LOW
  5. For each finding: Problem + Risk + Suggested fix with diff
  6. Include positive observations
  7. Return recommendation: APPROVE | REQUEST CHANGES | COMMENT
Repository
darrenhinde/OpenAgentsControl
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.