mcpbeat Sign in

M04 Zero Cost Agent Skill

CRITICAL: Use for generics, traits, zero-cost abstraction. Triggers: E0277, E0308, E0599, generic, trait, impl, dyn, where, monomorphization, static dispatch, dynamic dispatch, impl Trait, trait bound not satisfied, 泛型, 特征, 零成本抽象, 单态化

1.2k tokens
context cost
SKILL.md, read when the skill is used
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
108
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/moeru-ai/auv --skill m04-zero-cost

The instruction itself

13 sections, as written by the author

Zero-Cost Abstraction

> Layer 1: Language Mechanics

Core Question

Do we need compile-time or runtime polymorphism?

Before choosing between generics and trait objects:

  • Is the type known at compile time?
  • Is a heterogeneous collection needed?
  • What's the performance priority?

Error → Design Question

| Error | Don't Just Say | Ask Instead |

|-------|----------------|-------------|

| E0277 | "Add trait bound" | Is this abstraction at the right level? |

| E0308 | "Fix the type" | Should types be unified or distinct? |

| E0599 | "Import the trait" | Is the trait the right abstraction? |

| E0038 | "Make object-safe" | Do we really need dynamic dispatch? |


Thinking Prompt

Before adding trait bounds:

  • What abstraction is needed?
  • Same behavior, different types → trait
  • Different behavior, same type → enum
  • No abstraction needed → concrete type
  • When is type known?
  • Compile time → generics (static dispatch)
  • Runtime → trait objects (dynamic dispatch)
  • What's the trade-off priority?
  • Performance → generics
  • Compile time → trait objects
  • Flexibility → depends

Trace Up ↑

When type system fights back:

E0277 (trait bound not satisfied)
    ↑ Ask: Is the abstraction level correct?
    ↑ Check: m09-domain (what behavior is being abstracted?)
    ↑ Check: m05-type-driven (should use newtype?)

| Persistent Error | Trace To | Question |

|-----------------|----------|----------|

| Complex trait bounds | m09-domain | Is the abstraction right? |

| Object safety issues | m05-type-driven | Can typestate help? |

| Type explosion | m10-performance | Accept dyn overhead? |


Trace Down ↓

From design to implementation:

"Need to abstract over types with same behavior"
    ↓ Types known at compile time → impl Trait or generics
    ↓ Types determined at runtime → dyn Trait

"Need collection of different types"
    ↓ Closed set → enum
    ↓ Open set → Vec<Box<dyn Trait>>

"Need to return different types"
    ↓ Same type → impl Trait
    ↓ Different types → Box<dyn Trait>

Quick Reference

| Pattern | Dispatch | Code Size | Runtime Cost |

|---------|----------|-----------|--------------|

| fn foo<T: Trait>() | Static | +bloat | Zero |

| fn foo(x: &dyn Trait) | Dynamic | Minimal | vtable lookup |

| impl Trait return | Static | +bloat | Zero |

| Box<dyn Trait> | Dynamic | Minimal | Allocation + vtable |

Syntax Comparison

// Static dispatch - type known at compile time
fn process(x: impl Display) { }      // argument position
fn process<T: Display>(x: T) { }     // explicit generic
fn get() -> impl Display { }         // return position

// Dynamic dispatch - type determined at runtime
fn process(x: &dyn Display) { }      // reference
fn process(x: Box<dyn Display>) { }  // owned

Error Code Reference

| Error | Cause | Quick Fix |

|-------|-------|-----------|

| E0277 | Type doesn't impl trait | Add impl or change bound |

| E0308 | Type mismatch | Check generic params |

| E0599 | No method found | Import trait with use |

| E0038 | Trait not object-safe | Use generics or redesign |


Decision Guide

| Scenario | Choose | Why |

|----------|--------|-----|

| Performance critical | Generics | Zero runtime cost |

| Heterogeneous collection | dyn Trait | Different types at runtime |

| Plugin architecture | dyn Trait | Unknown types at compile |

| Reduce compile time | dyn Trait | Less monomorphization |

| Small, known type set | enum | No indirection |


Object Safety

A trait is object-safe if it:

  • Doesn't have Self: Sized bound
  • Doesn't return Self
  • Doesn't have generic methods
  • Uses where Self: Sized for non-object-safe methods

Anti-Patterns

| Anti-Pattern | Why Bad | Better |

|--------------|---------|--------|

| Over-generic everything | Compile time, complexity | Concrete types when possible |

| dyn for known types | Unnecessary indirection | Generics |

| Complex trait hierarchies | Hard to understand | Simpler design |

| Ignore object safety | Limits flexibility | Plan for dyn if needed |


| When | See |

|------|-----|

| Type-driven design | m05-type-driven |

| Domain abstraction | m09-domain |

| Performance concerns | m10-performance |

| Send/Sync bounds | m07-concurrency |

How to use it

Copy the folder

Take moeru-ai/m04-zero-cost from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.