review-sui-contracts

Name: review-sui-contracts
Author: OpenZeppelin

200stars27forks

How to install review-sui-contracts?

openzeppelin/openzeppelin-skills/review-sui-contracts

$npx -y skills add OpenZeppelin/openzeppelin-skills --skill review-sui-contracts

Installs into the current project.

Summary

Review Sui Move code that integrates OpenZeppelin Contracts for Sui against the library's own patterns and conventions. Use this when a developer wants their integration checked before shipping. Triggers: \"review my Sui Move code\", \"am I using OpenZeppelin correctly\", \"check

Files · 1

View on GitHub

SKILL.md

1	# Review Sui Contracts
2
3	AI-assisted review of a developer's Sui Move code against OpenZeppelin Contracts for Sui: does it use the library's on-chain primitives correctly, and where does it deviate from the library's `examples/`, doc-comments, and documented conventions?
4
5	> This is an AI code review, not a formal security audit. It supports the audit process by flagging misuse and deviations early; it does not replace an independent audit, and a clean review is not an assurance of safety.
6
7	For building an integration use `develop-secure-contracts`; for scaffolding a project use `setup-sui-contracts`. This skill reviews code that already exists.
8
9	## Establish the reference before reviewing
10
11	You cannot flag "incorrect use" or "deviation" without the correct pattern in hand — so discover it from the library's own metadata, never from memory, using the discovery chain the `develop-secure-contracts` skill defines. Read the primitive's API and behavior at the revision the integrator builds against — resolve each OZ dependency's pinned rev from `Move.lock` and use that source / those doc-comments, not `main`. Read the library-wide docs — `llms.txt`, the catalogs, `ARCHITECTURE.md`, `STYLEGUIDE.md` — from the repo's current `main` instead: they evolve continuously and often do not exist at an older pinned rev. For each OZ primitive the code uses, load its authoritative pattern from:
12
13	- the package's `examples/` if it has them, otherwise the module-header doc-comment's idiomatic-usage block — the canonical recipe (some packages ship only the latter);
14	- the modules' doc-comments and generated API reference (reached via the catalog's `Docs` link);
15	- `ARCHITECTURE.md` (capability model, object ownership, initialization) and `STYLEGUIDE.md` (conventions).
16
17	Review the code against those, not against assumptions.
18
19	## What to review
20
21	- Correct use of OZ primitives. Does the code thread the capability/witness the component defines (rather than hand-rolling `sender` checks or re-implementing what the library already provides), call functions with the right arguments, and handle the documented abort conditions?
22	- Who chooses the type argument — and is it the right one. For each OZ primitive parameterized by a witness or generic/`phantom` type, check who supplies it and whether it is the correct authority. A caller-chosen type is an authority the caller controls, so the trusted party must fix it, not the caller. And a developer-fixed type must be the right one for the action — a privileged operation gated by a lower-privilege role's `Auth` (or any weaker witness than the guarantee needs) is a privilege-escalation bug.
23	- Deviations from the reference pattern. Compare the flow against the closest `examples/` recipe (or the doc-comment's idiomatic-usage block) and flag divergences that weaken the guarantees it preserves — e.g. an object shared vs. embedded against its intended ownership model, a required setup step skipped, a returned value or receipt ignored, or an invariant the doc-comment states being bypassed.
24	- Copied library source. Flag any OZ module source copied into the project instead of imported via MVR — copies miss security updates.
25	- Invariants upheld. Check that the code preserves the invariants the OZ components document (in their doc-comments and `ARCHITECTURE.md`) — e.g. an object that must stay shared, a value that must remain bounded, a capability that must not be exposed. Flag any path that can break one.
26	- Test coverage of the integration. Check that the tests exercise the abort and branch paths the OZ usage introduces (role-denied, expired, over-limit, wrong-type, and similar), not just the happy path — untested failure paths are where integration bugs hide.
27	- Known issue classes (heuristic). Check the code for the classes of issue that recur in OZ-on-Sui / Move code — capability handling, rounding, object ownership, initialization — and raise suspicion where the code touches them. (The library's published audits, under `audits/`, inform these classes; the reports themselves are PDFs, not a findings feed.) A suspicion-raising self-check, not a reproduction of the audits or a security audit.
28
29	## Code quality — enforce the conventions
30
31	Treat OpenZeppelin's Sui conventions as a first-class review dimension

OpenZeppelinPublisher · 12 listings

Preview

OpenZeppelin/openzeppelin-skills

# Review Sui Contracts

AI-assisted review of a developer's Sui Move code against **OpenZeppelin Contracts for Sui**: does it use the library's on-chain primitives correctly, and where

> **This is an AI code review, not a formal security audit.** It supports the audit process by flagging misuse and deviations early; it does not replace an inde

For **building** an integration use `develop-secure-contracts`; for **scaffolding** a project use `setup-sui-contracts`. This skill reviews code that already ex

RepoOpenZeppelin/openzeppelin-skills

LicenseAGPL-3.0

TypeSkills

CategoryWeb3

UpdatedJul 2026

Repo stars200

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

review-sui-contracts

200stars27forks

View on GitHub

How to install review-sui-contracts?

openzeppelin/openzeppelin-skills/review-sui-contracts

$npx -y skills add OpenZeppelin/openzeppelin-skills --skill review-sui-contracts

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review Sui Contracts
2
3	AI-assisted review of a developer's Sui Move code against OpenZeppelin Contracts for Sui: does it use the library's on-chain primitives correctly, and where does it deviate from the library's `examples/`, doc-comments, and documented conventions?
4
5	> This is an AI code review, not a formal security audit. It supports the audit process by flagging misuse and deviations early; it does not replace an independent audit, and a clean review is not an assurance of safety.
6
7	For building an integration use `develop-secure-contracts`; for scaffolding a project use `setup-sui-contracts`. This skill reviews code that already exists.
8
9	## Establish the reference before reviewing
10
11	You cannot flag "incorrect use" or "deviation" without the correct pattern in hand — so discover it from the library's own metadata, never from memory, using the discovery chain the `develop-secure-contracts` skill defines. Read the primitive's API and behavior at the revision the integrator builds against — resolve each OZ dependency's pinned rev from `Move.lock` and use that source / those doc-comments, not `main`. Read the library-wide docs — `llms.txt`, the catalogs, `ARCHITECTURE.md`, `STYLEGUIDE.md` — from the repo's current `main` instead: they evolve continuously and often do not exist at an older pinned rev. For each OZ primitive the code uses, load its authoritative pattern from:
12
13	- the package's `examples/` if it has them, otherwise the module-header doc-comment's idiomatic-usage block — the canonical recipe (some packages ship only the latter);
14	- the modules' doc-comments and generated API reference (reached via the catalog's `Docs` link);
15	- `ARCHITECTURE.md` (capability model, object ownership, initialization) and `STYLEGUIDE.md` (conventions).
16
17	Review the code against those, not against assumptions.
18
19	## What to review
20
21	- Correct use of OZ primitives. Does the code thread the capability/witness the component defines (rather than hand-rolling `sender` checks or re-implementing what the library already provides), call functions with the right arguments, and handle the documented abort conditions?
22	- Who chooses the type argument — and is it the right one. For each OZ primitive parameterized by a witness or generic/`phantom` type, check who supplies it and whether it is the correct authority. A caller-chosen type is an authority the caller controls, so the trusted party must fix it, not the caller. And a developer-fixed type must be the right one for the action — a privileged operation gated by a lower-privilege role's `Auth` (or any weaker witness than the guarantee needs) is a privilege-escalation bug.
23	- Deviations from the reference pattern. Compare the flow against the closest `examples/` recipe (or the doc-comment's idiomatic-usage block) and flag divergences that weaken the guarantees it preserves — e.g. an object shared vs. embedded against its intended ownership model, a required setup step skipped, a returned value or receipt ignored, or an invariant the doc-comment states being bypassed.
24	- Copied library source. Flag any OZ module source copied into the project instead of imported via MVR — copies miss security updates.
25	- Invariants upheld. Check that the code preserves the invariants the OZ components document (in their doc-comments and `ARCHITECTURE.md`) — e.g. an object that must stay shared, a value that must remain bounded, a capability that must not be exposed. Flag any path that can break one.
26	- Test coverage of the integration. Check that the tests exercise the abort and branch paths the OZ usage introduces (role-denied, expired, over-limit, wrong-type, and similar), not just the happy path — untested failure paths are where integration bugs hide.
27	- Known issue classes (heuristic). Check the code for the classes of issue that recur in OZ-on-Sui / Move code — capability handling, rounding, object ownership, initialization — and raise suspicion where the code touches them. (The library's published audits, under `audits/`, inform these classes; the reports themselves are PDFs, not a findings feed.) A suspicion-raising self-check, not a reproduction of the audits or a security audit.
28
29	## Code quality — enforce the conventions
30
31	Treat OpenZeppelin's Sui conventions as a first-class review dimension

OpenZeppelinPublisher · 12 listings

Preview

OpenZeppelin/openzeppelin-skills

# Review Sui Contracts

AI-assisted review of a developer's Sui Move code against **OpenZeppelin Contracts for Sui**: does it use the library's on-chain primitives correctly, and where

> **This is an AI code review, not a formal security audit.** It supports the audit process by flagging misuse and deviations early; it does not replace an inde

For **building** an integration use `develop-secure-contracts`; for **scaffolding** a project use `setup-sui-contracts`. This skill reviews code that already ex

RepoOpenZeppelin/openzeppelin-skills

LicenseAGPL-3.0

TypeSkills

CategoryWeb3

UpdatedJul 2026

Repo stars200

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type