developing-smart-contracts
Skill126 starsChanged 3 months agoApache-2.0View on GitHub
Solidity smart contract development guidelines for Lineth blockchain. Use when writing, reviewing, or refactoring Solidity contracts, or when the user asks about Solidity best practices, contract structure, or NatSpec docstrings. Covers NatSpec documentation, naming conventions, file layout, and code style.
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 48
Read individual rule files for detailed explanations and code examples (correct and incorrect).
- Very specific: line 88
Every contract/interface NatSpec block must include @author Consensys Software Inc.
- Distinctive: line 108
Always use named imports. Always insert a blank line after imports.
- Distinctive: line 135
Follow this sequence when writing or modifying Solidity contracts:
- Very specific: line 151
Review gas patterns: check for unnecessary memory copies, repeated storage reads, and missing batch limits.
- Distinctive: line 152
Commit: after passing the checklist below.
- Distinctive: line 156
Before making a commit, please verify:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Lineth Smart Contract Development
Best practices for developing Solidity smart contracts on Lineth blockchain. Contains rules covering documentation, naming, structure, and code style.
Reference: Lineth Contract Style Guide
When to Apply
Reference these guidelines when:
- Writing new Solidity contracts for Lineth
- Reviewing smart contract code
- Refactoring existing contracts
- Adding NatSpec docstring documentation
- Setting up contract file structure
Licenses
// SPDX-License-Identifier: Apache-2.0 OR MIT
Solidity Pragma
- Contracts:
0.8.33(exact) - Interfaces, abstract contracts, libraries:
^0.8.33(caret)
Rule Categories by Priority
| Priority | Category | Impact | Rule File |
| 1 | Gas optimization | CRITICAL | rules/gas-optimization.md |
| 2 | NatSpec Docstrings | HIGH | rules/natspec.md |
| 3 | File Layout | HIGH | rules/file-layout.md |
| 4 | Naming | HIGH | rules/naming-conventions.md |
| 5 | Imports | MEDIUM | rules/imports.md |
| 6 | Visibility | MEDIUM | rules/visibility.md |
| 7 | General Rules | MEDIUM | rules/general-rules.md |
Read individual rule files for detailed explanations and code examples (correct and incorrect).
Quick Reference
1. Gas Optimization (CRITICAL)
Gas efficiency is critical for Lineth contracts. Apply these rules unless there is a documented safety, audit, or readability reason to deviate.
// Correct: external + calldata, cache storage reads
function submit(bytes32[] calldata _proofs) external {
uint256 current = fee;
require(current != 0, FeeNotSet());
_verify(_proofs, current);
}
// Incorrect: public + memory, repeated storage reads
function submit(bytes32[] memory _proofs) public {
require(fee != 0, FeeNotSet());
_verify(_proofs, fee);
}See rules/gas-optimization.md for details.
2. NatSpec Docstrings (HIGH)
ALWAYS use NatSpec docstrings for all public/external items.
// Correct: complete NatSpec with @notice, @param (in signature order), @return
/**
* @notice Sends a message to L2.
* @param _to The recipient address on L2.
* @param _fee The fee amount in wei.
* @return messageHash The hash of the sent message.
*/
function sendMessage(address _to, uint256 _fee) external payable returns (bytes32 messageHash);Every contract/interface NatSpec block must include @author Consensys Software Inc. and @custom:security-contact security-report@linea.build.
Consult rules/natspec.md for NatSpec docstring rules and examples
3. File Layout (HIGH)
Interface structure:
- Structs → 2. Enums → 3. Events → 4. Errors → 5. External Functions
Contract structure:
- Using statements → 2. Constants → 3. State variables → 4. Structs → 5. Enums → 6. Events → 7. Errors → 8. Modifiers → 9. Functions
See rules/file-layout.md for templates.
4. Naming Conventions (HIGH)
See rules/naming-conventions.md for symbol naming conventions.
5. Imports (MEDIUM)
Always use named imports. Always insert a blank line after imports.
// Correct: named imports with blank line before NatSpec/contract declaration
import { IMessageService } from "../interfaces/IMessageService.sol";
import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol";
/**
* @title Brief description.
* @author Consensys Software Inc.
* @custom:security-contact security-report@linea.build
*/
contract MessageService is IMessageService, Ownable {See rules/imports.md for details.
6. Visibility (MEDIUM)
See rules/visibility.md for rules on applying visibility modifiers (internal, external, public, etc).
7. General Rules (MEDIUM)
See rules/general-rules.md for inheritance and general style rules
Development Workflow
Follow this sequence when writing or modifying Solidity contracts:
- Write/modify contract applying rules from the priority table above.
- Compile and fix errors:
pnpm -F contracts run build - Run linter and fix warnings:
pnpm -F contracts run lint:fix - Run tests to verify behavior:
pnpm -F contracts run test - Verify NatSpec coverage: confirm all public/external functions, events, and errors have complete docstrings with
@notice,@param(in signature order), and@return. - Review gas patterns: check for unnecessary
memorycopies, repeated storage reads, and missing batch limits. - Commit after passing the checklist below.
Commit Checklist
Before making a commit, please verify:
- Rules on licenses and Solidity pragma have been applied
- All public items have NatSpec docstrings (
@notice,@param,@return) - All rules in
rules/*.mdhave been applied - Linting passes (
pnpm -F contracts run lint:fix)
Commands
For commands for testing and linting, refer to rules/commands.md
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- contracts/AGENTS.mdAGENTS.md
- coordinator/AGENTS.mdAGENTS.md
- e2e/AGENTS.mdAGENTS.md
- maru/AGENTS.mdAGENTS.md
- postman/AGENTS.mdAGENTS.md
- prover/AGENTS.mdAGENTS.md
- prover-ray/AGENTS.mdAGENTS.md
- tracer/AGENTS.mdAGENTS.md
- transaction-exclusion-api/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/documentation.mdcCursor rule
- .cursor/rules/security-logging-guidelines/EXAMPLES.mdCursor rule
- .cursor/rules/security-logging-guidelines/RULES.mdCursor rule
- .cursor/rules/smart-contract-guidelines/RULE.mdCursor rule
- .cursor/rules/versioning-guidelines/EXAMPLES.mdCursor rule
- .cursor/rules/versioning-guidelines/RULES.mdCursor rule
- linea-dependency-maintenanceSkill
- squash-bugbotSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

