Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
181 changes: 181 additions & 0 deletions .claude/skills/rust-production-readiness/CHECKLIST.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,181 @@
# Rust Production Readiness Checklist

Detailed checklist for manual code review. Use alongside automated tooling.

## 1. Error Handling

### Critical
- [ ] No `unwrap()` on user input or external data
- [ ] No `unwrap()` on network responses
- [ ] No `expect()` with generic messages in production paths

### High
- [ ] `Result` types propagated with `?` or explicitly handled
- [ ] Error types carry context (not just `Box<dyn Error>` or `String`)
- [ ] Errors logged before being converted/wrapped

### Patterns to find
```bash
# Find unwrap/expect in non-test code
rg "\.unwrap\(\)" --type rust -g '!*test*' -g '!*tests*'
rg "\.expect\(" --type rust -g '!*test*' -g '!*tests*'
```

## 2. Panic Vectors

### Critical
- [ ] No `panic!()` in library code
- [ ] No `unreachable!()` that could actually be reached
- [ ] No `todo!()` or `unimplemented!()` in shipped code

### High
- [ ] Array/slice indexing bounds-checked or using `.get()`
- [ ] Integer arithmetic checked for overflow in release builds
- [ ] No `assert!()` for runtime conditions (use `Result` instead)

### Patterns to find
```bash
rg "panic!\(|todo!\(|unimplemented!\(|unreachable!\(" --type rust -g '!*test*'
rg "\[.*\]" --type rust # Manual review for unchecked indexing
```

## 3. Unsafe Code

### Critical
- [ ] All `unsafe` blocks have `// SAFETY:` comments explaining invariants
- [ ] FFI boundaries validated (null checks, length checks)
- [ ] No undefined behavior (aliasing, uninitialized memory)

### High
- [ ] Unsafe code minimized and isolated
- [ ] Raw pointer lifetimes clearly bounded
- [ ] Transmutes justified and correct

### Patterns to find
```bash
rg "unsafe\s*\{" --type rust
rg "transmute" --type rust
```

## 4. Async & Concurrency

### Critical
- [ ] No `Mutex` held across `.await` points
- [ ] No blocking calls (std::fs, std::net) in async context
- [ ] Deadlock-free lock ordering

### High
- [ ] Timeouts on all network operations
- [ ] Cancellation handled gracefully
- [ ] No unbounded channel/queue growth

### Medium
- [ ] `Send + Sync` bounds explicit where needed
- [ ] Spawned tasks tracked or explicitly detached

### Patterns to find
```bash
rg "\.lock\(\)" --type rust -A 5 # Check if .await follows
rg "std::fs::|std::net::" --type rust # Blocking in async?
```

## 5. Memory & Performance

### High
- [ ] No unbounded `Vec::push` in loops without pre-allocation
- [ ] No string concatenation in hot loops (use `String::with_capacity` or `format!`)
- [ ] Large structs passed by reference, not value
- [ ] No excessive `.clone()` on large types

### Medium
- [ ] `Box` used for large stack allocations
- [ ] Iterators preferred over collecting into intermediate `Vec`s
- [ ] `Cow` used where ownership is conditional

### Patterns to find
```bash
rg "\.clone\(\)" --type rust # Review each for necessity
rg "\.collect::<Vec" --type rust # Could this stay as iterator?
```

## 6. Dependencies

### Critical
- [ ] `cargo audit` shows no vulnerabilities
- [ ] No yanked crates in dependency tree
- [ ] Crypto dependencies from reputable sources

### High
- [ ] Dependency versions pinned or bounded appropriately
- [ ] No unnecessary dependencies
- [ ] Feature flags minimize compiled code

### Commands
```bash
cargo audit
cargo tree --duplicates # Check for version conflicts
cargo deny check # If cargo-deny configured
```

## 7. API & Documentation

### High
- [ ] Public API has doc comments
- [ ] Error conditions documented
- [ ] Panics documented (if any exist intentionally)
- [ ] Examples compile (`cargo test --doc`)

### Medium
- [ ] `#[must_use]` on functions returning important values
- [ ] `#[non_exhaustive]` on public enums that may grow
- [ ] Breaking changes noted in changelog

## 8. Testing

### High
- [ ] Unit tests for core logic
- [ ] Integration tests for public API
- [ ] Error paths tested, not just happy path

### Medium
- [ ] Edge cases covered (empty input, max values, unicode)
- [ ] Async tests use appropriate runtime
- [ ] Mocks/fakes for external services

### Commands
```bash
cargo test --all-features
cargo tarpaulin # Coverage if available
```

## 9. Configuration & Environment

