You want one contract that issues swords, potions and keys, each with its own token id, and you want to know who is allowed to create new tokens. The agent writes the Solidity, runs your compile and test commands on a local chain or a test network, and shows each step as a card with the real result. This guide follows the minting function, because whoever can call it decides how many tokens exist. A deployed contract cannot be changed, so everything here stays on a local chain or a test network, whose coins have no value. Beginners can follow the four steps in order, and experienced readers can jump to the walkthroughs further down. The same four steps work for a ticket set, where each ticket type gets its own id and the minting function decides how many of each exist.
Start WaveClamp, choose the folder that holds your .sol files and tests as the working folder of the chat, and pick Ask first so every change arrives as a diff that you accept or reject. File tools work inside that folder, so keep the project in one place. Create a throwaway folder for the first run if you only want to practise.
Ask for a game item contract with three item types, a minting function that only one owner account can call, and batch transfers, and let the agent create the file with write_file. Name the file after the contract so later steps can refer to it. Keep the first request small, because a second request can add batch transfers after the first diff is accepted.
Tell the agent to run your compile command and your test command through Shell, then read the exit code and the names of any failing tests on the expanded card. Success is judged by the real exit code, not by a summary. If the compile command fails, the card shows the error text, and the agent can read it and propose a fix as a new diff.
Open the expanded cards, read the diff and the command output, accept what is right, reject the rest, and ask for a fix wherever a test still fails. Repeat until the tests pass, then read the minting function once more. Keep each accepted diff small, so a later failure points to one change and not to ten.
MultiTokenMinimal.solsavedMultiTokenMinimal.sol14 linesbalanceOf1 matchyour compile commandexit 0// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IMultiTokenMinimal {
event TransferSingle(address indexed operator,
address indexed from, address indexed to,
uint256 id, uint256 value);
function balanceOf(address account, uint256 id)
external view returns (uint256);
function uri(uint256 id)
external view returns (string memory);
}This read-only interface declares the TransferSingle event and the balanceOf and uri functions of the multi-token standard. It holds no state, no minting logic and no keys, which makes it a small file to read before you add real logic. Run your compile command on it first. Compile it first, then let the agent extend it one reviewed diff at a time, starting with the minting function. The file name matches the example label, so you can ask the agent to open it later.
Open the contract and ask the agent to wrap the ERC1155 _mint helper in a public function that only the owner account can call. The agent uses read_file to see the current code and edit_file to insert the function, and it shows the change as a diff. Common open-source implementations expose internal helpers named _mint and _mintBatch, and an internal helper has no access check of its own, which is why the wrapper matters. You can create an ERC20 token step by step with the same method, but a game item set needs ids, so start from the multi-token layout. Shell then runs your compile command and your test command, and each card shows a real exit code. Accept the diff only when you have read the tests.
Open an ERC721 contract example from your own project, or ask the agent to write one with write_file, and place it beside your item set. The agent uses grep to list the functions in both files and read_file to compare how ownership is stored: one owner per token in the unique-token file, a balance per account and id in the multi-token file. A standard for decentralized profiles using soulbound NFTs would need tokens that cannot be transferred, which is a different design from items that players pass on. Ask the agent to put the differences into a short table. You read the comparison in the chat, decide which standard fits your design, and only then ask for code changes.
Players often move several item types at once, so ask the agent to add safeBatchTransferFrom and balanceOfBatch to the contract. The agent uses edit_file for the change, glob to find the test files, and Shell to run your test command after each edit. Batch functions move several token ids in one transaction, which means one test can check several balances. Understanding ERC4337 gasless onboarding is a separate subject, so keep it out of the first contract and test it on its own. Read the diff in Ask first, run the tests again, and look for the TransferBatch event in the output before you accept the change.
A contract that receives tokens must implement onERC1155Received and onERC1155BatchReceived and accept the tokens, otherwise the safe transfer is rejected. Ask the agent to grep for both names and to open the receiving contract with read_file, then to list which one is missing. Next ask it to use edit_file on the uri(id) value so it contains {id}, which clients replace with the token id in lowercase hexadecimal, padded to 64 characters. Use write_file for one JSON file per id. Run your compile command and your test command, read both exit codes, and review the final diff before you accept it.
