--- 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) ```bash # 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`: ```markdown ## ottersec-prep session, - packages in scope: - checklist completion: , - threat model doc: - test count: , coverage: - open issues: ``` 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 OtterSec today without a follow-up "actually, I forgot..."? If any answer is no, the skill reports the gap and works through it before claiming the package is audit-ready. ## References On-demand references (load when relevant to the user's question): - `references/pre-audit-walkthrough.md`: Item-by-item walk of the checklist with example pass/fail patterns. - `references/finding-categories.md`: Common findings OtterSec produces, with mitigation patterns. - `references/threat-model-template.md`: One-page threat-model template. Knowledge docs (load when scope expands beyond what is in references): - `skills/data/sui-knowledge/sponsor-docs/ottersec-checklist.md`: Full checklist source. - `skills/data/guides/security-checklist.md`: P0-P3 reference. ## Use in your agent - Claude Code: `claude "/suiper:ottersec-prep "` - Codex: `codex "/ottersec-prep "` - Cursor: paste a chat message that includes a phrase like "prepare for OtterSec audit", or load `~/.cursor/rules/ottersec-prep.mdc` and reference it. If you activated this and the user actually wants something else, consult `skills/SKILL_ROUTER.md` and hand off.