/object-model-design

name: object-model-design
description: Design the Sui Object schema (owned vs shared, capability patterns). Use when the user wants to model Sui Objects or pick capability patterns.

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 object-model-design build completed
# Or use "failed" / "aborted" if it ended that way.
command -v suiperpower >/dev/null 2>&1 && suiperpower track object-model-design 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

Designs the Object schema for a Sui project before any Move code is written. Identifies every Object the system creates, decides owned vs shared vs immutable for each, picks the capability pattern that gates state changes, and writes the rationale into `build-context.md` so future readers (including auditors) can see why each decision was made.

Sui's object model is the most important architectural decision and the easiest to get wrong. This skill front-loads that thinking.

When to use it

• Starting a new Move package and designing the data model.
• Refactoring an existing package whose ownership decisions have proven painful.
• Reviewing a third-party Move package and reverse-engineering its object decisions.
• Migrating from EVM mental model (account-centric) to Sui mental model (Object-centric).

When NOT to use it

• For tiny single-Object utilities, design pressure is low; just write the code.
• For raw Move authoring after the design is done, use `build-with-move`.
• For client-side composition, use `ptb-composer`.

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

Inputs

• A project intent (one sentence: what does the package do).
• Optional: `.suiperpower/build-context.md` from `scaffold-project`. Read it if present.

If unclear, interview the user for:

• What entities exist in the system? (User, Vault, Listing, Position, etc.)
• For each, who can read it, who can mutate it, who owns it?
• Are mutations sequenced (one at a time per user) or contended (many parties race)?
• What capabilities exist (admin, treasury, moderator, custom)?

Outputs

• An Object map: each Object listed with its abilities (`key`, `store`), owner type (owned by address, shared, immutable), and the capability that gates mutation (if any).
• A capability flow diagram: where each capability is created, who holds it, who can use it.
• Rationale per decision: one line of why, especially for shared vs owned.
• Append to `.suiperpower/build-context.md`:

  ## object-model-design session, <timestamp>
  ### Objects
  | Object | Abilities | Ownership | Mutation gate | Why |
  |---|---|---|---|---|
  | User | key, store | owned | self | per-user state |
  | Vault | key | shared | AdminCap | global state, admins mutate |
  | ... | ... | ... | ... | ... |

  ### Capabilities
  - AdminCap: created in init, transferred to multisig, by-reference everywhere.
  - TreasuryCap: created via coin::create_currency, held by issuer, by-reference for mint/burn.

  ### 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 present.
• Confirm the project intent and major entities.

2. **Entity inventory**

• For each entity, name it.
• For each, identify: who creates it, who reads it, who mutates it, when it is destroyed.

3. **Owned vs shared vs immutable**

• Owned: only one address mutates at a time. Default for per-user state.
• Shared: multiple parties can call mutating functions concurrently (sequenced by consensus). Use for global state.
• Immutable: never mutated after creation. Use for content-addressed records, NFTs that should not change.
• Walk each entity, decide, write down the why.

4. **Abilities**

• Top-level Objects: `key`, plus `store` if they will be nested or transferred.
• Nested: `store` only.
• Stateful: avoid `copy` and `drop` unless silent burning or duplication is the intent.

5. **Capability map**

• For every state-changing function, name the capability that gates it.
• For each capability, name: where it is created, who holds it, by-reference vs by-value, whether it can leak via Display or public read.

6. **Sketch the API surface**

• List every public entry function. For each, name: which Object(s) it touches, which capability it requires, what it returns.
• Walk the sketch back to the user.

7. **Stress-test the design**

• Concurrency: can two users race in a way that matters?
• Reinitialization: can an attacker call a "create" function twice?
• Capability leakage: does any public function expose a Cap?
• Versioning: does any shared Object's mutation path forget to bump version?

8. **Document and pass to build-with-move**

• Write the Object map and capability map into `build-context.md`.
• Hand off to `build-with-move` for actual implementation.

Quality gate (anti-slop)

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

• Does every Object in the schema have an explicit owner-type decision (owned, shared, immutable) with a one-line rationale?
• Does every capability have a documented holder strategy (EOA, multisi