/verify-against-intent

name: verify-against-intent
description: After a Sui build session, check what was built against .suiperpower/intent.md and flag drift. Use when the user wants to verify their build matches intent.

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

Closes the loop on a Sui build session with disk-grounded checks, not session-memory claims. Walks the plan's Object model, capability holders, sponsor surfaces, and upgrade posture against actual Move source, `Move.toml`, `deploy-context.md`, and the test suite. Names drift honestly: decorative sponsor integration claimed as load-bearing, capabilities held in the wrong place, public functions without tests, deploy state that does not match the planned network rollout.

Without this gate, agents say "done" against a target that was never written. With it, every criterion gets a pass / fail / partial verdict tied to a concrete artifact.

When to use it

• A build skill (`build-with-move`, `walrus-storage`, `deepbook-orderbook`, `scallop-money-market`, `sui-zk-login`, `kiosk-marketplace`, etc.) just reported done.
• The user says "did we get there", "is this what I asked for", or "review what we built".
• A session is about to be wrapped, before `learn` captures it.
• The user is preparing to ship: run this before `deploy-to-testnet`, `deploy-to-mainnet`, or `submit-to-sui-overflow`.

When NOT to use it

• `.suiperpower/intent.md` does not exist. There is nothing to verify against. Use `clarify-intent` to backfill, then re-run.
• The user wants a security audit, use `review-move` (different gate, P0 to P3 findings) or `ottersec-prep`.
• The user wants UX critique, use `product-review` or `roast-my-product`.
• The user wants a code-style review. Not this skill.

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

Inputs

• `.suiperpower/intent.md` (required).
• `.suiperpower/build-plan.md` if `plan-before-code` ran.
• `.suiperpower/build-context.md`, `.suiperpower/deploy-context.md` if present.
• The current project tree: Move sources, `Move.toml`, `tests/`, frontend if any.

If `intent.md` is missing, stop. Tell the user verification needs a recorded intent. Offer `clarify-intent` to backfill.

Outputs

A printed report and an append to `.suiperpower/build-context.md`:

## verify-against-intent, <timestamp>

### Success criteria check
1. <criterion>: pass | fail | partial, evidence: <file:line | testnet tx hash | package id>
2. <criterion>: pass | fail | partial, evidence: <...>
...

### Object model check
- <ObjectName>: planned <ownership, abilities> | actual <ownership, abilities>: match | mismatch
- ...

### Capability holder check
- <CapName>: planned holder <X> | actual at init <Y>: match | mismatch

### Sponsor integration check (load-bearing test)
- <Walrus | DeepBook | Scallop | OZ Sui | zkLogin>: planned surface <...> | actual: <imported only | called but result unused | load-bearing in user flow with evidence <...>>

### Test coverage check
- Public entry points with at least one test: <count> / <total>
- Cap-gated functions with expected-failure tests: <count> / <total>
- Functions missing tests: <list>

### Build check
- `sui move build`: pass | fail (<error summary if fail>)
- `Move.toml` deps pinned (rev or tag): yes | no

### Upgrade and deploy posture check
- Planned network rollout: <devnet -> testnet -> mainnet>
- Actual deploy state: <per-network package id from deploy-context.md, or "not deployed">
- Upgrade authority: planned <X> | actual <Y from on-chain or deploy-context>: match | mismatch

### Drift summary
<one paragraph, honest>

### Follow-ups
- <thing to fix, with the skill that fixes it>
- <thing to document as accepted scope cut>

The skill does not fix the drift. It names it, points to the right skill, hands off.

Workflow

1. **Read inputs**

• `.suiperpower/intent.md`. Missing? Stop.
• `.suiperpower/build-plan.md` if present.
• `.suiperpower/build-context.md`, `.suiperpower/deploy-context.md`.
• List Move modules (`sources/*.move`), tests (`tests/*.move`), `Move.toml`, frontend entry points if applicable.

2. **Map criteria to Sui-grounded evidence** For each success criterion in `intent.md`, decide what would prove it:

• On-chain function existing? Check for `public entry fun <name>` in source.
• Test pass? Check for the named test in `tests/`.
• Network deploy? Check `deploy-context.md` for a package id on the right network.
• Frontend behavior? Check that the route calls the named entry point.
• Sponsor user flow? Check that the SDK call sits inside a real user path, not a top-of-file import only.

Do not trust session memory. Read disk.

3. **Object model check** For each Object in `build-plan.md`:

• Find `struct <Name>` in source. Parse abilities (`has key, store, ...`).
• Compare to plan. Note mismatch on ownership (e.g. plan said shared, code uses `transfer::transfer`, that is owned).

4. **Capability holder check** For each capability:

• Locate the `init` function. See where