- Home
- Skills
- Copyleftdev
- Sk1llz
- Matsakis
matsakis_skill
- Python
3
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 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 veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill copyleftdev/sk1llz --skill matsakis- SKILL.md6.8 KB
Overview
This skill writes Rust code in the style of Niko Matsakis, emphasizing ownership, lifetimes, and the borrow checker as a design tool. It guides API design and refactors to respect Rust's capability-based mental model, producing clear, idiomatic solutions for complex lifetime scenarios. Use it to get code and explanations that prioritize correctness, clarity, and minimal annotations.
How this skill works
The skill inspects function signatures, struct layouts, and borrow patterns to suggest edits that align with Matsakis' principles: trust the borrow checker, treat lifetimes as relationships, and minimize explicit annotations. It proposes concrete refactorings (e.g., split borrows, return owned values, use indices instead of self-references) and explains why each change satisfies the borrow checker's requirements. It can output code examples, lifetime reasoning, and a sequence of debugging questions to apply when the checker rejects code.
When to use it
- Designing APIs that expose ownership or borrow semantics
- Resolving complex lifetime errors and borrow-checker rejections
- Refactoring structs to avoid self-references or to enable split borrows
- Choosing between owned types, references, and interior mutability
- Writing generic code with lifetime bounds or HRTBs
Best practices
- Ask the borrow-checker debugging questions before patching errors
- Prefer elision and avoid unnecessary lifetime annotations
- Design structs to own data where appropriate; use references for parameters
- Split borrows of composite structures instead of cloning or using runtime checks
- Use interior mutability only when shared ownership or trait constraints require it
Example use cases
- Refactor a function that holds a reference while mutating its container into a two-step collection-and-modify pattern
- Turn a self-referential struct into an index-based layout or advise Pin/ouroboros for advanced cases
- Rewrite APIs to return owned values when lifetimes would otherwise force awkward bounds
- Introduce split borrows for struct fields to enable concurrent mutable access to disjoint parts
- Suggest HRTBs for callback APIs that must accept references with arbitrary lifetimes
FAQ
No. It avoids applying 'static or unnecessary clones as fixes and instead recommends redesigns or correct lifetime relationships.
When should I use RefCell or Rc instead of &mut?
Only when shared ownership or trait/object safety makes &mut impossible. The skill prefers &mut and shows when interior mutability is an appropriate last resort.