| name | composable-move-functions |
| description | 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. |
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 . This makes them composable in PTBs — the caller decides what to do with the result.
