/ottersec-prep

name: ottersec-prep
description: Prep a Sui Move package for an OtterSec security audit. Use when the user mentions OtterSec or wants audit prep.

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

Walks the OtterSec pre-audit checklist on the user's Move package, surfaces the gaps, and produces the engagement package the auditor expects (threat model, architecture diagram outline, test report, known-issues doc). The goal is for audit time to be spent on real findings, not on hygiene noise.

When to use it

• About to engage OtterSec or another Sui Move auditor.
• Wanting to self-assess audit readiness.
• Preparing the audit-prep portion of a Sui Overflow submission targeting the OtterSec track.

When NOT to use it

• Pre-MVP code where auditing is premature; use `review-move` for an in-house P0-P3 walk first.
• If the project does not have any Move code yet, use `build-with-move` first.
• For non-Move security questions (frontend XSS, key custody for sponsor wallets), use the relevant build skill.

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

Inputs

• A Sui project with at least one Move package under `move/` or similar.
• Optional: `.suiperpower/build-context.md` and any prior `review-move` output.

If unclear, interview the user for:

• Which packages are in scope for the audit?
• Target deploy: which network, what value at risk?
• Are there parts the user explicitly does not want audited (test scaffolding, prototypes)?
• What is the timeline for the audit and the deploy?

Outputs

• A filled-in pre-audit checklist (every P0 item answered, P1-P3 documented).
• A `THREAT_MODEL.md` in the project: who is trusted, what are the assets, what are the known risks.
• An architecture summary (which modules talk to which, where capabilities flow).
• A test-coverage report from `sui move test`.
• A `KNOWN_ISSUES.md` listing decisions to ship despite known concerns.
• Append to `.suiperpower/build-context.md`:

  ## ottersec-prep session, <timestamp>
  - packages in scope: <list>
  - checklist completion: <P0 percent>, <P1 percent>
  - threat model doc: <path>
  - test count: <n>, coverage: <percent>
  - 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 package(s) in scope and the deploy target.

2. **P0 walk**

• Step through every P0 item from `skills/data/guides/security-checklist.md`.
• For each, mark pass / fail / not-applicable with a one-line note.
• For fails, propose a fix and let the user decide whether to fix now or document as known.

3. **Capability inventory**

• List every `*Cap` struct in the package(s).
• For each, document: who creates it, who holds it, who can pass it to whom, whether it leaks via Display or public read.

4. **Visibility audit**

• Confirm `public(package)` is the default; `public` is reserved for true cross-package APIs.
• Flag any leftover `friend` declarations; recommend migration.
• Confirm `#[test_only]` on test helpers.

5. **Init function audit**

• Confirm one-time witness pattern intact.
• Confirm init does not leak capabilities outside its intended distribution.
• Confirm reinitialization is impossible (no shared init paths that can be re-entered).

6. **Test coverage**

• Run `sui move test`, capture output.
• Confirm every public entry function has at least one positive and one expected-failure test (where applicable).

7. **Build cleanliness**

• Run `sui move build`. Confirm zero warnings.
• Strip `assert!(false)`, commented-out checks, and `std::debug::print` from production paths.
• Confirm error codes are named constants, not magic numbers.

8. **Dependency pin**

• Confirm `Move.toml` uses pinned revs / tags. Reject `main` or floating versions in production deps.

9. **Threat model + known issues**

• Help the user write `THREAT_MODEL.md` and `KNOWN_ISSUES.md` if absent.
• Surface assumptions the auditor needs to know.

10. **Engagement package**

• Compose the audit submission: repo URL, scope, threat model, architecture, test report, checklist, known issues.
• Surface the OtterSec contact path (`https://osec.io/`).

11. **Writeback**

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

Quality gate (anti-slop)

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

• Is every P0 item from the security checklist explicitly marked pass / fail / N/A with a note?
• Has every public entry function been mapped to at least one happy-path test and one expected-failure test where applicable?
• Is `THREAT_MODEL.md` non-trivial (assets, trust assumptions, known risks named)?
• Is the capability inventory complete (every `*Cap` listed with holder strategy)?
• Is `Move.toml` pinned, no `main` in production deps?
• Is the engagement package something the user could send to O