immutable-and-constant

Purpose

Identify state variables that are assigned a fixed value and never modified, then promote them to constant (compile-time-known values) or immutable (constructor-set-once values). Both eliminate storage slots entirely: constant values are inlined as bytecode literals (zero runtime read cost); immutable values are baked into deployed bytecode and read via PUSH opcode (~3 gas vs 2,100 gas cold SLOAD).

When to Use This Skill

Use when:

• Claude is writing state variable declarations at contract scope
• Claude is writing or reviewing a constructor body
• The user asks about gas costs of state variable reads
• Claude reviews a contract where owner, token addresses, or config values are stored as regular address or uint256 state variables but never reassigned
• A modifier reads a state variable on every call (e.g., onlyOwner)

When NOT to Use This Skill

Do NOT use for:

• Variables that are reassigned in any function after the constructor — those require regular storage; immutable is disqualified if reassigned outside the constructor
• Variables set in an initialize() function in upgradeable contracts — immutable requires assignment in the constructor only; initializer patterns use storage
• immutable in proxy implementation contracts — the value lives in the implementation's bytecode, not the proxy's storage; use with care
• Variables that must be updatable (e.g., a transferable owner address) — use regular storage with appropriate access control

Platform Detection

This skill applies when the following markers are present:

File extensions: *.sol Project markers: foundry.toml or hardhat.config.ts in project root Language markers:

• pragma solidity ^0.8.x;
• contract declarations with state variable sections
• constructor( present or state variables with initializers

Do not apply to Vyper (.vy) or non-EVM languages.

Quick Reference

Decision tree — apply in order for each state variable: