/kiosk-marketplace

name: kiosk-marketplace
description: Build a Sui NFT marketplace with the Kiosk standard, transfer policy, royalties. Use when the user wants a Sui NFT marketplace or Kiosk integration.

Preamble (run first)

# Suiperpower telemetry. Routes through the CLI so projects.json + Convex stay in sync.
# Silent on failure so the skill never blocks. Opt out: SUIPERPOWER_TELEMETRY=off.
#
# AGENT NOTE: when this skill finishes, run the matching completion command:
#   suiperpower track kiosk-marketplace build completed
# Or use "failed" / "aborted" if it ended that way.
command -v suiperpower >/dev/null 2>&1 && suiperpower track kiosk-marketplace build started >/dev/null 2>&1 &
true

If `TEL_PROMPTED` is `no`, before doing real work, ask the user:

> Help suiperpower get better. We track which skills get used and how long they take. No code, no file paths, no PII. Change anytime in `~/.suiperpower/config.json`. > > A) Sure, anonymous > B) No thanks

Write the answer to `~/.suiperpower/config.json` `telemetryTier` field and create `~/.suiperpower/.telemetry-prompted`. Then continue.

What this skill does

Builds a marketplace on top of the Kiosk standard. Sets up the seller's Kiosk Object, defines a TransferPolicy with royalty and lock rules, writes list and purchase entry points, and verifies a real listing-to-purchase round-trip on testnet before declaring done. Avoids reinventing escrow logic that Kiosk already provides.

When to use it

• Building a marketplace, gallery, or trading venue for Sui NFTs.
• The user wants Sui-native royalty enforcement (Kiosk's TransferPolicy is the supported mechanism).
• The user wants a lock-and-list pattern where the seller cannot rug after listing.
• Migrating an EVM-style marketplace to Sui and wanting the right primitive.

When NOT to use it

• For fungible token trading, use `deepbook-orderbook` instead.
• If the user is launching a coin (fungible), use `launch-coin` instead.
• If the user has not picked a project yet, use `find-next-sui-idea` first.
• If the user has not scaffolded a project, use `scaffold-project` first.

If you activated this and the user actually wants something else, consult `skills/SKILL_ROUTER.md` and hand off.

Inputs

• A Sui project (Move package and/or TS frontend).
• Optional: `.suiperpower/build-context.md`. Read it if present.
• The asset type to be traded (existing NFT type, or one the user creates).

If unclear, interview the user for:

• What asset type is traded? Existing collection, or a new collection the user mints?
• Royalty policy? Fixed percent, tiered, or none?
• Are listings public, invite-only, or curated?
• Is there a primary sale (mint to first buyer) plus secondary, or only secondary?

Outputs

• Move module(s) defining the asset type (if new), the TransferPolicy, and any custom rules.
• TS client code that creates a Kiosk per seller, lists items, and executes purchases.
• A live testnet round-trip: list one item, purchase it from a different wallet, observable on suiscan.
• Append to `.suiperpower/build-context.md`:

  ## kiosk-marketplace session, <timestamp>
  - asset type: <module::Type>
  - transfer policy id: <id>
  - sample kiosk id (seller): <id>
  - sample listing tx digest: <digest>
  - sample purchase tx digest: <digest>
  - royalty policy: <description>
  - open issues: <list>

The skill never deletes files outside the integration source path without explicit user confirmation.

Workflow

1. **Context gathering**

• Read `.suiperpower/build-context.md` if it exists.
• Confirm asset type, royalty policy, and listing model.

2. **Asset type**

• If new, define the asset's Move struct with `key + store` abilities.
• Set up Display for the asset (so wallets render it correctly).
• Mint a test specimen to the seller wallet.

3. **TransferPolicy**

• Create a TransferPolicy for the asset type. The publisher (creator) holds the policy capability.
• Add rules: royalty rule (percentage of sale to creator), lock rule (buyer cannot pull out of Kiosk for N seconds), or custom rules.
• Persist the policy id.

4. **Seller Kiosk**

• Create a Kiosk Object for the seller. Holds the asset until sold.
• Place the asset in the Kiosk and lock it (TransferPolicy enforced).
• List with a price.

5. **Buyer purchase**

• From a different wallet, construct the purchase PTB:
• Pay the seller.
• Acquire the asset from the Kiosk.
• Confirm the TransferPolicy (royalty + any rules).
• Either keep the asset in the buyer's own Kiosk or transfer freely depending on policy.

6. **Royalty verification**

• Confirm the royalty payment landed in the publisher's address.

7. **Demo settlement**

• Run the real testnet round-trip end to end. Capture digests.

8. **Writeback**

• Append session details to `.suiperpower/build-context.md`.

9. **Closing handoff**

• If `.suiperpower/intent.md` exists and the session was non-trivial (new Kiosk integration, TransferPolicy rules added, royalty path live), recommend `verify-against-intent` as the next step so the policy capability holder and royalty enforcement are checked before shipping.
• If no `intent.md` exists and the session was non-trivial, surface that gap once: offer `clarify-intent` to backfill, do not force it.

Quality gate (anti-slop)

Before reporting done, the skill asks itself the following and refuses to declare success if any answer is no:

• Did a real listing and a real purchase from a different wallet both settle on testnet, with digests recorded?
• Was the TransferPolicy enforced on the purchase, with the royalty visibly paid out?
• Is the listed asset's Display configured so wallets render it correctly?
• Does the buyer end up either with the asset in their own Kiosk or with a clean transfer that complies with the TransferPolicy?
• If the user defined custom rules (lock, allowlist), is each rule tested with a positive case and an expected-failure