Spaces:
Running
Running
feat(agent): add Claude Code-style agent, skills, slash-commands, hooks, todos, sandboxed workspace, and full-stack scaffolding
81aa0b5 verified | name: code-review | |
| description: Review code for bugs, simplicity, DRY violations, and project conventions. Use when the user asks for a review or before committing changes. | |
| language: any | |
| tags: review, quality, bugs, refactoring | |
| # Code Review | |
| Review code with high signal and low noise. We only want HIGH SIGNAL issues. | |
| ## What to flag | |
| Flag issues where: | |
| - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references) | |
| - The code will definitely produce wrong results regardless of inputs (clear logic errors) | |
| - Clear, unambiguous project convention violations where you can quote the exact rule being broken | |
| - Security issues (hardcoded secrets, SQL injection, XSS, path traversal, command injection) | |
| - Resource leaks (unclosed files, connections, etc.) | |
| ## What NOT to flag | |
| Do NOT flag: | |
| - Code style or quality concerns (subjective) | |
| - Potential issues that depend on specific inputs or state | |
| - Subjective suggestions or improvements | |
| - Issues a linter will catch | |
| - Pre-existing issues outside the diff | |
| - Pedantic nitpicks that a senior engineer would not flag | |
| ## Process | |
| 1. **Read all changed files** using `read_file`. If the user mentions a diff, focus on the changed lines plus surrounding context. | |
| 2. **Run parallel reviews** mentally: | |
| - Review 1: Bugs and functional correctness β does it do what it claims? | |
| - Review 2: Simplicity/DRY/elegance β can it be simpler? | |
| - Review 3: Project conventions β does it match the codebase style? | |
| 3. **Validate each issue**: For each potential issue, check whether it's actually a problem by reading surrounding code. | |
| 4. **Filter false positives**: Drop anything you're not certain about. | |
| 5. **Present findings** sorted by severity (critical > high > medium > low). For each issue: | |
| - File and line number | |
| - Description of the issue | |
| - Suggested fix (with code snippet if small) | |
| ## Output format | |
| If issues found: | |
| ``` | |
| ## Code Review | |
| ### Critical | |
| - `path/to/file.py:42` β Description and fix | |
| ### High | |
| - `path/to/file.py:50` β Description and fix | |
| ### Medium | |
| - ... | |
| ``` | |
| If no issues: | |
| ``` | |
| ## Code Review | |
| No issues found. Checked for bugs, simplicity, DRY, and project conventions. | |
| ``` | |