m01-ownership

Diagnose Rust ownership and lifetime errors like E0382 and E0597.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/cecon123/tg-remote-bot --skill m01-ownership-cecon123
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: m01-ownership
Source: https://github.com/cecon123/tg-remote-bot/tree/main/.agents/skills/m01-ownership
Command: npx skills add https://github.com/cecon123/tg-remote-bot --skill m01-ownership-cecon123

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill helps developers resolve Rust ownership and borrowing issues by guiding reasoning around moves, borrows, and lifetimes, reducing compile-time errors and improving code safety.

Core Features & Use Cases

  • Comprehensive explanations of common ownership errors (E0382, E0597, E0506, E0507, E0515, E0716, E0106) and strategies to fix them.
  • Design patterns and decision guidance for ownership, borrowing, and lifetimes in Rust projects.
  • Real-world scenarios demonstrating how to structure code to satisfy borrow-checker constraints.

Quick Start

Analyze Rust code to identify ownership or lifetime issues and propose safe fixes using established patterns.

Frequently Asked Questions about m01-ownership

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix Rust borrow checker errors like E0382 and E0597?

Resolve Rust borrow checker errors like E0382 and E0597 by analyzing variable moves and borrows to apply established ownership patterns, ensuring references remain valid through correct lifetime constraints.

Why does Rust throw a borrow of moved value error and how do I resolve it?

Rust throws a borrow of moved value error when a variable is used after its ownership transfers. Resolve this by applying borrowing patterns or cloning data to prevent the original variable from invalidating.

How do I add lifetime annotations to fix Rust compiler error E0106?

Fix Rust compiler error E0106 by adding explicit lifetime annotations to struct definitions and function signatures, guiding the borrow checker to validate that input and output references share matching scopes.

What is the best way to structure Rust code to satisfy the borrow checker?

The best way to satisfy the Rust borrow checker is to apply established ownership and borrowing design patterns, reordering operations and scoping references to isolate mutable and immutable borrows during compile-time analysis.

How do I resolve cannot borrow as mutable because it is also borrowed as immutable errors?

Resolve cannot borrow as mutable errors by restructuring code to prevent overlapping mutable and immutable borrows, dropping immutable references before mutating or using scoped blocks to isolate borrow lifetimes.

What are common Rust lifetime constraints and when should I avoid complex lifetime annotations?

Common Rust lifetime constraints enforce reference validity scopes, but you should avoid complex lifetime annotations when simpler approaches like cloning data or restructuring ownership can satisfy the borrow checker without rigidly coupling scopes.