Chaque tour d'une boucle se déroule de la même façon, qu'il ait été déclenché par un webhook, une horloge, ou quelqu'un mentionnant le goblin directement. Cette page décrit ce qui se passe entre ce déclencheur et la merge request.
1. Le déclencheur arrive
TaskGoblin trouve ou crée le fil de ce travail — la conversation d'un ticket, d'une merge request, d'une boucle — et enregistre le tour comme un message dedans. Un suivi sur un travail déjà en cours rejoint le fil existant au lieu d'en ouvrir un neuf : c'est pourquoi le goblin ne vous demande jamais de tout réexpliquer.
2. Le sandbox démarre
L'exécution reçoit un conteneur cloud isolé contenant une copie de votre dépôt. Les sandboxes sont persistants et réutilisés entre les tours d'un même fil, donc un suivi atterrit dans un environnement qui a déjà le dépôt et l'état du tour précédent — le goblin reprend au lieu de repartir d'une boîte vide.
Ils sont souvent préchauffés, ce qui explique qu'une exécution commence généralement à travailler en quelques secondes plutôt que d'attendre un conteneur froid. Le sandbox cloud traite l'isolation, la persistance et l'auto-hébergement en profondeur.
3. Il lit avant d'écrire
Avant de toucher au code, le goblin rassemble le contexte : le ticket ou le diff qui l'a déclenché, l'historique du fil, la note de passation laissée par le goblin précédent, et les conventions de votre organisation. Dans une boucle d'événement, votre instruction permanente se pose par-dessus le contexte de l'événement lui-même.
C'est l'étape qui sépare un changement utile d'un changement seulement plausible. Un agent qui voit comment le dernier changement a été relu, et pourquoi une approche antérieure a été annulée, décide mieux qu'un agent qui démarre dans une pièce vide.
4. Un vrai agent de code fait le travail
Dans le sandbox tourne un véritable agent de code — Claude Code, Codex ou Gemini, selon le compte de modèle de l'exécution. Il a les outils d'un développeur : il lit et modifie des fichiers, lance des commandes et vos tests. Il ne complète pas un diff, il traite le problème.
5. Branche, commit, push, merge request
Le goblin suit le flux que votre équipe utilise déjà :
- Il travaille sur une branche dédiée —
142-taskgoblinpour le ticket 142 sur GitLab ou GitHub,proj-123-taskgoblinpour une clé Jira — jamais sur votre branche par défaut. - Il commite en signant son travail pour que la trace reste lisible, et pousse la branche.
- Il ouvre une merge request (GitLab) ou pull request (GitHub) et renvoie le lien là où le travail a commencé.
L'exception est une exécution déclenchée sur une merge request existante : elle pousse alors sur la branche de cette MR au lieu d'en ouvrir une concurrente.
Comme la sortie est une branche et une merge request, la relecture est exactement ce qu'elle est déjà pour les contributions humaines. Rien ne fusionne sans votre accord.
6. Il rend compte là où vous regardez déjà
Pendant l'exécution, le goblin s'exprime via la surface à laquelle le travail appartient : activité sur un ticket Linear, commentaires en ligne sur une merge request, une carte qui se met à jour toute seule dans Slack ou Teams. Vous ne surveillez pas un terminal, et il n'y a pas de tableau de bord séparé à penser à ouvrir.
7. Il note ce qui s'est passé
La dernière chose qu'un goblin fait — après avoir envoyé la réponse, jamais avant — est d'écrire une note de passation : ce qu'il a appris, ce qu'il a décidé, ce qui reste ouvert. Le tour suivant la lit en premier.
C'est pour cela qu'une boucle capitalise au lieu de se répéter. Voir Le cerveau.
Les secrets restent hors de l'agent
Le goblin ne voit jamais vos identifiants. L'accès git dans le sandbox est provisionné par organisation à l'exécution — un jeton OAuth GitLab ou un jeton d'installation GitHub fraîchement émis — et injecté dans l'environnement autour de l'agent plutôt que remis à lui pour lecture. Il peut utiliser l'accès nécessaire pour cloner et pousser sans que vos secrets entrent jamais dans son contexte ni dans sa transcription.
Ce jeton sert uniquement au transport git. Les commentaires, revues et mises à jour de tickets passent par les intégrations propres de TaskGoblin, afin d'être publiés en tant que goblin et non en tant que vous.
Quand quelque chose tourne mal
Une exécution en échec ne disparaît pas. Le goblin le signale clairement sur la surface d'où vous l'avez déclenchée, l'échec est consigné sur l'exécution, et la note de passation transporte le mur qu'il a heurté pour que le tour suivant ne le redécouvre pas. Une exécution qui n'a jamais obtenu de sandbox — bloquée par un solde épuisé, par exemple — n'est jamais facturée.
Où aller ensuite
- Le sandbox cloud — isolation, persistance et exécution sur votre propre infrastructure.
- Le cerveau — le savoir écrit qui fait avancer le travail.
- Tarifs et crédits — ce que coûte un tour, mesuré à la seconde.