Open the folder
Choose the project folder as the working folder of a new chat and select Ask first, so that every change that writes a file waits for your decision. Put the ABI file in that folder before you start.
Workflows
Create a dApp from an empty folder to a tested screen
03
Start from an empty project folder
To create a dapp, begin with a folder that holds nothing but the ABI file of your own contract. Open that folder as the working folder of a new chat, choose Ask first and describe the page you want: a connect-wallet button, a balance and a transaction status line. The agent maps the folder, proposes the files as diffs and creates the page only after you accept each change. Decide before you start where the project will run. A local chain on your own PC suits a first attempt well, because the coins on it have no value, and a public test network is the next step once the page works. Use throwaway accounts on either, never an account that holds real funds, and keep every private key and seed phrase out of the folder, the chat and the repository. The result is a small, tested page and a README that another person could follow.
Describe the screen
Write which data the page shows and which transaction states it must handle, in plain sentences. Name the contract function it calls and the network it talks to, for example your local chain.
Review each diff
Read every proposed file change in the chat, then accept it or reject it with a short note. Expand a card when you want the full diff, and reject anything that you cannot explain in one sentence.
Run and check
Let Shell run your build command and your test command, and read the exit code on each card. Open the page against the local chain and compare what it shows with what you expect. Fix what fails before you add the next feature.
A small ABI file to start from
Read balanceOf from the ABI and show the result on the page.
- read_file
balance-abi.jsonloaded - write_file
app.jssaved - edit_file
index.html+4 lines - Shell
your build commandexit 0
waiting for your OK before the next stepRejectAccept
balance-abi.json
[
{
"type": "function",
"name": "balanceOf",
"stateMutability": "view",
"inputs": [{ "type": "address", "name": "account" }],
"outputs": [{ "type": "uint256" }]
}
]This JSON fragment describes one read-only function, balanceOf, the balance-reading function that ERC-20 tokens use. It takes an address named account and returns a uint256. A front end uses an ABI like this to call the contract, and the file holds no key and no secret. Save it as balance-abi.json in the project folder, and replace it with the full ABI of your own contract once the page works, since a real contract usually has many more functions.
Walkthroughs for a first dApp
Map the folder and read the ABI
A good way to start learning web3 is to read one small ABI file before you write anything. Ask the agent to open balance-abi.json. read_file shows the file, list_dir shows what else is in the folder and grep confirms the exact name of the function. The agent then explains in the chat that balanceOf is a view function: it reads data and sends no transaction, so calling it changes nothing on the chain. Nothing is written yet. It also lists what the page will need, namely a connection to a node, the address of the deployed contract and an account to look up. Check each statement against the JSON on the card, because a model can misread a type or name a function that the file does not contain, and ask for a correction before you go on.
Connect the page to a local chain
Ask for a page that reads the balance of a throwaway test account. write_file creates app.js with a call to your local chain over JSON-RPC, and edit_file adds a script line to index.html. You must have cross chain tools for a dapp only when it talks to several chains; a first project on one local chain needs none, so leave them out. In Ask first mode both changes wait as diffs. Read them and accept them. Shell then runs your build command, and the card shows the real exit code. Open the page, compare the number it shows with the number your local chain reports for the same account, and ask the agent to fix the page if the two differ. Keep the chain address in one place, so that changing the network later means editing a single line.
Handle the transaction states
Transitioning from web2 to web3 as a dev mostly means adding a wallet, a network and a transaction state to screens you already know how to build. Ask the agent to add a status line with 5 states: not sent, waiting for the wallet, pending, confirmed and failed. edit_file changes the script and the style sheet, and grep finds any place where a state is still missing. The wallet signs; your code never touches a private key or a seed phrase. Also ask for messages for a missing wallet, the wrong network and a rejected signature, because a real user will meet them sooner or later. Run the page on a test network with a throwaway account, reject a signature on purpose and check that the failed state appears with a clear message.
Test, then document the project
Ask the agent to write a front-end test for each state and a short README that explains how to run the project. write_file creates both files, Shell runs your test command and the card reports the real exit code. A dapp developer who returns to the project a month later will read that README first, so check that it names only commands you actually use and that it says which network the page expects. Use Plan only mode first if you want to see the list of steps before any file is created, then switch to Ask first to carry it out. Read each diff, run the tests yourself once on a test network with throwaway accounts, and keep the README next to the ABI file so both stay in sync.
