coding-agent

• Créer ou développer de nouvelles fonctionnalités et applications — laissez un coding-agent explorer la base de code et implémenter de bout en bout, plutôt que de corriger en ligne.
• Réviser des pull requests — lancez un agent dans un clone temporaire ou un git worktree afin qu'il puisse comparer, analyser et résumer les modifications en toute sécurité.
• Refactoriser de grandes bases de code — les modifications multi-fichiers nécessitant un contexte sur de nombreux fichiers bénéficient d'un agent capable de parcourir l'arborescence du projet.
• Correction de problèmes en parallèle — utilisez des git worktrees pour exécuter plusieurs agents simultanément, un par problème, puis créez des PRs à partir de chaque branche.

• Corrections simples en une ligne — si la modification est évidente et localisée, modifiez directement le fichier ; lancer un agent ajoute une surcharge inutile.
• Exploration de code en lecture seule — utilisez un outil de lecture/grep pour inspecter le code plutôt que de démarrer un coding-agent complet.
• Travailler dans ~/clawd ou l'espace de travail OpenClaw actif — les agents ne doivent jamais être lancés dans le répertoire de travail propre à l'orchestrateur.
• Requêtes ACP liées au fil de discussion — si vous avez besoin de lancer ou d'exécuter Codex/Claude Code dans un fil Discord ou un contexte ACP similaire, utilisez sessions_spawn avec runtime:"acp" à la place.

Prend en charge quatre agents de codage distincts avec les patterns d'invocation corrects pour chacun. Codex et Pi nécessitent pty:true pour un comportement de terminal interactif ; Claude Code utilise --print --permission-mode bypassPermissions pour une exécution propre sans PTY.

Les tâches de longue durée peuvent être lancées avec background:true, ce qui retourne un sessionId. Vous pouvez ensuite interroger le statut, diffuser les journaux, envoyer des entrées stdin ou arrêter la session à l'aide des actions de l'outil de processus — en tenant l'utilisateur informé sans bloquer l'exécution.

Définir workdir garantit que l'agent démarre dans le bon dossier de projet et n'explore pas des fichiers sans rapport. Cela est essentiel pour les revues de PR et la résolution parallèle de problèmes.

Créez des worktrees git isolés par problème, lancez un agent dédié dans chacun, surveillez-les simultanément et poussez des branches séparées pour la création de PR — le tout sans toucher la branche principale.

Ajoutez une commande openclaw system event à la fin du prompt de l'agent afin que l'orchestrateur reçoive un événement de réveil immédiat lorsque la tâche se termine, plutôt que d'attendre la prochaine interrogation de battement de cœur.

Les révisions sont toujours effectuées dans un clone temporaire ou un worktree git — jamais dans le dossier du projet en cours — afin d'éviter les checkouts de branches accidentels ou les modifications de la base de code active.

Pointez un agent Codex ou Claude Code vers le répertoire de votre projet avec workdir et une invite de fonctionnalité claire. L'agent explore la base de code, implémente la fonctionnalité dans plusieurs fichiers et effectue un commit — pendant que vous surveillez via process action:log.

Récupérez toutes les références de PR ouvertes, lancez un processus coding-agent par PR en mode arrière-plan, collectez leurs revues, et publiez les résultats sous forme de commentaires GitHub via la CLI gh — le tout en parallèle.

Créez un worktree git pour chaque problème ouvert, lancez un agent dans chaque worktree, surveillez la progression, puis poussez les branches et ouvrez des PRs pour révision humaine — réduisant considérablement le temps de correction.

Pour des invites ponctuelles rapides sans projet existant, créez un répertoire temporaire, exécutez git init, et laissez coding-agent accomplir une tâche autonome — puis supprimez le répertoire une fois terminé.