m01-ownership_skill

This skill helps you diagnose and resolve Rust ownership and lifetime errors by guiding design decisions and refactoring strategies.
  • Shell

565

GitHub Stars

2

Bundled Files

3 weeks ago

Catalog Refreshed

2 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstart where the catalogue uses aiagentskills.

npx veilstart add skill zhanghandong/rust-skills --skill m01-ownership

  • comparison.md5.6 KB
  • SKILL.md4.1 KB

Overview

This skill focuses on diagnosing and resolving Rust ownership, borrowing, and lifetime issues. It targets common compiler errors like moved value, borrowed value does not live long enough, cannot move out of, use of moved value, and lifetime annotation problems. Use it when you need concrete guidance on whether to move, borrow, clone, or redesign ownership.

How this skill works

The skill inspects the error code and the surrounding code intent to map the compiler message to design questions: who should own the data, how long it must live, and whether it should be shared or exclusive. It suggests targeted remedies (references, cloning, smart pointers, lifetime annotations, or API redesign) and traces persistent failures to higher-level design decisions or adjacent skills like resource sharing and mutability. It provides quick pattern references and anti-pattern warnings to avoid repeated fixes that mask design issues.

When to use it

  • When you see errors E0382, E0597, E0506, E0507, E0515, E0716, or E0106
  • When value moved or use of moved value appears in compilation
  • When borrowed value does not live long enough or you need to return references
  • When deciding between move, borrow, clone, Rc/Arc, or Cow
  • When repeated fixes indicate a design-level ownership problem

Best practices

  • Ask who should own the data and for how long before applying a fix
  • Prefer redesign (API or scope) over cloning everywhere to avoid hidden costs
  • Use &T for read-only, &mut T for temporary exclusive access, and owned types for returned or long-lived data
  • Choose Rc/Arc for shared ownership and Cow for conditional clone-on-write
  • Trace persistent errors up to domain/resource/mutability choices rather than patching locally

Example use cases

  • Fixing E0382 by deciding whether to move ownership or use a reference/Arc for shared reuse
  • Resolving E0597 by extending the owner scope or returning an owned value instead of a reference
  • Handling E0506/E0507 by restructuring code to end borrows before mutation or cloning when appropriate
  • Addressing E0515 by changing function signatures to return owned data instead of references
  • Eliminating transient lifetime issues (E0716/E0106) by binding temporaries or adding accurate lifetime annotations

FAQ

Clone when values are cheap and truly independent; use Rc/Arc when multiple parts must share the same allocation without copying, choosing Arc for multi-threaded contexts.

Is adding 'static a safe lifetime shortcut?

No—'static often hides design problems and reduces flexibility. Prefer precise lifetimes or owned types that reflect actual data scope.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational