Développement d'applications Web3 dans votre propre dossier de projet

Ce que l'agent peut faire pour votre dApp

• Fichiers read_file, write_file, edit_file, grep, glob et list_dir fonctionnent dans le dossier de travail du chat, ce qui permet de lire et de modifier les composants, les styles et le fichier JSON ABI sur place.
• Shell exécute vos commandes de build et de test sur Windows, WSL ou un serveur SSH dont vous avez la maîtrise, et affiche le code de sortie réel de chaque opération.
• Web web_search et http_get lisent les pages de documentation publiques, de sorte qu'une question sur une bibliothèque ou une interface peut être vérifiée directement sur la page qui la décrit.
• Captures d'écran et images ocr extrait le texte d'une capture d'écran enregistrée, comme une maquette, et gen_image sauvegarde des fichiers image, comme des illustrations provisoires.
• Orchestration task lance des sous-agents pour les différentes parties du travail en parallèle, run_on_model envoie une étape complexe à un modèle plus puissant, et skill réutilise un jeu d'instructions.
• Modes de validation Auto-run agit immédiatement, Ask first fait une pause avant les actions qui modifient quelque chose et affiche un diff, et Plan only rédige un plan et n'exécute rien.
• Cron exécute une invite à intervalles réguliers, par exemple votre commande de test une fois par jour, et les plans survivent à un redémarrage de l'application, de sorte qu'une tâche longue peut reprendre plus tard.
• Modèles utilisez un fournisseur d'IA cloud via un point de terminaison API standard, un modèle sur votre propre PC ou le modèle intégré, et appuyez sur Test pour vérifier un point de terminaison.

Quatre parcours pour un projet dApp

Cartographier un projet hérité

Vous demandez à l'agent de cartographier un dossier dApp commencé par quelqu'un d'autre. list_dir affiche la structure, glob trouve les fichiers de composants et d'ABI, et grep liste chaque endroit où une fonction de contrat est appelée. Chaque résultat est une carte dans le chat. Rien ne change. La carte montre où les états des transactions sont gérés et où ils manquent, et ce qui empêche souvent les gens d'adopter les dapps est une interface front-end qui échoue sans préciser pourquoi : pas de portefeuille, le mauvais réseau ou une signature rejetée. Le mode Plan only convient bien à cette tâche, car il rédige le plan et n'exécute rien, et le plan peut nommer les fichiers qui nécessitent une attention en premier. Demandez un résumé écrit court, puis vérifiez-le par rapport au dossier avant de commencer toute modification, et corrigez l'agent s'il a mal interprété un fichier.

Intégrer une ABI à un composant

Vous demandez un composant qui affiche le solde d'un compte de test. read_file ouvre le fichier JSON ABI, de sorte que l'agent sait que balanceOf prend une adresse et retourne un uint256, et edit_file ajoute l'appel à votre composant. En mode Ask first, la modification s'affiche sous forme de diff. Vous lisez les lignes ajoutées et supprimées, les validez ou les rejetez, et demandez une révision si un nom ou un type semble incorrect. Shell exécute ensuite votre commande de build et affiche le code de sortie réel sur la carte, et vous pouvez développer la carte pour lire la sortie complète. Un build vert indique que le code se compile ; il ne garantit pas que la bonne fonction est appelée, donc vérifiez l'appel par rapport à l'ABI vous-même et gardez le fichier ABI synchronisé avec le contrat.

Tester chaque état de transaction

Les interfaces échouent souvent dans les intervalles entre les états : non envoyé, en attente du portefeuille, en attente, confirmé et échoué. Pour éviter de construire des dapps fantômes qui semblent terminées mais qui plantent dès la première signature rejetée, demandez à l'agent d'écrire un test front-end pour chaque état. write_file crée le fichier de test, edit_file ajuste le composant là où un état manque, et Shell exécute votre commande de test. La carte affiche le code de sortie et, lorsque vous la développez, la sortie complète. Exécutez les tests sur une chaîne locale avec des comptes jetables, lisez chaque échec et décidez si le test ou le composant est incorrect. Ne validez pas une modification juste parce que les tests passent : lisez le diff, et vérifiez que le test asserte vraiment l'état auquel il fait référence.

Planifier une fonctionnalité, puis la mettre en œuvre

Un développeur qui veut se perfectionner après 1 an dans le web3 peut demander à l'agent un plan qui ajoute des états de chargement, des corrections d'accessibilité et des tests à une dApp existante. En mode Plan only, l'agent rédige les étapes, n'exécute aucune commande et ne modifie aucun fichier. Vous lisez le plan, supprimez ce que vous ne voulez pas, et passez à Ask first pour le mettre en œuvre. À partir de là, l'agent fait une pause avant chaque action qui modifie quelque chose, et vous lisez chaque diff avant de le valider. Les plans survivent à un redémarrage, donc vous pouvez arrêter à n'importe quelle étape et reprendre le lendemain. Terminez en exécutant votre commande de test et en lisant sa sortie vous-même, et notez dans le README quelles commandes vous avez utilisées.