ワンクリックで
code-review
// Comprehensive code review for diffs. Analyzes changed code for security vulnerabilities, anti-patterns, and quality issues. Auto-detects domain (frontend/backend) from file paths.
// Comprehensive code review for diffs. Analyzes changed code for security vulnerabilities, anti-patterns, and quality issues. Auto-detects domain (frontend/backend) from file paths.
CLI best practices for LlamaFarm. Covers Cobra, Bubbletea, Lipgloss patterns for Go CLI development.
Electron patterns for LlamaFarm Desktop. Covers main/renderer processes, IPC, security, and packaging.
Shared Python best practices for LlamaFarm. Covers patterns, async, typing, testing, error handling, and security.
Server-specific best practices for FastAPI, Celery, and Pydantic. Extends python-skills with framework-specific patterns.
Shared TypeScript best practices for Designer and Electron subsystems.
Manage LlamaFarm worktrees for isolated parallel development. Create, start, stop, and clean up worktrees.
| name | code-review |
| description | Comprehensive code review for diffs. Analyzes changed code for security vulnerabilities, anti-patterns, and quality issues. Auto-detects domain (frontend/backend) from file paths. |
| allowed-tools | Bash, Read, Edit, Write, Grep, Glob, Task |
You are performing a comprehensive code review on a diff. Your task is to analyze the changed code for security vulnerabilities, anti-patterns, and quality issues.
This skill expects a diff to be provided in context before invocation. The caller is responsible for generating the diff.
Example invocations:
/code-reviewgit diff HEAD~1, then invokes this skillIf no diff is present in context, ask the user to provide one or offer to generate one (e.g., git diff, git diff main..HEAD).
Auto-detect which checklists to apply based on directory paths in the diff:
| Directory | Domain | Checklist |
|---|---|---|
designer/ | Frontend | Read frontend.md |
server/ | Backend | Read backend.md |
rag/ | Backend | Read backend.md |
runtimes/universal/ | Backend | Read backend.md |
cli/ | CLI/Go | Generic checks only |
config/ | Config | Generic checks only |
If the diff spans multiple domains, load all relevant checklists.
Extract from the diff:
Create a review document using the temp-files pattern:
SANITIZED_PATH=$(echo "$PWD" | tr '/' '-')
REPORT_DIR="/tmp/claude/${SANITIZED_PATH}/reviews"
mkdir -p "$REPORT_DIR"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
FILEPATH="${REPORT_DIR}/code-review-${TIMESTAMP}.md"
Initialize with this schema:
# Code Review Report
**Date**: {current date}
**Reviewer**: Code Review Agent
**Source**: {e.g., "PR diff", "unstaged changes", "main..HEAD"}
**Files Changed**: {count}
**Domains Detected**: {list}
**Status**: In Progress
## Summary
| Category | Items Checked | Passed | Failed | Findings |
|----------|---------------|--------|--------|----------|
| Security | 0 | 0 | 0 | 0 |
| Code Quality | 0 | 0 | 0 | 0 |
| LLM Code Smells | 0 | 0 | 0 | 0 |
| Impact Analysis | 0 | 0 | 0 | 0 |
| Simplification | 0 | 0 | 0 | 0 |
{domain-specific categories added based on detected domains}
## Detailed Findings
{findings added here as review progresses}
For EACH checklist item:
Key principle: The diff is what gets reviewed. The rest of the file provides context to make that review accurate.
Check if the diff might affect other parts of the codebase:
Report any unaccounted-for impacts as findings with severity based on risk.
For each issue found, add an entry:
### [{CATEGORY}] {Item Name}
**Status**: FAIL
**Severity**: Critical | High | Medium | Low
**Scope**: Changed code | Impact analysis
#### Violation
- **File**: `path/to/file.ext`
- **Line(s)**: 42-48 (from diff)
- **Code**:
// problematic code snippet from diff
- **Issue**: {explanation of what's wrong}
- **Recommendation**: {how to fix it}
After completing all checks:
These checks apply to ALL changed code regardless of domain.
Check diff for:
api_key, apiKey, password, secret, token, credential with literal valuesPass criteria: No hardcoded secrets in diff (should use environment variables) Severity: Critical
Check diff for:
eval(, new Function(, setTimeout(", setInterval("eval(, exec(, compile(Pass criteria: No dynamic code execution in changed lines Severity: Critical
Check diff for:
subprocess with shell=True, os.system(exec.Command( with unsanitized inputPass criteria: No unvalidated user input in shell commands Severity: Critical
Check diff for:
console.log, console.debug, console.infoprint( statementsPass criteria: No debug statements in production code changes Severity: Low
Check diff for:
TODO:, FIXME:, HACK:, XXX: commentsPass criteria: New TODOs should be tracked in issues Severity: Low
Check diff for:
catch { } or catch(e) { }except: pass or empty except blocksPass criteria: All error handlers log or rethrow Severity: High
Check diff for:
TODO, PLACEHOLDER, IMPLEMENT, NotImplementedreturn None, return [], return {}Pass criteria: No placeholder implementations in production code Severity: High
Check diff for:
GenericHandler, BaseManager, AbstractFactoryPass criteria: Abstractions are justified by actual reuse Severity: Low
Check if diff modifies:
Pass criteria: All impacted code identified and accounted for Severity: High (if unaccounted impacts found)
Check diff for:
Pass criteria: No obvious duplication in changed code Severity: Medium Suggestion: Extract shared logic into reusable functions
Check diff for:
Pass criteria: Code is reasonably flat and focused Severity: Medium Suggestion: Use early returns, extract helper functions
Check diff for:
Pass criteria: Code uses idiomatic patterns Severity: Low Suggestion: Simplify using language built-ins
Based on detected domains, read and apply the appropriate checklists:
designer/): Read frontend.md and apply those checks to changed codeserver/, rag/, runtimes/): Read backend.md and apply those checks to changed code## Executive Summary
**Review completed**: {timestamp}
**Total findings**: {count}
### Critical Issues (Must Fix)
1. {issue 1}
2. {issue 2}
### Impact Analysis Results
- {summary of any breaking changes or unaccounted impacts}
### High Priority (Should Fix)
1. {issue 1}
2. {issue 2}
### Recommendations
{Overall recommendations based on the changes reviewed}
Scope to diff: Only flag issues in the changed lines. Don't review unchanged code.
Use context: Read full files to understand the changes, but feedback targets the diff only.
Check impacts: When changes touch exports, APIs, or shared code, search for affected consumers.
Be specific: Include file paths, line numbers (from diff), and code snippets for every finding.
Prioritize: Flag critical security issues immediately.
Provide solutions: Each finding should include a recommendation for how to fix it.
Update incrementally: Update the review document after each category, not at the end.