solidity-coding

Enforces Solidity coding standards including pragma, naming, layout, and OpenZeppelin usage for contracts.

Updated Mar 20, 2026
One-click install
npx skills add https://github.com/0bkevin/aethertable --skill solidity-coding
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: solidity-coding
Source: https://github.com/0bkevin/aethertable/tree/main/.agents/skills/solidity-coding
Command: npx skills add https://github.com/0bkevin/aethertable --skill solidity-coding

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Before writing or modifying any Solidity contract, developers need consistent standards to avoid pragma drift, naming inconsistencies, insecure patterns, and misconfigurations.

Core Features & Use Cases

  • Enforce pragma version consistency (e.g., ^0.8.19) across all files and modules.
  • Standardize project layout and file organization (src, test, scripts) to improve maintainability.
  • Guide OpenZeppelin library selection and import practices to reduce risk.
  • Establish coding conventions for documentation, error handling, events, and naming.
  • Provide guardrails for oracle integration, upgradeability, and anti-patterns.
  • Promote NatSpec usage and inline documentation for public/external functions.
  • Document project structure and configuration management for Foundry/Remix workflows.

Use cases: a team kicks off a Solidity project and runs this skill to automatically validate the initial contract skeleton; a reviewer applies it to ensure new PRs adhere to standards; a maintainer uses it to audit and refactor existing contracts.

Quick Start

Invoke this skill before writing or editing any Solidity contract to enforce versioning, naming, layout, and security best practices.

Frequently Asked Questions about solidity-coding

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce Solidity coding standards before writing smart contracts?

To enforce Solidity coding standards before writing smart contracts, apply consistent pragma version controls, naming conventions, and OpenZeppelin library usage rules. This reduces security risks and maintenance costs by validating project layout and anti-patterns early.

What Solidity pragma version and OpenZeppelin library versions should I standardize on?

Standardize Solidity pragma versions on consistent ^0.8.19 across all files and use OpenZeppelin 4.9.x libraries. Consistent pragma versioning and library selection reduce security risks and prevent pragma drift across modules.

How do I set up a Foundry project layout for Solidity smart contracts?

Set up a Foundry project layout for Solidity smart contracts by organizing directories into src, test, and scripts folders. Standardized project layout improves maintainability and ensures remappings and configuration management align with coding conventions.

Does this approach work with existing Solidity contracts that need refactoring?

Yes, this approach works with existing Solidity contracts that need refactoring. Maintainers can audit existing code to apply NatSpec documentation, custom errors, event design rules, and anti-pattern guardrails for upgradeability and oracle integration.

Why use custom errors and NatSpec in Solidity contract development?

Use custom errors and NatSpec in Solidity contract development to standardize error handling and document public or external functions. Inline comments explaining advanced keywords and consistent event design reduce maintenance costs and improve code readability.

What are common Solidity anti-patterns to avoid during a contract audit?

Common Solidity anti-patterns to avoid during a contract audit include pragma drift, naming inconsistencies, insecure OpenZeppelin import practices, and misconfigured oracle integration. Applying coding guardrails early prevents these security risks and maintenance issues.