Web3 application development inside your own project folder

What the agent can do for your dApp

• Filesread_file, write_file, edit_file, grep, glob and list_dir work in the chat's working folder, so components, styles and the ABI JSON file can be read and changed there.
• Shellruns your own build command and test command on Windows, WSL or an SSH server you own, and reports the real exit code of each.
• Webweb_search and http_get read public documentation pages, so a question about a library or an interface can be checked against the page that describes it.
• Screenshots and imagesocr reads the text of a saved screenshot, such as a design mock-up, and gen_image saves image files, such as placeholder artwork.
• Orchestrationtask starts sub-agents for separate parts of the work in parallel, run_on_model sends one hard step to a bigger model, and skill reuses a playbook.
• Approval modesAuto-run acts at once, Ask first pauses before actions that change something and shows a diff, and Plan only writes a plan and runs nothing.
• Cronruns a prompt on a schedule, for example your test command once a day, and plans survive a restart of the app, so a long task can continue later.
• Modelsuse a cloud AI provider through a standard API endpoint, a model on your own PC or the built-in model, and press Test to check an endpoint.

Four walkthroughs for a dApp project

Map an inherited project

You ask the agent to map a dApp folder that someone else started. list_dir shows the structure, glob finds the component and ABI files, and grep lists every place that calls a contract function. Each result is a card in the chat. Nothing changes. The map shows where transaction states are handled and where they are missing, and what stops people from adopting dapps is often a front end that fails without saying why: no wallet, the wrong network or a rejected signature. Plan only mode fits this task well, since it writes the plan and runs nothing, and the plan can name the files that need attention first. Ask for a short written summary, then read it against the folder before you start any edit, and correct the agent if it has misread a file.

Wire an ABI into a component

You ask for a component that shows the balance of a test account. read_file opens the ABI JSON, so the agent knows that balanceOf takes an address and returns a uint256, and edit_file adds the call to your component. In Ask first mode the change waits as a diff. You read the added and removed lines, accept or reject them, and ask for a revision if a name or a type looks wrong. Shell then runs your build command and reports the real exit code on the card, and you can expand the card to read the full output. A green build shows that the code compiles; it does not show that the right function is called, so check the call against the ABI yourself and keep the ABI file in sync with the contract.

Test every transaction state

Interfaces fail in the gaps between states: not sent, waiting for the wallet, pending, confirmed and failed. To stop building ghost dapps that look finished and break on the first rejected signature, ask the agent to write a front-end test for each state. write_file creates the test file, edit_file adjusts the component where a state is missing, and Shell runs your test command. The card shows the exit code and, when you expand it, the full output. Run the tests against a local chain with throwaway accounts, read each failure and decide whether the test or the component is wrong. Do not accept a change just because the tests turn green: read the diff, and check that the test really asserts the state it is named after.

Plan a feature, then carry it out

A developer who wants to level up after 1 year in web3 can ask the agent for a plan that adds loading states, accessibility fixes and tests to an existing dApp. In Plan only mode the agent writes the steps and runs no command and changes no file. You read the plan, cut what you do not want, and switch to Ask first to carry it out. From then on the agent pauses before each action that changes something, and you read every diff before you accept it. Plans survive a restart, so you can stop at any step and continue the next day. Finish by running your test command and reading its output yourself, and write down in the README which commands you used.