### Critical
- [ ] No hardcoded secrets or API keys
- [ ] Secrets loaded from environment or secure storage
- [ ] No `println!` debug output in production code

### High
- [ ] Configuration validated at startup
- [ ] Sensible defaults for optional config
- [ ] Feature flags documented

### Patterns to find
```bash
rg "println!\(|dbg!\(" --type rust -g '!*test*'
rg "HARDCODED|TODO|FIXME|XXX" --type rust
```

## 10. Build & Release

### High
- [ ] `cargo build --release` succeeds
- [ ] No compiler warnings with `-D warnings`
- [ ] MSRV (minimum supported Rust version) documented and tested
- [ ] Cross-compilation targets build (if applicable)

### Commands
```bash
cargo build --release --all-features
cargo clippy --all-targets --all-features -- -D warnings
```
137 changes: 137 additions & 0 deletions .claude/skills/rust-production-readiness/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
---
name: rust-production-readiness
description: Audits Rust code for production readiness. Use when preparing Rust code for release, reviewing PRs before merge, or assessing code quality before shipping to production.
---

# Rust Production Readiness Audit

## Goal
Systematically evaluate Rust code against production-readiness criteria and produce an actionable report with findings and recommendations.

## When to use
- Before merging a PR to main
- Before cutting a release
- When onboarding to assess codebase health
- After major refactoring

## When not to use
- For prototype/experimental code
- For test-only code review
- When you just need a quick syntax check (use `cargo check` instead)

## Inputs
- Rust codebase (current directory or specified path)
- Optional: specific files/modules to focus on

## Outputs
- Structured audit report with severity ratings
- Specific file:line references for issues
- Recommended fixes

## Default workflow

1) **Gather context**
- Read `Cargo.toml` for dependencies and features
- Check for `CLAUDE.md` or project-specific conventions
- Identify the crate type (library, binary, FFI)

2) **Run automated checks**
```bash
cargo clippy --all-targets --all-features -- -D warnings
cargo audit
cargo test --all-features
```

3) **Manual code review** (see CHECKLIST.md for details)
- Error handling patterns
- Panic vectors
- Unsafe code
- Async pitfalls
- Performance concerns

4) **Generate report**
- Group findings by severity (Critical/High/Medium/Low)
- Include file:line references
- Provide fix recommendations

## Severity definitions

| Severity | Criteria |
|----------|----------|
| Critical | Can cause crashes, data loss, or security vulnerabilities in production |
| High | Likely to cause issues under load or edge cases |
| Medium | Code smell or maintainability concern |
| Low | Style or minor improvement suggestion |

## Quick checklist (detailed version in CHECKLIST.md)

- [ ] No `unwrap()` or `expect()` in non-test code paths
- [ ] All `Result` types handled or explicitly propagated
- [ ] No `panic!` in library code
- [ ] `unsafe` blocks documented with safety invariants
- [ ] Async code avoids holding locks across `.await`
- [ ] No unbounded allocations (Vec growth, string concat in loops)
- [ ] Dependencies audited (`cargo audit` clean)
- [ ] Public API documented
- [ ] Error types are meaningful (not just `String`)

## Report template

```markdown
# Rust Production Readiness Report

**Crate:** {name}
**Version:** {version}
**Date:** {date}

## Summary
- Critical: {n}
- High: {n}
- Medium: {n}
- Low: {n}

## Automated checks
- [ ] `cargo clippy`: {PASS/FAIL}
- [ ] `cargo audit`: {PASS/FAIL}
- [ ] `cargo test`: {PASS/FAIL}

## Findings

### Critical
{findings or "None"}

### High
{findings or "None"}

### Medium
{findings or "None"}

### Low
{findings or "None"}

## Recommendations
{prioritized action items}
```

## Examples

### Example 1: Focused module audit
**Input:** "Check the `src/account_client/` module for production readiness"
**Output:** Report focused on that module with findings like:
- `src/account_client/mod.rs:142` - `unwrap()` on user input parsing (Critical)
- `src/account_client/retry.rs:58` - Unbounded retry loop (High)

### Example 2: Pre-release full audit
**Input:** "/rust-production-readiness"
**Output:** Full crate audit with all checks run, summary statistics, and prioritized fix list.

## Evaluation prompts

1. **Activation test:** "Review this Rust code for production readiness before we ship"
- Should trigger this skill

2. **Non-activation test:** "Help me write a new function to parse JSON"
- Should NOT trigger (this is feature development, not audit)

3. **Edge case:** "Is this Rust code ready for prod?" (no specific files mentioned)
- Should trigger, audit entire crate in current directory