mirror of
https://github.com/browseros-ai/BrowserOS.git
synced 2026-05-17 02:25:57 +00:00
feat: browseros review slash command and complexity warning (#175)
* fix: add biome complexity lint * fix: browseros-review slash command
This commit is contained in:
176
.claude/commands/browseros-review.md
Normal file
176
.claude/commands/browseros-review.md
Normal file
@@ -0,0 +1,176 @@
|
||||
# BrowserOS Code Review
|
||||
|
||||
You are a code review specialist. Identify genuine issues while filtering out false positives.
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **High Signal Only**: Flag only issues you are certain about
|
||||
- **Objective Over Subjective**: Focus on bugs, security, explicit CLAUDE.md violations
|
||||
- **Validate Everything**: Every issue must be validated before reporting
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Determine Review Scope
|
||||
|
||||
**If argument provided** (e.g., `$ARGUMENTS` is a PR number): Proceed with PR review.
|
||||
|
||||
**If no argument provided**: Ask the user ONE question with TWO options:
|
||||
1. **PR Review** - then ask for PR number in follow-up
|
||||
2. **Branch Diff** - proceed immediately (no follow-up needed)
|
||||
|
||||
**For PR review:**
|
||||
```bash
|
||||
gh pr view <PR_NUMBER> --json title,body,files,baseRefName,headRefName
|
||||
gh pr diff <PR_NUMBER>
|
||||
```
|
||||
|
||||
**For branch diff (changes since fork point, not current main):**
|
||||
```bash
|
||||
# Find where branch forked from main
|
||||
MERGE_BASE=$(git merge-base main HEAD)
|
||||
git diff $MERGE_BASE HEAD
|
||||
git log $MERGE_BASE..HEAD --oneline
|
||||
```
|
||||
|
||||
### Step 2: Gather Context
|
||||
|
||||
- Read root CLAUDE.md
|
||||
- Read CLAUDE.md files in directories containing modified files
|
||||
- Understand the intent from commit messages or PR description
|
||||
|
||||
### Step 3: Review for Issues
|
||||
|
||||
Scan the diff for:
|
||||
|
||||
**Logic Errors**
|
||||
- Off-by-one in loops, slices, array access
|
||||
- Incorrect boolean logic (missing negation, wrong operator)
|
||||
- Missing edge cases: empty arrays, null/undefined, zero, negative
|
||||
- Incorrect equality checks (== vs ===, reference vs value)
|
||||
|
||||
**Async Errors**
|
||||
- Missing await on async calls
|
||||
- Unhandled promise rejections
|
||||
- Race conditions in shared state
|
||||
- Async in loops without proper batching
|
||||
|
||||
**Resource/Memory**
|
||||
- Unclosed connections, streams, handles
|
||||
- Event listeners not removed on cleanup
|
||||
- Missing finally/cleanup in error paths
|
||||
|
||||
**Type Safety (TypeScript)**
|
||||
- **Untyped functions**: Function parameters or return types using `any` instead of proper types
|
||||
- **Inline `any` casts**: Callbacks like `(x: any) => ...` that bypass type checking
|
||||
- **Missing interfaces for external data**: JSON parsing, API responses, or third-party data without defined types (create interfaces even for complex/nested structures)
|
||||
- Non-null assertions (!) without validation
|
||||
- Type narrowing lost across async boundaries
|
||||
|
||||
**Security**
|
||||
- String concatenation in SQL/commands (injection)
|
||||
- User input in innerHTML/dangerouslySetInnerHTML (XSS)
|
||||
- Secrets in code or logs
|
||||
- Missing input validation at boundaries
|
||||
|
||||
**CLAUDE.md Compliance**
|
||||
- Violations of rules in CLAUDE.md files
|
||||
- Quote the exact rule being broken
|
||||
|
||||
### Step 4: Check Design Principles
|
||||
|
||||
Flag clear violations of:
|
||||
- **SRP**: Class/module doing multiple unrelated things
|
||||
- **DRY**: Duplicated logic that should be extracted
|
||||
- **Separation of Concerns**: Business logic mixed with data access/UI/transport
|
||||
- **KISS**: Unnecessary complexity, over-abstraction
|
||||
- **YAGNI**: Unused features, speculative generalization
|
||||
|
||||
### Step 5: Check Code Readability
|
||||
|
||||
Flag these issues:
|
||||
- Functions over 100 lines
|
||||
- Nesting depth > 3 levels
|
||||
- Unclear names requiring mental mapping
|
||||
- Magic numbers/strings without named constants
|
||||
- God objects/files doing too many things
|
||||
|
||||
### Step 6: Suggest Design Patterns (MEDIUM PRIORITY)
|
||||
|
||||
When code would clearly benefit, suggest these patterns:
|
||||
|
||||
- **Factory**: Scattered/duplicated object creation → centralize with factory
|
||||
- **Builder**: Constructor with 4+ params or complex setup → step-by-step builder
|
||||
- **Strategy**: Multiple if/else chains selecting behavior → interchangeable strategies
|
||||
- **Decorator**: Need to add behavior dynamically → wrap objects with decorators
|
||||
- **Observer**: Objects need to react to state changes → pub/sub notification
|
||||
- **Repository**: Data access mixed with business logic → abstract data layer
|
||||
- **Singleton**: Need exactly one instance → controlled single instance
|
||||
- **Adapter**: Incompatible interfaces → wrapper to make compatible
|
||||
- **Dependency Injection**: Hard-coded dependencies → inject via constructor
|
||||
- **MVC**: Mixed data/UI/logic → separate model, view, controller
|
||||
|
||||
Only suggest when the pattern clearly solves an existing problem in the code. Don't suggest patterns speculatively.
|
||||
|
||||
## DO NOT Flag (False Positives)
|
||||
|
||||
- Pre-existing issues not introduced in this diff
|
||||
- Correct code that appears buggy without context
|
||||
- Pedantic nitpicks a senior engineer wouldn't flag
|
||||
- Issues a linter will catch (Biome handles these)
|
||||
- Issues silenced in code (lint ignore comments)
|
||||
- Subjective suggestions or "might be" problems
|
||||
- Style preferences not explicitly in CLAUDE.md
|
||||
- General quality concerns unless explicitly in CLAUDE.md
|
||||
|
||||
## Link Format
|
||||
|
||||
When citing code, use full git SHA:
|
||||
```
|
||||
https://github.com/{owner}/{repo}/blob/{full_git_sha}/{path}#L{start}-L{end}
|
||||
```
|
||||
|
||||
## Comment Guidelines
|
||||
|
||||
- One comment per unique issue
|
||||
- For fixes under 5 lines: include committable suggestion block
|
||||
- For fixes 6+ lines: provide high-level guidance + copyable prompt
|
||||
- Never include fixes that would break without additional changes
|
||||
|
||||
## Output Format
|
||||
|
||||
After reviewing, output a concise summary:
|
||||
|
||||
```
|
||||
## Code Review Summary
|
||||
|
||||
**Scope**: [PR #123 / Branch `feat/xyz` vs main]
|
||||
**Files reviewed**: [count]
|
||||
|
||||
### Issues Found
|
||||
|
||||
For each issue:
|
||||
- **[SEVERITY]** `file:line` - Brief description
|
||||
- Why it's a problem
|
||||
- Suggested fix (or copyable prompt: `Fix file:line: description`)
|
||||
|
||||
### Concise Action Items
|
||||
|
||||
🔴 HIGH PRIORITY:
|
||||
□ [Critical bugs, security issues, data loss risks]
|
||||
|
||||
🟡 MEDIUM PRIORITY:
|
||||
□ [Design improvements, testability issues]
|
||||
|
||||
🔵 LOW PRIORITY:
|
||||
□ [Refactoring suggestions, minor improvements]
|
||||
```
|
||||
|
||||
If no issues found, output:
|
||||
```
|
||||
## Code Review Summary
|
||||
|
||||
**Scope**: [PR #123 / Branch vs main]
|
||||
**Files reviewed**: [count]
|
||||
|
||||
No issues found. Code looks good.
|
||||
```
|
||||
@@ -23,6 +23,14 @@
|
||||
},
|
||||
"nursery": {
|
||||
"useSortedClasses": "error"
|
||||
},
|
||||
"complexity": {
|
||||
"noExcessiveCognitiveComplexity": {
|
||||
"level": "warn",
|
||||
"options": {
|
||||
"maxAllowedComplexity": 30
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
|
||||
Reference in New Issue
Block a user