/deploy-to-mainnet

name: deploy-to-mainnet
description: Deploy a Sui Move package to mainnet after testnet has been exercised. Use when the user wants to ship to mainnet, go to prod, or publish to Sui mainnet.

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 deploy-to-mainnet ship completed
# Or use "failed" / "aborted" if it ended that way.
command -v suiperpower >/dev/null 2>&1 && suiperpower track deploy-to-mainnet ship 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

Runs the mainnet deploy with refusal gates in front of the publish step. The point is not to gatekeep, it is to surface the gates honestly so the user is not deploying to mainnet because they typed a command, but because they have done the work that mainnet implies.

If a gate is missing, the skill names what is missing and routes the user to the relevant skill. The user can override and proceed by typing the literal phrase the skill asks for, but the override is logged in `deploy-context.md` so it is on the record.

When to use it

• After the testnet deploy was exercised by a frontend or PTB and the relevant anti-slop skills have run.
• For a production launch the user is willing to defend.

When NOT to use it

• Pre-MVP, before there is a working testnet deploy.
• For experimental projects that should stay on testnet. Mainnet introduces real cost and real user expectations.
• If the user only wants a "label" of mainnet without the responsibility. Route to `validate-business-model` and `retention-loop` first.

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

Inputs

• `.suiperpower/business-model.md` (required, verdict must be `yes` or `partial`).
• `.suiperpower/retention-loop.md` (required, verdict must not be `no`).
• A recent `review-move` output, indicated by an entry in `.suiperpower/learnings.md` under `Decisions` or a separate `.suiperpower/review-move.md` if present.
• `.suiperpower/deploy-context.md` (required, must contain at least one testnet entry).
• `Move.toml` and the package path for the publish.
• A funded mainnet address.

Outputs

A `## Deploy, <timestamp>` block appended to `.suiperpower/deploy-context.md` with `env: mainnet`, the package id, the upgrade cap, the upgrade policy chosen, and any override notes:

## Deploy, <timestamp>

### Network
- env: mainnet
- rpc: <rpc url>
- gas address: <0x...>
- balance before: <SUI>
- balance after: <SUI>

### Package
- package id: <0x...>
- modules: <comma-separated module names>
- digest: <publish digest>
- upgrade cap object: <0x...>
- upgrade cap policy: <compatible | additive | dep-only | immutable>

### Gates
- business-model: <yes | partial | overridden>
- retention-loop: <yes | partial | overridden>
- review-move: <recent | overridden>
- testnet exercised: <yes | overridden>

### Notes
- <override rationale, if any>
- <stakeholders notified, if any>

Workflow

1. **Read the gate inputs**

• Open `business-model.md`, `retention-loop.md`, `deploy-context.md`. If any are missing, surface which ones and route the user back.
• Look for evidence that `review-move` ran in the last 14 days. The skill considers a `## Decisions` entry referencing `review-move` or a `.suiperpower/review-move.md` file as evidence.

2. **Score the gates**

• business-model: `yes` to proceed cleanly, `partial` to proceed with a flag, `no` to refuse unless override.
• retention-loop: `yes` or `partial` to proceed, `no` to refuse unless override.
• review-move: recent run within 14 days, or refuse unless override.
• testnet exercised: must have a testnet entry in `deploy-context.md` plus user-confirmed evidence the testnet package was exercised by a frontend or PTB.

3. **If a gate fails**

• Name the failed gate explicitly.
• Recommend the corresponding skill to clear it: `validate-business-model`, `retention-loop`, `review-move`, `deploy-to-testnet`.
• Offer the override path: the user must type "I accept the risk and want to deploy anyway" verbatim. Anything less is treated as a no.
• If the user overrides, record the rationale in the `Notes` section of the new deploy entry.

4. **Mainnet preflight**

• Verify Sui CLI version matches the version pinned in `skills/data/guides/deploy-runbook.md`.
• Verify env is `mainnet`, address is funded, RPC is healthy.
• Verify the same Move package builds and tests pass: `sui move build`, `sui move test`.

5. **Publish**

• Run `sui client publish <package path> --gas-budget <budget> --json`.
• Capture JSON output to a temp file.

6. **Capture artifacts**

• Apply jq recipe per `skills/data/guides/package-id-capture.md`.
• Extract package id, digest, `UpgradeCap` id.

7. **Lock the upgrade policy intentionally**

• Default policy after first mainnet publish is `compatible`. The skill prompts the user to choose:
• `compatible` (default): future upgrades may add fields and functions but not change existing signatures.
• `additive`: future upgrades may only add, never modify.
• `dep-only`: future upgrades only update dependency package addresses.
• `immutable`: no future upgrades possible. Most secure, most rigid.
• The skill records the chosen policy. If the user picks `immutable`, the skill confirms with a second prompt.

8. **W