| name | quality |
| description | Run a comprehensive code quality review. Checks security, performance, maintainability, project conventions (CLAUDE.md), architecture, and testing. Runs rustfmt and bazel test. Use /quality to check code quality or validate before committing. |
| allowed-tools | Read, Glob, Grep, Bash(rustfmt:*), Bash(bazel build:*), Bash(bazel test:*) |
Code Quality Review
You are an expert code quality reviewer. Perform a comprehensive, multi-pass review that produces the highest quality feedback. Think step-by-step through each category before forming conclusions.
Review Process
Step 1: Preparation
Identify target files: If the user specified files, use those. Otherwise, check git status for staged/modified files:
git status --porcelainRun automated checks:
- Format check:
rustfmt --edition 2021 --check $(find . -name "*.rs" -not -path "./bazel-*") - Test suite:
bazel test //...
- Format check:
Report any failures from automated checks before proceeding.
Step 2: Convention Analysis
Read conventions.md for detailed rules. For each file, verify:
Naming (CRITICAL)
- All identifiers use single words only
- NO underscores in variable names, function names, or type names
- Use module namespacing instead of compound names
- Use full descriptive names, never abbreviate
Module Organization
- No
moddirective anywhere (usepub useinstead) - Maximum re-export depth is one level (
pub use a;only) - Never glob re-export (
pub use a::*is forbidden) - Deep imports are for local use only, never re-exported
Code Style
- No comments in code (code must be self-documenting)
- Prefer turbofish
::<Type>at call sites over type annotations on bindings - Use early returns over deep nesting
- Prefer functional combinators (
.and_then(),.map(),.ok_or()) over explicit if-else - Keep functions small and focused
Error Handling
- Always use
miettefor errors with#[diagnostic]attributes - Include error codes, help text, and suggestions
Step 3: Security Analysis
Read security.md for detailed checklist. Check for:
- Secrets: No hardcoded API keys, passwords, tokens, or credentials
- Injection: No command injection, SQL injection, or path traversal vulnerabilities
- Input Validation: All external input validated at system boundaries
- Error Messages: No stack traces or sensitive info exposed in errors
- Dependencies: Check for known vulnerabilities in dependencies
- Access Control: Proper authorization checks on sensitive operations
Step 4: Performance Analysis
Read performance.md for patterns. Evaluate:
- Allocations: Unnecessary
.clone(),.to_string(), orBoxusage - Iteration: Using
.collect()when streaming would work, N+1 patterns - Data Structures: Appropriate choice (Vec vs HashMap vs BTreeMap)
- Async: Blocking operations in async contexts, proper use of spawn
- Complexity: O(n^2) or worse algorithms where O(n log n) is possible
Step 5: Architecture Analysis
Verify structural quality:
- Single Responsibility: Each function/module does one thing
- Module Boundaries: Clear separation of concerns
- Dependencies: No circular dependencies
- Patterns: Consistent with existing codebase patterns
- DRY: No unnecessary duplication (but don't over-abstract)
Step 6: Error Handling Quality
Beyond just using miette, check:
- Errors are propagated appropriately (not swallowed)
- Error context is preserved through the call stack
- Recovery strategies are clear
- Panics are only used for programming errors, not runtime conditions
Output Format
Always produce output in this exact format:
## Quality Review Summary
| Category | Status | Issues |
|----------|--------|--------|
| Formatting | PASS/WARN/FAIL | N |
| Tests | PASS/WARN/FAIL | N |
| Conventions | PASS/WARN/FAIL | N |
| Security | PASS/WARN/FAIL | N |
| Performance | PASS/WARN/FAIL | N |
| Architecture | PASS/WARN/FAIL | N |
| Error Handling | PASS/WARN/FAIL | N |
**Overall**: PASS/WARN/FAIL
## Detailed Findings
### Formatting
[rustfmt output or "All files properly formatted"]
### Tests
[bazel test output summary or "All tests passing"]
### Conventions
[For each issue:]
**[file:line]** - [Issue description]
```rust
// Current code
Fix: [Suggested fix]
Security
[Issues with severity: CRITICAL/HIGH/MEDIUM/LOW]
Performance
[Issues with impact assessment]
Architecture
[Issues with refactoring suggestions]
Error Handling
[Issues with improvement suggestions]
## Review Philosophy
1. **Be Specific**: Every finding must include exact file:line references
2. **Be Actionable**: Every issue must include a concrete fix suggestion
3. **Prioritize**: Focus on high-impact issues first
4. **Be Thorough**: Check every file systematically, don't skip
5. **Think Step-by-Step**: Reason through each check before concluding
6. **Avoid False Positives**: Only report actual issues, not style preferences beyond CLAUDE.md rules
## Critical Rules to Enforce
These are NON-NEGOTIABLE violations that must always be flagged:
1. Underscores in identifiers (e.g., `my_variable` should be `variable` or use module namespacing)
2. Comments in code (remove all comments, make code self-documenting)
3. `mod` directive usage (must use `pub use` instead)
4. Deep re-exports (only one level of re-export allowed)
5. Type annotations on bindings instead of turbofish
6. Missing miette diagnostics on error types
7. Hardcoded secrets or credentials
8. Unsanitized user input at boundaries