agentleFS
MindrallyMindrally/skills/solidity/SKILL.md

solidity

Skill275 starsChanged 34 days agoApache-2.0View on GitHub

Best practices for secure, gas-efficient Solidity smart contract development and Web3 frontend integration. Use when writing or reviewing Solidity contracts, hardening against reentrancy and access-control bugs, optimizing gas usage, setting up Hardhat/Foundry testing and static analysis, or wiring a React frontend to wallets, providers, and on-chain transactions.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 12 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use explicit visibility modifiers and NatSpec documentation

    line 21
  2. Distinctive:

    Use proxy patterns for upgradeable contracts

    line 27
  3. Distinctive:

    Follow Checks-Effects-Interactions pattern against reentrancy

    line 29
  4. Distinctive:

    Use OpenZeppelin's AccessControl for permissions

    line 33
  5. Distinctive:

    Use Pausable pattern for circuit breakers

    line 35
  6. Distinctive:

    Use SafeERC20 for token interactions

    line 37
  7. Distinctive:

    Use immutable variables for constructor-set values

    line 44
  8. Distinctive:

    Use custom errors instead of revert strings

    line 45
  9. Distinctive:

    Use appropriate data types

    line 47
  10. Distinctive:

    Use pre-commit linting tools

    line 54
  11. Distinctive:

    Keep frontend code that talks to contracts type-safe and explicit — generate TypeScript types from ABIs (e.g.

    line 72
  12. Very specific:

    Treat wallet connection, chain/network state, and transaction status as explicit, typed state (connected/connecting/wrong-network/error), …

    line 73
  13. Distinctive:

    Never trust client-side reads of contract state for authorization decisions — always re-verify on-chain in the contract itself

    line 76

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Solidity

This skill covers best practices for Solidity smart contract development, including security patterns, gas optimization, testing/tooling, and integrating contracts with a Web3 React frontend.

Core Principles

  • Cut the fluff. Code or detailed explanations only
  • Maintain brevity while prioritizing accuracy and depth
  • Answer first, explain later when needed

Code Structure & Security

  • Use explicit visibility modifiers and NatSpec documentation
  • Apply function modifiers to reduce redundancy
  • Follow naming conventions:
    • CamelCase for contracts
    • PascalCase for interfaces (prefix with "I")
  • Implement Interface Segregation Principle
  • Use proxy patterns for upgradeable contracts
  • Emit comprehensive events for state changes
  • Follow Checks-Effects-Interactions pattern against reentrancy

Security Best Practices

  • Use OpenZeppelin's AccessControl for permissions
  • Require Solidity 0.8.0+ for overflow/underflow protection
  • Use Pausable pattern for circuit breakers
  • Implement ReentrancyGuard for additional protection
  • Use SafeERC20 for token interactions
  • Employ pull-over-push payment patterns
  • Implement timelocks and multisig controls for sensitive operations

Gas Optimization

  • Optimize gas consumption (deployment and runtime)
  • Use immutable variables for constructor-set values
  • Use custom errors instead of revert strings
  • Pack storage variables efficiently
  • Use appropriate data types

Tools & Analysis

  • Integrate Slither and Mythril for static analysis
  • Leverage Hardhat's testing and development environment
  • Implement robust CI/CD pipelines
  • Use pre-commit linting tools

Advanced Patterns

  • Chainlink VRF for randomness
  • Strategic assembly use with extensive documentation
  • State machine patterns for complex logic
  • ERC20Snapshot, ERC20Permit, and ERC20Votes for specialized tokens

Testing & Quality

  • Comprehensive unit, integration, and end-to-end testing
  • Property-based testing approaches
  • High coverage targets
  • Regular security audits

Web3 Frontend Integration

  • Keep frontend code that talks to contracts type-safe and explicit — generate TypeScript types from ABIs (e.g. via TypeChain or wagmi/viem codegen) rather than hand-writing contract call signatures
  • Treat wallet connection, chain/network state, and transaction status as explicit, typed state (connected/connecting/wrong-network/error), not implicit booleans
  • Surface transaction lifecycle clearly in the UI: submitted, pending confirmation, confirmed, reverted — never assume a submitted transaction succeeded
  • Validate and simulate transactions (e.g. eth_call/gas estimation) before prompting the user to sign, to catch reverts early
  • Never trust client-side reads of contract state for authorization decisions — always re-verify on-chain in the contract itself
  • Handle provider/RPC failures and user rejection of signature requests as expected, recoverable error states

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.