rust-borrow-checker

caioniehues's avatarfrom caioniehues

Debug Rust ownership, borrowing, and lifetime errors. Use when encountering borrow checker errors (E0382, E0502, E0597, etc.) or when code won't compile due to ownership issues.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 23, 2025
[Debugging]

When & Why to Use This Skill

This Claude skill is a specialized assistant for Rust developers designed to diagnose and resolve complex borrow checker errors. It provides expert guidance on ownership, borrowing rules, and lifetime annotations, helping users fix common compiler errors like E0382, E0502, and E0597 while ensuring memory safety and optimal code performance.

Use Cases

  • Diagnosing and fixing 'use of moved value' (E0382) errors by suggesting cloning, referencing, or code restructuring.
  • Resolving mutable and immutable borrow conflicts (E0502) through scope separation or interior mutability patterns like RefCell.
  • Correcting lifetime annotation issues (E0597) to ensure references remain valid throughout their intended usage.
  • Providing step-by-step workflows to understand and solve specific Rust compiler error codes (E0499, E0506, etc.) to pass cargo check.
namerust-borrow-checker
descriptionDebug Rust ownership, borrowing, and lifetime errors. Use when encountering borrow checker errors (E0382, E0502, E0597, etc.) or when code won't compile due to ownership issues.
The Rust borrow checker enforces memory safety at compile time through three rules:
  1. Each value has exactly one owner - When the owner goes out of scope, the value is dropped
  2. You can have either one mutable reference OR any number of immutable references - Never both simultaneously
  3. References must always be valid - No dangling references, lifetimes must be sufficient

Understanding these rules is the key to fixing borrow checker errors.

What would you like help with?
  1. Diagnose a borrow checker error (paste the error)
  2. Fix a lifetime annotation issue
  3. Fix an ownership transfer problem
  4. Fix a mutable/immutable borrow conflict
  5. Understand a specific error code

Paste the compiler error or describe the issue, then I'll route to the appropriate workflow.

| Response | Workflow | |----------|----------| | Error message pasted, "diagnose", "error", "E0XXX" | `workflows/diagnose-error.md` | | "lifetime", "'a", "outlives", "E0597", "E0621" | `workflows/fix-lifetime.md` | | "move", "moved", "ownership", "E0382", "E0507" | `workflows/fix-ownership.md` | | "borrow", "mutable", "immutable", "E0502", "E0499" | `workflows/fix-borrowing.md` | | Other | Clarify, then select appropriate workflow | Common solutions for frequent errors:

E0382 (use of moved value): Clone, use references, or restructure to avoid the move E0502 (cannot borrow as mutable, already borrowed as immutable): Separate the borrows into different scopes, or use interior mutability (RefCell, Mutex) E0499 (cannot borrow as mutable more than once): Split into separate scopes or use indices instead of references E0597 (borrowed value does not live long enough): Extend the lifetime of the owner, or use owned types instead E0506 (cannot assign, already borrowed): Complete borrow before assignment, or use Cell/RefCell

Domain knowledge in `references/`:

Core Rules:

  • ownership-rules.md - The three ownership rules with examples
  • borrowing-rules.md - Borrowing and reference rules
  • lifetime-syntax.md - Lifetime annotation patterns and elision

Problem Solving:

  • common-errors.md - Detailed breakdown of E0XXX errors
  • patterns.md - Clone, Rc, Arc, RefCell, Cow patterns
| Workflow | Purpose | |----------|---------| | diagnose-error.md | Systematically diagnose any borrow checker error | | fix-lifetime.md | Resolve lifetime annotation issues | | fix-ownership.md | Fix ownership transfer problems | | fix-borrowing.md | Handle borrow conflicts | A fix is complete when: - `cargo check` passes without borrow checker errors - The solution doesn't introduce unnecessary cloning - The fix maintains the original intent of the code - Lifetimes are as simple as possible (rely on elision when possible)