Desarrollo de aplicaciones Web3 dentro de tu propia carpeta de proyecto

Lo que el agente puede hacer por tu dApp

• Archivosread_file, write_file, edit_file, grep, glob y list_dir funcionan en la carpeta de trabajo del chat, por lo que los componentes, los estilos y el archivo JSON del ABI pueden leerse y modificarse allí.
• Shellejecuta tu propio comando de compilación y de prueba en Windows, WSL o un servidor SSH que poseas, e informa el código de salida real de cada uno.
• Webweb_search y http_get leen páginas de documentación públicas, por lo que una pregunta sobre una biblioteca o una interfaz puede verificarse contra la página que la describe.
• Capturas de pantalla e imágenesocr lee el texto de una captura de pantalla guardada, como un mock-up de diseño, y gen_image guarda archivos de imagen, como ilustraciones de marcador de posición.
• Orquestacióntask inicia subagentes para partes separadas del trabajo en paralelo, run_on_model envía un paso difícil a un modelo más grande, y skill reutiliza un plan de acción.
• Modos de aprobaciónAuto-run actúa de inmediato, Ask first pausa antes de las acciones que cambian algo y muestra un diff, y Plan only escribe un plan y no ejecuta nada.
• Cronejecuta un prompt en un horario, por ejemplo, tu comando de prueba una vez al día, y los planes sobreviven a un reinicio de la app, por lo que una tarea larga puede continuar más tarde.
• Modelosusa un proveedor de IA en la nube a través de un punto de conexión API estándar, un modelo en tu propia PC o el modelo integrado, y presiona Test para verificar un punto de conexión.

Cuatro recorridos para un proyecto dApp

Mapear un proyecto heredado

Le pides al agente que mapee una carpeta dApp que alguien más comenzó. list_dir muestra la estructura, glob encuentra los archivos de componentes y ABI, y grep lista cada lugar que llama a una función del contrato. Cada resultado es una tarjeta en el chat. No cambia nada. El mapa muestra dónde se manejan los estados de las transacciones y dónde faltan, y lo que impide que la gente adopte dapps suele ser un front-end que falla sin decir por qué: sin billetera, la red incorrecta o una firma rechazada. El modo Plan only se ajusta bien a esta tarea, ya que escribe el plan y no ejecuta nada, y el plan puede nombrar los archivos que necesitan atención primero. Pide un resumen escrito breve, luego léelo contra la carpeta antes de comenzar cualquier edición, y corrige al agente si ha leído mal un archivo.

Conectar un ABI en un componente

Pides un componente que muestre el saldo de una cuenta de prueba. read_file abre el JSON del ABI, por lo que el agente sabe que balanceOf toma una dirección y devuelve un uint256, y edit_file añade la llamada a tu componente. En el modo Ask first, el cambio espera como un diff. Lees las líneas añadidas y eliminadas, las aceptas o rechazas, y pides una revisión si un nombre o un tipo parece incorrecto. Shell luego ejecuta tu comando de compilación e informa el código de salida real en la tarjeta, y puedes expandir la tarjeta para leer la salida completa. Una compilación verde muestra que el código compila; no muestra que se llame a la función correcta, por lo que verifica la llamada contra el ABI tú mismo y mantén el archivo ABI sincronizado con el contrato.

Probar cada estado de transacción

Las interfaces fallan en los huecos entre estados: no enviado, esperando la billetera, pendiente, confirmado y fallido. Para evitar construir dapps fantasma que parecen terminadas y fallan en la primera firma rechazada, pídele al agente que escriba una prueba de front-end para cada estado. write_file crea el archivo de prueba, edit_file ajusta el componente donde falta un estado, y Shell ejecuta tu comando de prueba. La tarjeta muestra el código de salida y, cuando la expandes, la salida completa. Ejecuta las pruebas contra una cadena local con cuentas desechables, lee cada fallo y decide si la prueba o el componente están mal. No aceptes un cambio solo porque las pruebas se pongan verdes: lee el diff y verifica que la prueba realmente afirme el estado tras el cual está nombrada.

Planificar una función, luego ejecutarla

Un desarrollador que quiere dar un salto de calidad después de 1 año en web3 puede pedirle al agente un plan que añada estados de carga, correcciones de accesibilidad y pruebas a un dApp existente. En el modo Plan only, el agente escribe los pasos y no ejecuta ningún comando ni cambia ningún archivo. Lees el plan, quitas lo que no quieras, y cambias a Ask first para ejecutarlo. Desde entonces, el agente pausa antes de cada acción que cambia algo, y lees cada diff antes de aceptarlo. Los planes sobreviven a un reinicio, por lo que puedes detenerte en cualquier paso y continuar al día siguiente. Termina ejecutando tu comando de prueba y leyendo su salida tú mismo, y escribe en el README qué comandos usaste.