What this prompt does
This prompt turns the AI into a Rust borrow-checker tutor for a specific error rather than a general explainer. You paste your [code_snippet] and name the [error_type], and it explains in plain English what the borrow checker is actually complaining about, draws an ASCII ownership and lifetime diagram showing the conflict, and then gives [solution_count] different fixes ordered by idiomatic preference. Getting several ranked fixes, rather than the first one that happens to compile, is what keeps the resulting code clean instead of quietly papered over with clones and shared mutability.
The variables steer both depth and direction. [advanced_pattern] tells the AI which interior-mutability or shared-ownership tools to evaluate, such as Rc, Arc, RefCell, or Cow, and when each is genuinely appropriate, while [explanation_level] sets how much foundational ownership theory it includes for your background. Beyond the fixes themselves, it shows the memory-layout difference between solutions, gives a simplified mental model for this whole class of error, writes a test that verifies the fix, and lists patterns that avoid the error from the start.
When to use it
- Getting unstuck on a borrow-checker or lifetime error you genuinely cannot decode
- Learning why a fix works in ownership terms, not merely that it compiles
- Deciding whether Rc, Arc, RefCell, or Cow is the right tool for a specific case
- Building a durable mental model so the same error class stops recurring
- Comparing the memory and performance trade-offs of several valid fixes
- Generating a test that locks in the fix and prevents a later regression
Example output
You get a plain-English diagnosis of the error, an ASCII diagram of the ownership and lifetime conflict, and a ranked list of fixes from most to least idiomatic, each with an explanation grounded in ownership rules. It adds a memory-layout comparison between the solutions, guidance on whether an advanced pattern fits your case, a simplified mental model for the error, a verifying test, and prevention patterns, often with a pointer to the relevant Rust book chapter for deeper reading.
Pro tips
- Paste the full
[code_snippet]and the exact compiler message; partial context yields generic, often wrong advice - Set
[error_type]to the real error class so the diagnosis targets your actual conflict rather than a guess - Keep
[solution_count]around 3 so you see real alternatives without drowning in marginal variations - Set
[explanation_level]honestly; overstating your level skips the theory you may actually need to understand the fix - Be skeptical when it suggests
[advanced_pattern]like Rc<RefCell<T>>; often a borrow restructure is cleaner and cheaper - Run the generated test and confirm it actually fails before the fix, so it genuinely proves the change works