Claude Code Plugins

Community-maintained marketplace

Feedback

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.

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

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

  1. Identify target files: If the user specified files, use those. Otherwise, check git status for staged/modified files:

    git status --porcelain
    
  2. Run automated checks:

    • Format check: rustfmt --edition 2021 --check $(find . -name "*.rs" -not -path "./bazel-*")
    • Test suite: bazel test //...
  3. 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 mod directive anywhere (use pub use instead)
  • 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 miette for 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(), or Box usage
  • 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