agentsclimarketplace

Sui move setup

Skill widnyana/eyay-toolkits/plugins/sui-dev-tools/skills/sui-move-setup

Agents don’t behave, they swarm. Skills and plugins slot in mid flight, and somehow the whole thing is a mess

Install
npx -y skills add widnyana/eyay-toolkits --skill sui-move-setup

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Move package setup (Move.toml, edition, dependencies), building, testing, and common pitfalls from other Move dialects.

SKILL.md

5.4 KB, as published. Nobody here has run it

1. Package Setup

Always use the Move 2024 edition (edition = "2024" in Move.toml). The name in [package] defines the package's address name and must match what the Move code uses (e.g., module my_package::m requires name = "my_package"):

[package]
name = "my_package"
edition = "2024"

Implicit framework dependencies (Sui 1.45+) — do not list Sui, MoveStdlib, Bridge, or SuiSystem in [dependencies]. They are implicit:

# ✅ Sui 1.45+
[dependencies]
# no framework entries needed

# ❌ Outdated
[dependencies]
Sui = { git = "...", subdir = "crates/sui-framework/packages/sui-framework", rev = "..." }

No [addresses] section (Sui CLI 1.63+) — named addresses are derived from the [package] name and [dependencies] keys. Do not add an [addresses] or [dev-addresses] section.

Run sui move build after any significant change to verify the code compiles before proceeding.


2. Building and Testing

Always verify code compiles and tests pass using the Sui CLI:

# Build
sui move build

# Run all tests
sui move test

# Run a specific test by name
sui move test swap_exact_input

Test conventions

Naming — do not prefix test functions with test_. The #[test] attribute already signals intent:

// ✅
#[test] fun create_pool() { }
#[test] fun swap_returns_correct_amount() { }

// ❌
#[test] fun test_create_pool() { }

Merge attributes — combine #[test] and #[expected_failure] on one line:

// ✅
#[test, expected_failure(abort_code = EInsufficientLiquidity)]
fun swap_with_zero_input() { ... }

// ❌
#[test]
#[expected_failure(abort_code = EInsufficientLiquidity)]
fun swap_with_zero_input() { ... }

Don't clean up in expected_failure tests — let them abort naturally, don't add scenario.end() or other teardown:

// ✅
#[test, expected_failure(abort_code = EInsufficientLiquidity)]
fun swap_with_zero_input() {
    let mut ctx = tx_context::dummy();
    let pool = create_pool(&mut ctx);
    pool.swap(coin::zero(&mut ctx)); // aborts here — done
}

// ❌ — don't clean up after expected failure
#[test, expected_failure(abort_code = EInsufficientLiquidity)]
fun swap_with_zero_input() {
    let mut scenario = test_scenario::begin(@0xA);
    // ... test body ...
    scenario.end(); // unnecessary, misleading
}

Use tx_context::dummy() for simple tests — only reach for test_scenario when multi-transaction or multi-sender behaviour is genuinely needed:

// ✅ Simple test — no scenario needed
#[test]
fun create_pool() {
    let mut ctx = tx_context::dummy();
    let pool = new_pool(&mut ctx);
    assert_eq!(pool.fee_bps(), 30);
    sui::test_utils::destroy(pool);
}

// ✅ Multi-sender test — scenario is appropriate
#[test]
fun only_admin_can_set_fee() {
    let mut scenario = test_scenario::begin(@admin);
    // ...
    scenario.end();
}

Assertions — prefer assert_eq! over assert! for value comparisons (shows both sides on failure), and never pass abort codes to assert!:

// ✅
assert_eq!(pool.fee_bps(), 30);
assert!(pool.is_active());

// ❌
assert!(pool.fee_bps() == 30);   // doesn't show the actual value on failure
assert!(pool.is_active(), 0);    // abort code conflicts with app error codes

Destroying objects in tests — use sui::test_utils::destroy, never write custom destroy_for_testing functions:

// ✅
use sui::test_utils::destroy;
destroy(pool);

// ❌
pool.destroy_for_testing();

3. What Move on Sui is NOT

PatternSourceDo NOT use on Sui
acquires, move_to, move_from, borrow_globalAptos / Core MoveSui has no global storage
signer typeAptos / Core MoveUse &mut TxContext and ctx.sender()
Script functionsAptosUse entry functions instead
public(friend)Legacy MoveUse public(package)
Struct without public keywordLegacy MoveAll structs must be public
let x = ... for mutable varsLegacy MoveUse let mut x = ...
use inside function bodies for module-level importsStyle issuePut use at the top of the module
&signerRust / AptosDoes not exist on Sui

Routing

TaskLoad
Writing module code, functions, enumssui-move-syntax
Defining structs or choosing abilitiessui-move-object
Emitting events, error handling, capssui-move-patterns
Working with Coin, Balance, vectors, etc.sui-move-stdlib
Full contract from scratchall sub-skills

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.