OpenZeppelin Skills plugin

Skills for building and upgrading smart contracts on OpenZeppelin libraries in Solidity, Cairo, Stylus, Stellar and Sui

  • 223 ★ on the repository
  • Last commit
  • AGPL-3.0
Plugin

Extended access

Why this level

  • The contract generation skill runs the contracts-cli npm package and uses the network
  • Deployed contracts control value, so mistakes are costly and an audit stays mandatory
All reasons and checks

openzeppelin/openzeppelin-skills

Install

In your terminal, with SkillFoxx CLI

npx skillfoxx add plugins/openzeppelin-skills

Detects the agents on your machine, shows the access level and pins the version.

Other ways to install

Access and checks

How we review

Extended accessThe tool runs code or makes network calls and only reads external data.

  • The contract generation skill runs the contracts-cli npm package and uses the network
  • Deployed contracts control value, so mistakes are costly and an audit stays mandatory

This is third-party code. Review the repository files before installing.

What it does

OpenZeppelin Skills is a set of twelve skills from OpenZeppelin for secure smart contract development. develop-secure-contracts guides the agent in building contracts on OpenZeppelin Contracts libraries and uses the @openzeppelin/contracts-cli package to generate reference implementations. Five platforms get a pair of skills for project setup and contract upgrades: Solidity, Cairo, Stylus, Stellar and Sui Move. review-sui-contracts reviews an integration of OpenZeppelin Contracts for Sui, and migrate-defender-to-cre assesses, implements and validates the migration of Defender workflows to Chainlink CRE. The skills install through the Skills CLI, as a Claude Code plugin or by copying the folders.

Who it is for. Smart contract developers who use OpenZeppelin libraries and work across several blockchain platforms.

Good fit when

  • You need to set up a new Solidity, Cairo, Stylus, Stellar or Sui project with OpenZeppelin libraries
  • Contracts built on OpenZeppelin must move to a newer library version
  • You need to review an OpenZeppelin Contracts for Sui integration in a Move project
  • Defender workflows must migrate to Chainlink CRE

Not a fit when

  • You need a full audit before mainnet launch: the skills guide development and do not replace auditors
  • The project does not use OpenZeppelin: the skills are built around its libraries
  • You need skills for networks beyond the five listed platforms

Example request

Set up a Solidity project with OpenZeppelin Contracts and build an ERC-20 token with role-based access control

Limitations

The license is AGPL-3.0, so check whether it fits your project. develop-secure-contracts needs the @openzeppelin/contracts-cli package and network access at install. The skills guide development, but contract deployment and pre-launch security checks stay with your team. Each platform needs its own toolchain: the compiler, framework and a testnet wallet are not installed for you without your approval.

How to disable. Delete the skill folders from ~/.claude/skills/ or run /plugin uninstall openzeppelin-skills if you installed the plugin.

FAQ

Which platforms are supported?

Solidity, Cairo, Stylus, Stellar and Sui Move. Each has a project setup skill, all but Sui have a contract upgrade skill, and Sui has a separate integration review skill.

How do I install the skills in Claude Code?

Through the plugin: /plugin marketplace add OpenZeppelin/openzeppelin-skills and /plugin install openzeppelin-skills. Or with npx skills add OpenZeppelin/openzeppelin-skills, or by copying skills/ into ~/.claude/skills.

What is Defender and why a migration skill?

Defender is an OpenZeppelin service for automating contract operations. migrate-defender-to-cre helps assess Defender workflows, implement them on Chainlink CRE and validate the result; reference files live under references.

What is contracts-cli for?

The @openzeppelin/contracts-cli package generates reference contract implementations. develop-secure-contracts uses them so the agent studies recommended integration patterns and does not invent a structure from scratch.

Do the skills replace an audit?

No. They steer the agent while developing on vetted libraries, but an independent audit before mainnet remains a separate team step.

Discussion

No questions or reviews yet.

Plugins
Official

Eight Stellar Development Foundation skills: Rust contracts, SDKs, RPC, assets, wallets and security reviews

SkillMinimal access59Repository stars
Official

A Solana Foundation skill for Solana development: Anchor and Pinocchio, @solana/kit clients, wallets, Surfpool and LiteSVM testing, security

SkillExtended access590Repository stars

Nine skills for building on Chainlink: CRE, CCIP, Data Feeds, Data Streams, VRF and other network products

SkillExtended access128Repository stars

Corrections to what AI agents know about Ethereum: current gas, contract addresses, L2s, standards and smart contract security

SkillMinimal access304Repository stars

73 skills for a delivery pipeline: plan, code, review and QA, ending in a ready, labeled PR in your own repository.

SkillBroad access276Repository stars

The official OpenHands registry: 71 skills and 11 plugins for code review, GitHub, Bitbucket, Docker and CI, usable elsewhere.

SkillExtended access183Repository stars

README in short

The README briefly describes the set: three install routes, a table of twelve skills with their purposes and a section on the Contracts CLI that develop-secure-contracts uses. Contributor notes on principles and testing sit in the dev folder.

README badge

Original SKILL.md

---
name: develop-secure-contracts
description: "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."
license: AGPL-3.0-only
metadata:
  author: OpenZeppelin
---

# Develop Secure Smart Contracts with OpenZeppelin

## Core Workflow

### Understand the Request Before Responding

For conceptual questions ("How does Ownable work?"), explain without generating code. For implementation requests, proceed with the workflow below.

### CRITICAL: Always Read the Project First

Before generating code or suggesting changes:

1. **Search the user's project** for existing contracts (`Glob` for `**/*.sol`, `**/*.cairo`, `**/*.rs`, `**/*.move`, etc.)
2. **Read the relevant contract files** to understand what already exists
3. **Default to integration, not replacement** — when users say "add pausability" or "make it upgradeable", they mean modify their existing code, not generate something new. Only replace if explicitly requested ("start fresh", "replace this").

If a file cannot be read, surface the failure explicitly — report the path attempted and the reason. Ask whether the path is correct. Never silently fall back to a generic response as if the file does not exist.

### Fundamental Rule: Prefer Library Components Over Custom Code

Before writing ANY logic, search the OpenZeppelin library for an existing component:

1. **Exact match exists?** Import and use it directly — inherit, implement its trait, compose with it. Done.
2. **Close match exists?** Import and extend it — override only functions the library marks as overridable (virtual, hooks, configurable parameters).
3. **No match exists?** Only then write custom logic. Confirm by browsing the library's directory structure first.

**NEVER copy or embed library source code into the user's contract.** Always import from the dependency so the project receives security updates. Never hand-write what the library already provides:
- Never write a custom `paused` modifier when `Pausable` or `ERC20Pausable` exists
- Never write `require(msg.sender == owner)` when `Ownable` exists
- Never implement ERC165 logic when the library's base contracts already handle it

### Methodology

The primary workflow is **pattern discovery from library source code**:

1. Inspect what the user's project already imports
2. Read the dependency source and docs in the project's installed packages

Report a problem