[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-openzeppelin-review-sui-contracts":3,"mdc--tpjz14-key":36,"related-org-openzeppelin-review-sui-contracts":680,"related-repo-openzeppelin-review-sui-contracts":810},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":25,"repoUrl":26,"updatedAt":27,"license":28,"forks":29,"topics":30,"repo":31,"sourceUrl":34,"mdContent":35},"review-sui-contracts","review Sui Move smart contracts","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 this integration\", \"is this idiomatic\", \"review before audit\". Checks correct use of OZ primitives, deviations from examples\u002Fdoc-comments, upheld invariants, test coverage, and code-quality\u002Fstyle. This is an AI code review, not a formal security audit.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"openzeppelin","OpenZeppelin","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fopenzeppelin.png",[12,16,19,22],{"name":13,"slug":14,"type":15},"Blockchain","blockchain","tag",{"name":17,"slug":18,"type":15},"Code Review","code-review",{"name":20,"slug":21,"type":15},"Rust","rust",{"name":23,"slug":24,"type":15},"Smart Contracts","smart-contracts",193,"https:\u002F\u002Fgithub.com\u002FOpenZeppelin\u002Fopenzeppelin-skills","2026-07-16T06:00:49.17387","AGPL-3.0-only",25,[],{"repoUrl":26,"stars":25,"forks":29,"topics":32,"description":33},[],"Agent skills for secure smart contract development with OpenZeppelin Contracts libraries","https:\u002F\u002Fgithub.com\u002FOpenZeppelin\u002Fopenzeppelin-skills\u002Ftree\u002FHEAD\u002Fskills\u002Freview-sui-contracts","---\nname: review-sui-contracts\ndescription: \"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 this integration\\\", \\\"is this idiomatic\\\", \\\"review before audit\\\". Checks correct use of OZ primitives, deviations from examples\u002Fdoc-comments, upheld invariants, test coverage, and code-quality\u002Fstyle. This is an AI code review, not a formal security audit.\"\nlicense: AGPL-3.0-only\nmetadata:\n  author: OpenZeppelin\n---\n\n# Review Sui Contracts\n\nAI-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\u002F`, doc-comments, and documented conventions?\n\n> **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.\n\nFor **building** an integration use `develop-secure-contracts`; for **scaffolding** a project use `setup-sui-contracts`. This skill reviews code that already exists.\n\n## Establish the reference before reviewing\n\nYou 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 \u002F 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:\n\n- the package's **`examples\u002F` if it has them, otherwise the module-header doc-comment's idiomatic-usage block** — the canonical recipe (some packages ship only the latter);\n- the modules' **doc-comments** and generated API reference (reached via the catalog's `Docs` link);\n- **`ARCHITECTURE.md`** (capability model, object ownership, initialization) and **`STYLEGUIDE.md`** (conventions).\n\nReview the code against those, not against assumptions.\n\n## What to review\n\n- **Correct use of OZ primitives.** Does the code thread the capability\u002Fwitness 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?\n- **Who chooses the type argument — and is it the right one.** For each OZ primitive parameterized by a witness or generic\u002F`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.\n- **Deviations from the reference pattern.** Compare the flow against the closest `examples\u002F` 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.\n- **Copied library source.** Flag any OZ module source copied into the project instead of imported via MVR — copies miss security updates.\n- **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.\n- **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.\n- **Known issue classes (heuristic).** Check the code for the classes of issue that recur in OZ-on-Sui \u002F Move code — capability handling, rounding, object ownership, initialization — and raise suspicion where the code touches them. (The library's published audits, under `audits\u002F`, 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.\n\n## Code quality — enforce the conventions\n\nTreat OpenZeppelin's Sui conventions as a first-class review dimension: report violations as **findings, not optional suggestions**. The rules and the review procedure are the single source of truth — apply them, don't restate them:\n\n- **[`STYLEGUIDE.md`](https:\u002F\u002Fraw.githubusercontent.com\u002FOpenZeppelin\u002Fcontracts-sui\u002Fmain\u002FSTYLEGUIDE.md)** — the codified rules (naming, section ordering, imports, idiomatic Move 2024, testing, docs, lint suppression).\n- **[`.claude\u002Fcommands\u002Fcode-quality.md`](https:\u002F\u002Fraw.githubusercontent.com\u002FOpenZeppelin\u002Fcontracts-sui\u002Fmain\u002F.claude\u002Fcommands\u002Fcode-quality.md)** — the canonical procedure that checks `.move` files against `STYLEGUIDE.md`; run it against the code under review.\n- **Lint is not optional.** Build and test with the project's `--build-env` and `--lint` (see `setup-sui-contracts` for the exact invocation); per the styleguide, warnings must be **fixed**, never suppressed with `#[allow(...)]`. `--lint` enforces the compiler-checkable subset independently, so if the `STYLEGUIDE.md` fetch is momentarily unreachable, retry rather than skipping conventions.\n\nReport each violation against the `STYLEGUIDE.md` section it breaks.\n\n## Verify before reporting\n\nThe checks above optimize for catching issues, so before writing anything, try to *disprove* each finding: quote the exact line and confirm the problem is really there; confirm it is a genuine deviation and not an intentional, documented choice; and confirm you can state a concrete one-line fix. Drop whatever does not survive all three, and keep the severity bar high — a short review a developer trusts beats a long one they skim.\n\n## Output\n\nProduce one review, findings ordered by severity. Each finding: `file:line` — what's wrong (one clause) → the fix (one clause) — and the OZ `example` or doc-comment it deviates from, so the developer can compare directly. A short preamble is useful — the scope\u002Fboundary call and the build\u002Ftest\u002Flint status — and on a clean integration a single \"verified and cleared\" line is fine; keep the body to findings, not a recap.\n\nIf the project builds, run its checks first (`sui move build` \u002F `test`, per `setup-sui-contracts`) so the review reflects compiling code, and report build\u002Ftest failures separately from the pattern findings.\n\n## Boundaries\n\n- Reviews the **integrator's** code — how it uses the library — not the OpenZeppelin library internals themselves.\n- **Not a security audit** — no exhaustive threat modeling or completeness guarantee; recommend a formal audit for production code.\n- Complements `develop-secure-contracts` (integration) and `setup-sui-contracts` (scaffolding); it neither builds nor scaffolds.\n",{"data":37,"body":39},{"name":4,"description":6,"license":28,"metadata":38},{"author":9},{"type":40,"children":41},"root",[42,50,73,87,122,129,198,263,268,274,408,414,426,545,557,563,575,581,602,630,636],{"type":43,"tag":44,"props":45,"children":46},"element","h1",{"id":4},[47],{"type":48,"value":49},"text","Review Sui Contracts",{"type":43,"tag":51,"props":52,"children":53},"p",{},[54,56,62,64,71],{"type":48,"value":55},"AI-assisted review of a developer's Sui Move code against ",{"type":43,"tag":57,"props":58,"children":59},"strong",{},[60],{"type":48,"value":61},"OpenZeppelin Contracts for Sui",{"type":48,"value":63},": does it use the library's on-chain primitives correctly, and where does it deviate from the library's ",{"type":43,"tag":65,"props":66,"children":68},"code",{"className":67},[],[69],{"type":48,"value":70},"examples\u002F",{"type":48,"value":72},", doc-comments, and documented conventions?",{"type":43,"tag":74,"props":75,"children":76},"blockquote",{},[77],{"type":43,"tag":51,"props":78,"children":79},{},[80,85],{"type":43,"tag":57,"props":81,"children":82},{},[83],{"type":48,"value":84},"This is an AI code review, not a formal security audit.",{"type":48,"value":86}," 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.",{"type":43,"tag":51,"props":88,"children":89},{},[90,92,97,99,105,107,112,114,120],{"type":48,"value":91},"For ",{"type":43,"tag":57,"props":93,"children":94},{},[95],{"type":48,"value":96},"building",{"type":48,"value":98}," an integration use ",{"type":43,"tag":65,"props":100,"children":102},{"className":101},[],[103],{"type":48,"value":104},"develop-secure-contracts",{"type":48,"value":106},"; for ",{"type":43,"tag":57,"props":108,"children":109},{},[110],{"type":48,"value":111},"scaffolding",{"type":48,"value":113}," a project use ",{"type":43,"tag":65,"props":115,"children":117},{"className":116},[],[118],{"type":48,"value":119},"setup-sui-contracts",{"type":48,"value":121},". This skill reviews code that already exists.",{"type":43,"tag":123,"props":124,"children":126},"h2",{"id":125},"establish-the-reference-before-reviewing",[127],{"type":48,"value":128},"Establish the reference before reviewing",{"type":43,"tag":51,"props":130,"children":131},{},[132,134,142,144,149,151,157,159,165,167,173,175,181,183,189,191,196],{"type":48,"value":133},"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 ",{"type":43,"tag":57,"props":135,"children":136},{},[137],{"type":43,"tag":65,"props":138,"children":140},{"className":139},[],[141],{"type":48,"value":104},{"type":48,"value":143}," skill defines. Read the primitive's ",{"type":43,"tag":57,"props":145,"children":146},{},[147],{"type":48,"value":148},"API and behavior at the revision the integrator builds against",{"type":48,"value":150}," — resolve each OZ dependency's pinned rev from ",{"type":43,"tag":65,"props":152,"children":154},{"className":153},[],[155],{"type":48,"value":156},"Move.lock",{"type":48,"value":158}," and use that source \u002F those doc-comments, not ",{"type":43,"tag":65,"props":160,"children":162},{"className":161},[],[163],{"type":48,"value":164},"main",{"type":48,"value":166},". Read the library-wide docs — ",{"type":43,"tag":65,"props":168,"children":170},{"className":169},[],[171],{"type":48,"value":172},"llms.txt",{"type":48,"value":174},", the catalogs, ",{"type":43,"tag":65,"props":176,"children":178},{"className":177},[],[179],{"type":48,"value":180},"ARCHITECTURE.md",{"type":48,"value":182},", ",{"type":43,"tag":65,"props":184,"children":186},{"className":185},[],[187],{"type":48,"value":188},"STYLEGUIDE.md",{"type":48,"value":190}," — from the repo's current ",{"type":43,"tag":65,"props":192,"children":194},{"className":193},[],[195],{"type":48,"value":164},{"type":48,"value":197}," 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:",{"type":43,"tag":199,"props":200,"children":201},"ul",{},[202,220,240],{"type":43,"tag":203,"props":204,"children":205},"li",{},[206,208,218],{"type":48,"value":207},"the package's ",{"type":43,"tag":57,"props":209,"children":210},{},[211,216],{"type":43,"tag":65,"props":212,"children":214},{"className":213},[],[215],{"type":48,"value":70},{"type":48,"value":217}," if it has them, otherwise the module-header doc-comment's idiomatic-usage block",{"type":48,"value":219}," — the canonical recipe (some packages ship only the latter);",{"type":43,"tag":203,"props":221,"children":222},{},[223,225,230,232,238],{"type":48,"value":224},"the modules' ",{"type":43,"tag":57,"props":226,"children":227},{},[228],{"type":48,"value":229},"doc-comments",{"type":48,"value":231}," and generated API reference (reached via the catalog's ",{"type":43,"tag":65,"props":233,"children":235},{"className":234},[],[236],{"type":48,"value":237},"Docs",{"type":48,"value":239}," link);",{"type":43,"tag":203,"props":241,"children":242},{},[243,251,253,261],{"type":43,"tag":57,"props":244,"children":245},{},[246],{"type":43,"tag":65,"props":247,"children":249},{"className":248},[],[250],{"type":48,"value":180},{"type":48,"value":252}," (capability model, object ownership, initialization) and ",{"type":43,"tag":57,"props":254,"children":255},{},[256],{"type":43,"tag":65,"props":257,"children":259},{"className":258},[],[260],{"type":48,"value":188},{"type":48,"value":262}," (conventions).",{"type":43,"tag":51,"props":264,"children":265},{},[266],{"type":48,"value":267},"Review the code against those, not against assumptions.",{"type":43,"tag":123,"props":269,"children":271},{"id":270},"what-to-review",[272],{"type":48,"value":273},"What to review",{"type":43,"tag":199,"props":275,"children":276},{},[277,295,336,353,363,380,390],{"type":43,"tag":203,"props":278,"children":279},{},[280,285,287,293],{"type":43,"tag":57,"props":281,"children":282},{},[283],{"type":48,"value":284},"Correct use of OZ primitives.",{"type":48,"value":286}," Does the code thread the capability\u002Fwitness the component defines (rather than hand-rolling ",{"type":43,"tag":65,"props":288,"children":290},{"className":289},[],[291],{"type":48,"value":292},"sender",{"type":48,"value":294}," checks or re-implementing what the library already provides), call functions with the right arguments, and handle the documented abort conditions?",{"type":43,"tag":203,"props":296,"children":297},{},[298,303,305,311,313,319,321,326,328,334],{"type":43,"tag":57,"props":299,"children":300},{},[301],{"type":48,"value":302},"Who chooses the type argument — and is it the right one.",{"type":48,"value":304}," For each OZ primitive parameterized by a witness or generic\u002F",{"type":43,"tag":65,"props":306,"children":308},{"className":307},[],[309],{"type":48,"value":310},"phantom",{"type":48,"value":312}," type, check ",{"type":43,"tag":314,"props":315,"children":316},"em",{},[317],{"type":48,"value":318},"who",{"type":48,"value":320}," 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 ",{"type":43,"tag":314,"props":322,"children":323},{},[324],{"type":48,"value":325},"right",{"type":48,"value":327}," one for the action — a privileged operation gated by a lower-privilege role's ",{"type":43,"tag":65,"props":329,"children":331},{"className":330},[],[332],{"type":48,"value":333},"Auth",{"type":48,"value":335}," (or any weaker witness than the guarantee needs) is a privilege-escalation bug.",{"type":43,"tag":203,"props":337,"children":338},{},[339,344,346,351],{"type":43,"tag":57,"props":340,"children":341},{},[342],{"type":48,"value":343},"Deviations from the reference pattern.",{"type":48,"value":345}," Compare the flow against the closest ",{"type":43,"tag":65,"props":347,"children":349},{"className":348},[],[350],{"type":48,"value":70},{"type":48,"value":352}," 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.",{"type":43,"tag":203,"props":354,"children":355},{},[356,361],{"type":43,"tag":57,"props":357,"children":358},{},[359],{"type":48,"value":360},"Copied library source.",{"type":48,"value":362}," Flag any OZ module source copied into the project instead of imported via MVR — copies miss security updates.",{"type":43,"tag":203,"props":364,"children":365},{},[366,371,373,378],{"type":43,"tag":57,"props":367,"children":368},{},[369],{"type":48,"value":370},"Invariants upheld.",{"type":48,"value":372}," Check that the code preserves the invariants the OZ components document (in their doc-comments and ",{"type":43,"tag":65,"props":374,"children":376},{"className":375},[],[377],{"type":48,"value":180},{"type":48,"value":379},") — 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.",{"type":43,"tag":203,"props":381,"children":382},{},[383,388],{"type":43,"tag":57,"props":384,"children":385},{},[386],{"type":48,"value":387},"Test coverage of the integration.",{"type":48,"value":389}," 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.",{"type":43,"tag":203,"props":391,"children":392},{},[393,398,400,406],{"type":43,"tag":57,"props":394,"children":395},{},[396],{"type":48,"value":397},"Known issue classes (heuristic).",{"type":48,"value":399}," Check the code for the classes of issue that recur in OZ-on-Sui \u002F Move code — capability handling, rounding, object ownership, initialization — and raise suspicion where the code touches them. (The library's published audits, under ",{"type":43,"tag":65,"props":401,"children":403},{"className":402},[],[404],{"type":48,"value":405},"audits\u002F",{"type":48,"value":407},", 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.",{"type":43,"tag":123,"props":409,"children":411},{"id":410},"code-quality-enforce-the-conventions",[412],{"type":48,"value":413},"Code quality — enforce the conventions",{"type":43,"tag":51,"props":415,"children":416},{},[417,419,424],{"type":48,"value":418},"Treat OpenZeppelin's Sui conventions as a first-class review dimension: report violations as ",{"type":43,"tag":57,"props":420,"children":421},{},[422],{"type":48,"value":423},"findings, not optional suggestions",{"type":48,"value":425},". The rules and the review procedure are the single source of truth — apply them, don't restate them:",{"type":43,"tag":199,"props":427,"children":428},{},[429,449,483],{"type":43,"tag":203,"props":430,"children":431},{},[432,447],{"type":43,"tag":57,"props":433,"children":434},{},[435],{"type":43,"tag":436,"props":437,"children":441},"a",{"href":438,"rel":439},"https:\u002F\u002Fraw.githubusercontent.com\u002FOpenZeppelin\u002Fcontracts-sui\u002Fmain\u002FSTYLEGUIDE.md",[440],"nofollow",[442],{"type":43,"tag":65,"props":443,"children":445},{"className":444},[],[446],{"type":48,"value":188},{"type":48,"value":448}," — the codified rules (naming, section ordering, imports, idiomatic Move 2024, testing, docs, lint suppression).",{"type":43,"tag":203,"props":450,"children":451},{},[452,466,468,474,476,481],{"type":43,"tag":57,"props":453,"children":454},{},[455],{"type":43,"tag":436,"props":456,"children":459},{"href":457,"rel":458},"https:\u002F\u002Fraw.githubusercontent.com\u002FOpenZeppelin\u002Fcontracts-sui\u002Fmain\u002F.claude\u002Fcommands\u002Fcode-quality.md",[440],[460],{"type":43,"tag":65,"props":461,"children":463},{"className":462},[],[464],{"type":48,"value":465},".claude\u002Fcommands\u002Fcode-quality.md",{"type":48,"value":467}," — the canonical procedure that checks ",{"type":43,"tag":65,"props":469,"children":471},{"className":470},[],[472],{"type":48,"value":473},".move",{"type":48,"value":475}," files against ",{"type":43,"tag":65,"props":477,"children":479},{"className":478},[],[480],{"type":48,"value":188},{"type":48,"value":482},"; run it against the code under review.",{"type":43,"tag":203,"props":484,"children":485},{},[486,491,493,499,501,507,509,514,516,521,523,529,531,536,538,543],{"type":43,"tag":57,"props":487,"children":488},{},[489],{"type":48,"value":490},"Lint is not optional.",{"type":48,"value":492}," Build and test with the project's ",{"type":43,"tag":65,"props":494,"children":496},{"className":495},[],[497],{"type":48,"value":498},"--build-env",{"type":48,"value":500}," and ",{"type":43,"tag":65,"props":502,"children":504},{"className":503},[],[505],{"type":48,"value":506},"--lint",{"type":48,"value":508}," (see ",{"type":43,"tag":65,"props":510,"children":512},{"className":511},[],[513],{"type":48,"value":119},{"type":48,"value":515}," for the exact invocation); per the styleguide, warnings must be ",{"type":43,"tag":57,"props":517,"children":518},{},[519],{"type":48,"value":520},"fixed",{"type":48,"value":522},", never suppressed with ",{"type":43,"tag":65,"props":524,"children":526},{"className":525},[],[527],{"type":48,"value":528},"#[allow(...)]",{"type":48,"value":530},". ",{"type":43,"tag":65,"props":532,"children":534},{"className":533},[],[535],{"type":48,"value":506},{"type":48,"value":537}," enforces the compiler-checkable subset independently, so if the ",{"type":43,"tag":65,"props":539,"children":541},{"className":540},[],[542],{"type":48,"value":188},{"type":48,"value":544}," fetch is momentarily unreachable, retry rather than skipping conventions.",{"type":43,"tag":51,"props":546,"children":547},{},[548,550,555],{"type":48,"value":549},"Report each violation against the ",{"type":43,"tag":65,"props":551,"children":553},{"className":552},[],[554],{"type":48,"value":188},{"type":48,"value":556}," section it breaks.",{"type":43,"tag":123,"props":558,"children":560},{"id":559},"verify-before-reporting",[561],{"type":48,"value":562},"Verify before reporting",{"type":43,"tag":51,"props":564,"children":565},{},[566,568,573],{"type":48,"value":567},"The checks above optimize for catching issues, so before writing anything, try to ",{"type":43,"tag":314,"props":569,"children":570},{},[571],{"type":48,"value":572},"disprove",{"type":48,"value":574}," each finding: quote the exact line and confirm the problem is really there; confirm it is a genuine deviation and not an intentional, documented choice; and confirm you can state a concrete one-line fix. Drop whatever does not survive all three, and keep the severity bar high — a short review a developer trusts beats a long one they skim.",{"type":43,"tag":123,"props":576,"children":578},{"id":577},"output",[579],{"type":48,"value":580},"Output",{"type":43,"tag":51,"props":582,"children":583},{},[584,586,592,594,600],{"type":48,"value":585},"Produce one review, findings ordered by severity. Each finding: ",{"type":43,"tag":65,"props":587,"children":589},{"className":588},[],[590],{"type":48,"value":591},"file:line",{"type":48,"value":593}," — what's wrong (one clause) → the fix (one clause) — and the OZ ",{"type":43,"tag":65,"props":595,"children":597},{"className":596},[],[598],{"type":48,"value":599},"example",{"type":48,"value":601}," or doc-comment it deviates from, so the developer can compare directly. A short preamble is useful — the scope\u002Fboundary call and the build\u002Ftest\u002Flint status — and on a clean integration a single \"verified and cleared\" line is fine; keep the body to findings, not a recap.",{"type":43,"tag":51,"props":603,"children":604},{},[605,607,613,615,621,623,628],{"type":48,"value":606},"If the project builds, run its checks first (",{"type":43,"tag":65,"props":608,"children":610},{"className":609},[],[611],{"type":48,"value":612},"sui move build",{"type":48,"value":614}," \u002F ",{"type":43,"tag":65,"props":616,"children":618},{"className":617},[],[619],{"type":48,"value":620},"test",{"type":48,"value":622},", per ",{"type":43,"tag":65,"props":624,"children":626},{"className":625},[],[627],{"type":48,"value":119},{"type":48,"value":629},") so the review reflects compiling code, and report build\u002Ftest failures separately from the pattern findings.",{"type":43,"tag":123,"props":631,"children":633},{"id":632},"boundaries",[634],{"type":48,"value":635},"Boundaries",{"type":43,"tag":199,"props":637,"children":638},{},[639,651,661],{"type":43,"tag":203,"props":640,"children":641},{},[642,644,649],{"type":48,"value":643},"Reviews the ",{"type":43,"tag":57,"props":645,"children":646},{},[647],{"type":48,"value":648},"integrator's",{"type":48,"value":650}," code — how it uses the library — not the OpenZeppelin library internals themselves.",{"type":43,"tag":203,"props":652,"children":653},{},[654,659],{"type":43,"tag":57,"props":655,"children":656},{},[657],{"type":48,"value":658},"Not a security audit",{"type":48,"value":660}," — no exhaustive threat modeling or completeness guarantee; recommend a formal audit for production code.",{"type":43,"tag":203,"props":662,"children":663},{},[664,666,671,673,678],{"type":48,"value":665},"Complements ",{"type":43,"tag":65,"props":667,"children":669},{"className":668},[],[670],{"type":48,"value":104},{"type":48,"value":672}," (integration) and ",{"type":43,"tag":65,"props":674,"children":676},{"className":675},[],[677],{"type":48,"value":119},{"type":48,"value":679}," (scaffolding); it neither builds nor scaffolds.",{"items":681,"total":809},[682,698,705,719,732,742,752,764,776,787,798],{"slug":104,"name":104,"fn":683,"description":684,"org":685,"tags":686,"stars":25,"repoUrl":26,"updatedAt":697},"develop secure smart contracts with OpenZeppelin","Develop secure smart contracts using OpenZeppelin Contracts libraries. Use when users need to integrate OpenZeppelin library components — including token standards (ERC20, ERC721, ERC1155), access control (Ownable, AccessControl, AccessManager), security primitives (Pausable, ReentrancyGuard), governance (Governor, timelocks), or accounts (multisig, account abstraction) — into existing or new contracts. Covers pattern discovery from library source, CLI contract generators, and library-first integration. Supports Solidity, Cairo, Stylus, Stellar, and Sui Move.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[687,690,693,694],{"name":688,"slug":689,"type":15},"Access Control","access-control",{"name":691,"slug":692,"type":15},"Security","security",{"name":23,"slug":24,"type":15},{"name":695,"slug":696,"type":15},"Solidity","solidity","2026-07-13T06:04:32.666273",{"slug":4,"name":4,"fn":5,"description":6,"org":699,"tags":700,"stars":25,"repoUrl":26,"updatedAt":27},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[701,702,703,704],{"name":13,"slug":14,"type":15},{"name":17,"slug":18,"type":15},{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"slug":706,"name":706,"fn":707,"description":708,"org":709,"tags":710,"stars":25,"repoUrl":26,"updatedAt":718},"setup-cairo-contracts","set up Cairo smart contract projects","Set up a Cairo smart contract project with OpenZeppelin Contracts for Cairo on Starknet. Use when users need to: (1) create a new Scarb\u002FStarknet project, (2) add OpenZeppelin Contracts for Cairo dependencies to Scarb.toml, (3) configure individual or umbrella OpenZeppelin packages, or (4) understand Cairo import conventions and component patterns for OpenZeppelin.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[711,714,715],{"name":712,"slug":713,"type":15},"Engineering","engineering",{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},"Web3","web3","2026-07-13T06:04:17.186825",{"slug":720,"name":720,"fn":721,"description":722,"org":723,"tags":724,"stars":25,"repoUrl":26,"updatedAt":731},"setup-solidity-contracts","set up Solidity smart contract projects","Set up a Solidity smart contract project with OpenZeppelin Contracts. Use when users need to: (1) create a new Hardhat or Foundry project, (2) install OpenZeppelin Contracts dependencies for Solidity, (3) configure remappings for Foundry, or (4) understand Solidity import conventions for OpenZeppelin.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[725,726,729,730],{"name":712,"slug":713,"type":15},{"name":727,"slug":728,"type":15},"Foundry","foundry",{"name":23,"slug":24,"type":15},{"name":695,"slug":696,"type":15},"2026-07-13T06:04:29.360325",{"slug":733,"name":733,"fn":734,"description":735,"org":736,"tags":737,"stars":25,"repoUrl":26,"updatedAt":741},"setup-stellar-contracts","set up Stellar Soroban smart contract projects","Set up a Stellar\u002FSoroban smart contract project with OpenZeppelin Contracts for Stellar. Use when users need to: (1) install Stellar CLI and Rust toolchain for Soroban, (2) create a new Soroban project, (3) add OpenZeppelin Stellar dependencies to Cargo.toml, or (4) understand Soroban import conventions and contract patterns for OpenZeppelin.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[738,739,740],{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},"2026-07-13T06:04:23.807685",{"slug":743,"name":743,"fn":744,"description":745,"org":746,"tags":747,"stars":25,"repoUrl":26,"updatedAt":751},"setup-stylus-contracts","set up Stylus smart contract projects","Set up a Stylus smart contract project with OpenZeppelin Contracts for Stylus on Arbitrum. Use when users need to: (1) install Rust toolchain and WASM target for Stylus, (2) create a new Cargo Stylus project, (3) add OpenZeppelin Stylus dependencies to Cargo.toml, or (4) understand Stylus import conventions and storage patterns for OpenZeppelin.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[748,749,750],{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},"2026-07-13T06:04:18.638516",{"slug":119,"name":119,"fn":753,"description":754,"org":755,"tags":756,"stars":25,"repoUrl":26,"updatedAt":763},"set up Sui Move smart contracts","Set up a Sui Move smart contract project with OpenZeppelin Contracts for Sui. Use when users need to: (1) install the Sui CLI and Move toolchain, (2) create a new Sui Move package, (3) discover and add OpenZeppelin Sui dependencies to Move.toml via the Move Registry (MVR), (4) learn the integration pattern from the library's examples and API docs before implementing, or (5) understand Sui Move import conventions and build\u002Ftest commands for OpenZeppelin.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[757,758,761,762],{"name":13,"slug":14,"type":15},{"name":759,"slug":760,"type":15},"CLI","cli",{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},"2026-07-16T05:59:21.671811",{"slug":765,"name":765,"fn":766,"description":767,"org":768,"tags":769,"stars":25,"repoUrl":26,"updatedAt":775},"upgrade-cairo-contracts","upgrade Cairo smart contracts on Starknet","Upgrade Cairo smart contracts using OpenZeppelin's UpgradeableComponent on Starknet. Use when users need to: (1) make Cairo contracts upgradeable via replace_class_syscall, (2) integrate the OpenZeppelin UpgradeableComponent, (3) understand Starknet's class-based upgrade model vs EVM proxy patterns, (4) ensure storage compatibility across upgrades, (5) guard upgrade functions with access control, or (6) test upgrade paths for Cairo contracts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[770,773,774],{"name":771,"slug":772,"type":15},"Migration","migration",{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},"2026-07-13T06:04:25.126377",{"slug":777,"name":777,"fn":778,"description":779,"org":780,"tags":781,"stars":25,"repoUrl":26,"updatedAt":786},"upgrade-solidity-contracts","upgrade Solidity smart contracts with proxies","Upgrade Solidity smart contracts using OpenZeppelin proxy patterns. Use when users need to: (1) make contracts upgradeable with UUPS, Transparent, or Beacon proxies, (2) write initializers instead of constructors, (3) use the Hardhat or Foundry upgrades plugins, (4) understand storage layout rules and ERC-7201 namespaced storage, (5) validate upgrade safety, (6) manage proxy deployments and upgrades, or (7) understand upgrade restrictions between OpenZeppelin Contracts major versions.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[782,783,784,785],{"name":771,"slug":772,"type":15},{"name":691,"slug":692,"type":15},{"name":23,"slug":24,"type":15},{"name":695,"slug":696,"type":15},"2026-07-13T06:04:20.958319",{"slug":788,"name":788,"fn":789,"description":790,"org":791,"tags":792,"stars":25,"repoUrl":26,"updatedAt":797},"upgrade-stellar-contracts","upgrade Stellar Soroban smart contracts","Upgrade Stellar\u002FSoroban smart contracts using OpenZeppelin's upgradeable module. Use when users need to: (1) make Soroban contracts upgradeable via native WASM replacement, (2) use Upgradeable or UpgradeableMigratable derive macros, (3) implement atomic upgrade-and-migrate patterns with an Upgrader contract, (4) ensure storage key compatibility across upgrades, or (5) test upgrade paths for Soroban contracts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[793,794,795,796],{"name":13,"slug":14,"type":15},{"name":771,"slug":772,"type":15},{"name":691,"slug":692,"type":15},{"name":23,"slug":24,"type":15},"2026-07-13T06:04:31.398663",{"slug":799,"name":799,"fn":800,"description":801,"org":802,"tags":803,"stars":25,"repoUrl":26,"updatedAt":808},"upgrade-stylus-contracts","upgrade Stylus smart contracts","Upgrade Stylus smart contracts using OpenZeppelin proxy patterns on Arbitrum. Use when users need to: (1) make Stylus Rust contracts upgradeable with UUPS or Beacon proxies, (2) understand Stylus-specific proxy mechanics (logic_flag, WASM reactivation), (3) integrate UUPSUpgradeable with access control, (4) ensure storage compatibility across upgrades, or (5) test upgrade paths for Stylus contracts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[804,805,806,807],{"name":771,"slug":772,"type":15},{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},"2026-07-13T06:04:28.005287",11,{"items":811,"total":809},[812,819,826,832,839,845,851],{"slug":104,"name":104,"fn":683,"description":684,"org":813,"tags":814,"stars":25,"repoUrl":26,"updatedAt":697},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[815,816,817,818],{"name":688,"slug":689,"type":15},{"name":691,"slug":692,"type":15},{"name":23,"slug":24,"type":15},{"name":695,"slug":696,"type":15},{"slug":4,"name":4,"fn":5,"description":6,"org":820,"tags":821,"stars":25,"repoUrl":26,"updatedAt":27},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[822,823,824,825],{"name":13,"slug":14,"type":15},{"name":17,"slug":18,"type":15},{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"slug":706,"name":706,"fn":707,"description":708,"org":827,"tags":828,"stars":25,"repoUrl":26,"updatedAt":718},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[829,830,831],{"name":712,"slug":713,"type":15},{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},{"slug":720,"name":720,"fn":721,"description":722,"org":833,"tags":834,"stars":25,"repoUrl":26,"updatedAt":731},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[835,836,837,838],{"name":712,"slug":713,"type":15},{"name":727,"slug":728,"type":15},{"name":23,"slug":24,"type":15},{"name":695,"slug":696,"type":15},{"slug":733,"name":733,"fn":734,"description":735,"org":840,"tags":841,"stars":25,"repoUrl":26,"updatedAt":741},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[842,843,844],{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},{"slug":743,"name":743,"fn":744,"description":745,"org":846,"tags":847,"stars":25,"repoUrl":26,"updatedAt":751},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[848,849,850],{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"name":716,"slug":717,"type":15},{"slug":119,"name":119,"fn":753,"description":754,"org":852,"tags":853,"stars":25,"repoUrl":26,"updatedAt":763},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[854,855,856,857],{"name":13,"slug":14,"type":15},{"name":759,"slug":760,"type":15},{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15}]