Desenvolvimento de aplicações Web3 dentro da pasta do seu projeto

O que o agente pode fazer pelo seu dApp

• Arquivosread_file, write_file, edit_file, grep, glob e list_dir funcionam na pasta de trabalho do chat, então componentes, estilos e o arquivo JSON do ABI podem ser lidos e alterados ali.
• Shellexecuta seu próprio comando de build e comando de teste no Windows, WSL ou em um servidor SSH de sua propriedade, e relata o código de saída real de cada um.
• Webweb_search e http_get leem páginas de documentação públicas, então uma dúvida sobre uma biblioteca ou interface pode ser verificada contra a página que a descreve.
• Capturas de tela e imagensocr lê o texto de uma captura de tela salva, como um mock-up de design, e gen_image salva arquivos de imagem, como arte de placeholder.
• Orquestraçãotask inicia sub-agentes para partes separadas do trabalho em paralelo, run_on_model envia uma etapa difícil para um modelo maior, e skill reutiliza um playbook.
• Modos de aprovaçãoAuto-run age imediatamente, Ask first pausa antes de ações que alteram algo e mostra um diff, e Plan only escreve um plano e não executa nada.
• Cronexecuta um prompt em um agendamento, por exemplo, seu comando de teste uma vez por dia, e os planos sobrevivem a uma reinicialização do app, então uma tarefa longa pode continuar mais tarde.
• Modelosuse um provedor de IA na nuvem através de um endpoint de API padrão, um modelo no seu próprio PC ou o modelo integrado, e pressione Testar para verificar um endpoint.

Quatro tutoriais para um projeto dApp

Mapear um projeto herdado

Você pede ao agente para mapear uma pasta dApp que outra pessoa começou. list_dir mostra a estrutura, glob encontra os arquivos de componente e ABI, e grep lista todos os lugares que chamam uma função de contrato. Cada resultado é um cartão no chat. Nada muda. O mapa mostra onde os estados das transações são tratados e onde estão ausentes, e o que impede as pessoas de adotar dapps é frequentemente uma interface front-end que falha sem dizer o motivo: sem carteira, a rede errada ou uma assinatura rejeitada. O modo Plan only se encaixa bem nesta tarefa, pois ele escreve o plano e não executa nada, e o plano pode listar os arquivos que precisam de atenção primeiro. Peça um resumo escrito curto, depois leia-o contra a pasta antes de iniciar qualquer edição, e corrija o agente se ele tiver interpretado mal um arquivo.

Conectar um ABI a um componente

Você pede um componente que mostra o saldo de uma conta de teste. read_file abre o JSON do ABI, então o agente sabe que balanceOf recebe um endereço e retorna um uint256, e edit_file adiciona a chamada ao seu componente. No modo Ask first, a alteração fica pendente como um diff. Você lê as linhas adicionadas e removidas, aceita ou rejeita, e pede uma revisão se um nome ou um tipo parecer errado. Shell então executa seu comando de build e relata o código de saída real no cartão, e você pode expandir o cartão para ler a saída completa. Um build verde mostra que o código compila; não mostra que a função correta é chamada, então verifique a chamada contra o ABI você mesmo e mantenha o arquivo ABI sincronizado com o contrato.

Testar cada estado de transação

Interfaces falham nas lacunas entre estados: não enviado, aguardando a carteira, pendente, confirmado e falhou. Para evitar construir dapps fantasmas que parecem terminados e quebram na primeira assinatura rejeitada, peça ao agente para escrever um teste front-end para cada estado. write_file cria o arquivo de teste, edit_file ajusta o componente onde um estado está ausente, e Shell executa seu comando de teste. O cartão mostra o código de saída e, quando você o expande, a saída completa. Execute os testes contra uma cadeia local com contas descartáveis, leia cada falha e decida se o teste ou o componente estão errados. Não aceite uma alteração apenas porque os testes ficam verdes: leia o diff, e verifique se o teste realmente afirma o estado para o qual ele foi nomeado.

Planejar um recurso, então executá-lo

Um desenvolvedor que quer evoluir após 1 ano em web3 pode pedir ao agente um plano que adicione estados de carregamento, correções de acessibilidade e testes a um dApp existente. No modo Plan only, o agente escreve as etapas e não executa nenhum comando e não altera nenhum arquivo. Você lê o plano, remove o que não quer, e muda para Ask first para executá-lo. A partir daí, o agente pausa antes de cada ação que altera algo, e você lê todo diff antes de aceitá-lo. Planos sobrevivem a uma reinicialização, então você pode parar em qualquer etapa e continuar no dia seguinte. Termine executando seu comando de teste e lendo sua saída você mesmo, e anote no README quais comandos você usou.