agentleFS
MystenLabsMystenLabs/skills/composable-move-functions/SKILL.md

composable-move-functions

Skill20 starsChanged 15 days agoApache-2.0View on GitHub

Use when writing Move functions on Sui, especially public APIs. Applies to function visibility (public vs entry), parameter ordering, and return patterns. Use whenever designing function signatures or deciding whether functions should transfer objects or return them.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    All patterns sourced from https://move-book.com/guides/code-quality-checklist

    line 14
  2. Very specific:

    When to use entry: Only for convenience endpoints that are intentionally non-composable — functions that wrap a composable public …

    line 31
  3. Very specific:

    If the function is called frequently from the CLI, consider providing a companion entry wrapper that transfers internally (as shown above).

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

composable-move-functions

MCP tool: When available in your environment, also query the Sui documentation MCP server (https://sui.mcp.kapa.ai) for up-to-date answers. Use it for verification and for details not covered by these reference files.

Overview

Sui transactions can chain multiple function calls in a single Programmable Transaction Block (PTB). Functions that transfer objects internally instead of returning them break this composability. This skill covers how to design functions that work well in PTBs.

All patterns sourced from https://move-book.com/guides/code-quality-checklist

No public entry

Functions should be either public (composable, can be called from other modules and PTBs) or entry (transaction endpoint only). Never use public entry together.

// WRONG — public entry is redundant and limits composability
public entry fun do_something() { }

// CORRECT — public for composable functions that return values
public fun mint(ctx: &mut TxContext): NFT { }

// CORRECT — entry for intentionally non-composable endpoints
entry fun mint_and_keep(ctx: &mut TxContext) { }

When to use entry: Only for convenience endpoints that are intentionally non-composable — functions that wrap a composable public function and handle transfers to sender.

Return Objects, Don't Transfer Internally

Public functions should return values to the caller rather than transferring them to ctx.sender(). This makes them composable in PTBs — the caller decides what to do with the result.

// WRONG — couples minting with transfer, can't compose
public fun mint_and_transfer(ctx: &mut TxContext) {
    let nft = NFT { id: object::new(ctx) };
    transfer::transfer(nft, ctx.sender());
}

// CORRECT — returns the object, caller decides
public fun mint(ctx: &mut TxContext): NFT {
    NFT { id: object::new(ctx) }
}

// If you need a convenience entry point, add a separate entry wrapper:
entry fun mint_and_keep(ctx: &mut TxContext) {
    let nft = mint(ctx);
    transfer::transfer(nft, ctx.sender());
}

CLI implication for returned values

Functions that return non-drop values cannot be invoked via sui client call — the CLI has no way to consume the returned value, causing an UnusedValueWithoutDrop error. Use sui client ptb instead, where you can chain --assign and --transfer-objects to handle the return value:

sui client ptb \
  --move-call @pkg::module::create_thing --assign thing \
  --transfer-objects "[thing]" @sender

If the function is called frequently from the CLI, consider providing a companion entry wrapper that transfers internally (as shown above).

This applies broadly:

  • add_liquidity should return LP coins and remainder coins, not transfer them
  • remove_liquidity should return both coins, not transfer them
  • swap should return the output coin, not transfer it
  • borrow should return the borrowed asset, not transfer it

Parameter Ordering

Function parameters follow a strict order:

  1. Objects first — the primary object being acted on
  2. Capabilities second — authorization tokens like AdminCap
  3. Primitive values — amounts, flags, addresses
  4. Clock — always at the end (before ctx), exception to objects-first rule
  5. ctx: &mut TxContext last — ALWAYS the final parameter, after all primitives and all other arguments
// WRONG — cap before object, primitives mixed in
public fun authorize_action(
    cap: &AdminCap,
    value: u8,
    app: &mut App,
    ctx: &mut TxContext,
) { }

// CORRECT — object first, cap second, primitives third, ctx last
public fun authorize_action(
    app: &mut App,
    cap: &AdminCap,
    value: u8,
    ctx: &mut TxContext,
) { }

Clock Exception

Clock goes near the end, just before ctx, even though it's an object:

public fun timed_action(
    app: &mut App,
    cap: &AppCap,
    value: u8,
    clock: &Clock,
    ctx: &mut TxContext,
) { }

Quick Reference

PatternRule
Visibilitypublic for composable, entry for endpoints. Never public entry.
ReturnsPublic functions return objects. Don't transfer to sender internally.
Entry wrappersSeparate entry function that calls public function + transfers.
Param orderObject → Capability → Primitives → Clock → TxContext

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.