home / skills / raintree-technology / claude-starter / move-language

move-language skill

/skills/aptos/move-language

This skill helps you master Move language fundamentals for Aptos, including abilities, generics, references, and global storage patterns.

npx playbooks add skill raintree-technology/claude-starter --skill move-language

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.0 KB
---
name: aptos-move-language
description: Expert on Move programming language fundamentals including abilities (copy/drop/store/key), generics, phantom types, references, global storage operations (move_to/move_from/borrow_global), signer pattern, visibility modifiers, and advanced type system features.
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
license: MIT
metadata:
  author: raintree
  version: "1.0"
---

# Move Language Expert

Deep expertise on the Move programming language for Aptos blockchain.

## Triggers

- move language, abilities, generics
- phantom type, borrow_global
- signer, friend, inline
- copy, drop, store, key
- move_to, move_from, acquires

## Abilities

The four abilities control what can be done with types:

| Ability | Meaning | Use Case |
|---------|---------|----------|
| `copy` | Can be copied | Primitives, configs |
| `drop` | Can be discarded | Temporary data |
| `store` | Can be stored in structs | Most data types |
| `key` | Can be top-level resource | Account resources |

```move
struct Resource has key, store { value: u64 }
struct Point has copy, drop, store { x: u64, y: u64 }
struct Capability {}  // No abilities - hot potato
```

### Critical Rules

1. Fields must have compatible abilities
2. Structs without `drop` must be explicitly handled
3. `copy` requires all fields to have `copy`

## Generics

```move
struct Box<T: store> has store {
    value: T
}

public fun create<T: store>(value: T): Box<T> {
    Box { value }
}
```

### Phantom Types (Zero-Cost Type Safety)

```move
struct Coin<phantom CoinType> has store {
    value: u64  // CoinType doesn't appear here
}

struct BTC {}
struct ETH {}

// Coin<BTC> != Coin<ETH> at compile time
```

## References

```move
// Immutable reference
fun read(x: &u64): u64 { *x }

// Mutable reference
fun increment(x: &mut u64) { *x = *x + 1; }
```

### Reference Rules

- Can't have mutable + immutable refs simultaneously
- Only one mutable reference at a time
- References can't outlive values

## Global Storage

```move
// Store resource
move_to(account, MyResource { value: 0 });

// Remove resource
let resource = move_from<MyResource>(addr);

// Immutable borrow
let r = borrow_global<MyResource>(addr);

// Mutable borrow
let r = borrow_global_mut<MyResource>(addr);

// Check existence
exists<MyResource>(addr);
```

### The `acquires` Annotation

```move
public fun get_value(addr: address): u64 acquires MyResource {
    borrow_global<MyResource>(addr).value
}
```

## Signer

`signer` is Move's authentication primitive:

```move
public entry fun initialize(account: &signer) {
    move_to(account, Resource { value: 0 });
}

let addr = signer::address_of(account);
```

## Visibility

```move
fun private_fn() { }                    // Module only
public fun public_fn() { }              // Anywhere
public(friend) fun friend_fn() { }      // Friends only
public entry fun entry_fn(s: &signer) { }  // Transaction entry
entry fun local_entry(s: &signer) { }   // Local entry
```

### Friend Declarations

```move
module admin {
    friend user_module;
    public(friend) fun admin_function() { }
}
```

## Inline Functions

```move
inline fun min(a: u64, b: u64): u64 {
    if (a < b) a else b
}
```

## Common Patterns

### Capability Pattern

```move
struct AdminCap has key, store {}

public fun admin_only(admin: &signer) acquires AdminCap {
    assert!(exists<AdminCap>(signer::address_of(admin)), ERROR);
}
```

### Witness Pattern

```move
struct MyModule has drop {}

public fun initialize<T: drop>(account: &signer, _witness: T) {
    move_to(account, Config<T> { });
}
```

### Hot Potato Pattern

```move
struct Receipt { amount: u64 }  // No abilities!

public fun buy(): Receipt { Receipt { amount: 100 } }
public fun redeem(r: Receipt) { let Receipt { amount } = r; }
// Must call both - can't drop Receipt
```

## Best Practices

- Use abilities explicitly
- Leverage phantom types for type safety
- Constrain generics only as needed
- Use references to avoid copies
- Check exists before borrow_global
- Always annotate acquires

Overview

This skill is an expert guide to the Move programming language fundamentals used on Aptos. It explains abilities (copy/drop/store/key), generics, phantom types, references, global storage operations, signer patterns, visibility modifiers, and advanced type-system features with practical patterns and pitfalls.

How this skill works

The skill inspects Move code patterns and explains what each construct allows or forbids, focusing on compile-time guarantees driven by abilities and type constraints. It breaks down how generics, phantom types, and references interact with resource semantics and shows correct usage of global storage operations like move_to, move_from, borrow_global, and the acquires annotation. It also covers signer handling, visibility rules, friend modules, and inline functions.

When to use it

  • Designing resource-bearing structs and deciding abilities for safety and storage
  • Implementing generic modules and using phantom types for zero-cost type safety
  • Managing global account resources with move_to/move_from and borrow_global
  • Writing transaction entry points that require signer authentication
  • Applying friend visibility or inline functions for module-level control

Best practices

  • Declare abilities explicitly and ensure all fields meet ability constraints
  • Constrain generics only to the abilities you need (e.g., T: store)
  • Use phantom types to distinguish logically different token types at compile time
  • Prefer references to avoid unnecessary copies and respect borrow rules
  • Always check exists before borrow_global and annotate functions with acquires
  • Use signer for authentication and move resources through move_to/move_from

Example use cases

  • Define an account Resource struct with has key to store per-account state
  • Create a generic Box<T: store> wrapper and constructors for reusable storage types
  • Enforce asset type safety with Coin<phantom BTC> vs Coin<phantom ETH>
  • Implement admin capabilities via a key-bearing AdminCap and acquires checks
  • Write entry functions that initialize resources using &signer and move_to

FAQ

What do abilities control?

Abilities control compile-time permissions: copy allows duplication, drop allows disposal, store allows inclusion in structs, and key allows a type to be a top-level resource.

When should I use phantom types?

Use phantom types to enforce compile-time distinctions between logically different types (like token kinds) without runtime cost when the phantom type does not appear in storage.