Claude/ChatGPT Prompt to Build a Solidity ERC-20 Token with Tests

What this prompt does

This prompt makes the AI act as a senior smart contract engineer and produce a secure ERC-20 token plus a Foundry test suite — real code, not pseudocode. Because a deployed contract is immutable, the prompt treats the tests as the deliverable that matters most: happy path, access control, mint-cap enforcement, pause/unpause, a reentrancy probe, and fuzz tests for transfer and approve. It builds on OpenZeppelin primitives rather than rolling crypto by hand, which is the right default for production tokens.

The placeholders pin the output to your token. [version] sets the Solidity compiler (the default 0.8.24 gives you built-in overflow checks), [token_name] names the token and symbol, [supply_rules] defines the cap and minting behaviour so the contract enforces a hard limit, and [chain] notes the target so the model can flag chain-specific considerations. Custom errors, events on every state change, and NatSpec on external functions are all requested, which keeps the contract auditable.

When to use it

• You need an ERC-20 token wired with OpenZeppelin ownership, pausability, and a hard mint cap.
• A client asked for an on-chain token and you want the tests to prove access control actually holds.
• You want Foundry fuzz tests surfacing overflow/underflow edge cases on transfer and approve.
• You're verifying a reentrancy guard before any testnet deploy.
• You want custom errors and full events instead of string reverts and silent state changes.
• You need the exact forge commands to build, test, and report coverage in one place.

Example output

You get three things, each fenced: one code block for the contract, one for the Foundry test file, and a short list of forge commands. The contract extends OpenZeppelin's ERC20, Ownable, and Pausable with a mint cap and custom errors. The test file covers the happy path, access-control reverts, mint-cap enforcement, pause/unpause behaviour, a reentrancy probe, and fuzz tests for transfer and approve. The commands cover forge build, forge test, and coverage reporting so you can run the suite immediately.

Pro tips

• Keep [version] at 0.8.24 or later unless you have a reason not to — pre-0.8 Solidity lacks built-in overflow protection and the fuzz tests assume it.
• Make [supply_rules] explicit: "10M cap, owner-minted, no burn" produces enforceable logic, whereas "limited supply" leaves the cap ambiguous.
• Run the reentrancy probe and fuzz tests from deliverables 4 and 5 before you even think about a testnet deploy — that's the whole point of the suite.
• Set [chain] honestly; a token on Base behaves differently at deploy time than one on mainnet, and naming it lets the model flag gas and tooling notes.
• If you change the supply model after generating, regenerate the tests too — a stale mint-cap test gives false confidence.
• Review the NatSpec the model writes; it documents intent, but you should confirm it matches the constraints you actually want.