mindrally/skills

solidity

Best practices for secure, gas-efficient Solidity smart contract development and Web3 frontend integration.

Hot #1457 First seen Jan 25, 2026

Installation

$ npx skills add mindrally/skills --skill solidity

Summary

  • 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.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from mindrally/skills · top by installs.

npx skills add mindrally/skills

Browse all from mindrally/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 258
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,356 B
  • docs SUMMARY.md 3,313 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 663 installs

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