code-review

Category: Development & Coding | Uploader: jezweb | Downloads: 0 | Version: v1.0（Latest）

Review code for bugs, security issues, performance problems, and style. Use when the user pastes code, shares a file, or asks "what's wrong with this code?".

Changelog: Source: GitHub https://github.com/jezweb/vite-flare-starter

Directory Structure

Current level: tree/main/skills/code-review/

📄 SKILL.md 2.7 KB

SKILL.md

---
name: code-review
description: Review code for bugs, security issues, performance problems, and style. Use when the user pastes code, shares a file, or asks "what's wrong with this code?".
---

# Code Review

## When to use
- User pastes code in chat
- User attaches a code file
- User asks for review, audit, "find bugs", "security check"

## Steps

1. **Identify scope and language** — what's being reviewed, in what language? If multiple files involved, ask which to focus on first via `ask_questions`.

2. **Read the code carefully** — don't skim. For files in `fs`, call `fs_read`.

3. **Categorise findings**:
   - **Bugs** (incorrect behaviour, will fail at runtime)
   - **Security** (injection, auth bypass, exposed secrets, unsafe deserialization)
   - **Performance** (N+1 queries, unnecessary loops, blocking ops)
   - **Reliability** (missing error handling, race conditions, resource leaks)
   - **Style** (naming, formatting, idiomatic patterns)
   - **Design** (architecture, coupling, complexity)

4. **Filter ruthlessly** — only report issues you're confident about. Skip:
   - Style nits if the user asked about bugs
   - Theoretical problems with no evidence in this code
   - Personal preferences disguised as best practices

5. **For each finding, provide**:
   - **Severity**: critical / high / medium / low
   - **Line reference** if available
   - **What's wrong** (one sentence)
   - **Why it matters** (one sentence)
   - **Suggested fix** (code snippet)

6. **Display the findings**:
   - For 1-3 findings: render inline as markdown
   - For more: use `show_data_table` with columns: Severity, Line, Issue, Fix
   - Use `show_alert` (`error` type) for any critical findings at the top

7. **Summarise** — one paragraph: overall code quality, biggest concern, recommended next action.

8. **Offer next steps** via `offer_choices`:
   - "Apply the critical fix"
   - "Show me how to test this"
   - "Review another file"
   - "Explain finding [N]"

## Style
- Direct but not harsh. Critique the code, not the coder.
- Show, don't tell — code suggestions speak louder than abstract advice.
- Acknowledge what's good if there are bright spots.

## What not to do
- Don't make up issues to seem thorough
- Don't suggest sweeping rewrites unless asked
- Don't mix style nits with critical bugs in the same list (separate by severity)
- Don't claim certainty about runtime behaviour you can't verify (note assumptions)

## Optional: actually run the code
If `run_python` or `run_shell` tools are available and the code is safe to execute, run it with the user's permission to verify:
- Does it execute without errors?
- Does the output match expected behaviour?

Use `confirm_action` first: "Should I run this code in the sandbox to test it?"

Comments 0

Latest | Hot

Please login before commenting.

Loading comments...

code-review

Directory Structure

SKILL.md

Report

Notice