Pourquoi OpenClaw a besoin d’un workflow GitHub
Les agents de style OpenClaw sont utiles parce qu’ils continuent après le premier prompt. Cette même force rend la discipline GitHub indispensable : un agent peut modifier des dizaines de fichiers, un autre corriger les tests, et un troisième relire le diff. Sans modèle de branches et de pull requests, l’équipe reçoit une pile de changements sans propriétaire clair.
Office Claws n’est pas une runtime OpenClaw native. Nous appliquons la même leçon d’exploitation aux agents adossés à Codex : une tâche reçoit un runner, une branche, un flux de logs et une PR relisible. Si tu compares les runtimes, commence par OpenClaw vs Codex, puis utilise le workflow ci-dessous comme couche GitHub sûre autour de l’un ou l’autre setup.
Le modèle de branche OpenClaw
Donne une branche à chaque agent avant qu’il écrive du code. Le nom de branche doit expliquer aux reviewers ce qui s’est passé sans ouvrir la PR. Nous aimons cette forme :
agent/<ticket-or-topic>-<short-purpose>
fix/<bug>-agent
docs/<topic>-agentUn peu de discipline de nommage évite deux échecs courants : des agents qui poussent sur main, et des humains qui ne savent plus quel runner possède quel diff. Dans Office Claws, la vue desktop relie une tâche à son runner et à son flux de logs ; la branche GitHub est la poignée équivalente côté contrôle de source.
| Étape | Propriétaire | Garde-fou | Échec évité |
|---|---|---|---|
| Créer la branche | Humain ou dispatcher | Le nom inclut la tâche | L’agent modifie main |
| Lancer l’agent | Runner isolé | Un worktree par tâche | Collisions de fichiers entre agents |
| Pousser une PR brouillon | Agent | La CI démarre aussitôt | Changements cachés seulement en local |
| Relire le diff | Humain ou agent reviewer | Approbation requise | Dérive d’architecture silencieuse |
| Merger | Humain | CI verte | Branche de production cassée |
La règle utile est simple : un agent peut proposer du code, mais il ne prend pas la décision finale d’intégration.
Des garde-fous CI avant la revue par agent
Lance les vérifications ennuyeuses avant de demander à un autre agent de relire le travail. Un agent reviewer est bien meilleur sur l’architecture, les cas limites et les tests manquants quand il ne dépense pas son contexte sur une erreur de formatage TypeScript.
Un garde-fou GitHub Actions minimal pour un repo web proche d’OpenClaw ressemble à ceci :
name: agent-pr
on:
pull_request:
branches: [main]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint --if-present
- run: npm test --if-present
- run: npm run buildPour les utilisateurs d’Office Claws, c’est là que le gestionnaire desktop devient précieux : garde l’agent de code sur un VPS, conserve les clés fournisseur en local, et laisse GitHub devenir l’endroit neutre où les humains inspectent le diff final. Voir Office Claws pour les utilisateurs OpenClaw pour la couche de gestion, et OpenClaw sur VPS pour l’architecture des runners.
Des passages de relais sûrs entre agents
Le passage de relais doit être explicite. Ne dis pas à un agent reviewer « vérifie le repo ». Dis-lui quelle PR, quels tests sont passés, ce qui a changé et quel risque tu veux faire examiner.
Review PR #42 on branch agent/billing-export.
CI is green. Focus on data-loss risk, auth boundaries, and migration rollback.
Do not push unless you create a separate reviewer branch.
Return: blocking issues, non-blocking suggestions, and merge recommendation.
Garde les permissions tout aussi explicites :
- Les agents de code ne peuvent pousser que sur leurs propres branches.
- Les agents reviewers peuvent commenter, pas merger.
- Les tokens de release ne sont pas présents sur les runners d’agents.
- Les humains gardent le dernier bouton de merge.
Ce modèle convient à OpenClaw, Codex ou toute future runtime d’agents. L’important n’est pas la marque de l’agent ; c’est la frontière de revue autour du code qu’il écrit.
Workflow recommandé
- Démarre chaque tâche depuis une branche fraîche et un worktree isolé.
- Laisse l’agent pousser une PR brouillon tôt, même avant la fin du travail.
- Exige la CI avant le retour d’un agent reviewer.
- Garde les clés fournisseur et les identifiants de release hors du runner.
- Merge seulement après qu’un humain a lu le résumé de PR, la sortie des tests et les fichiers risqués.
Si tu passes de sessions OpenClaw improvisées à quelque chose qu’une équipe peut vraiment utiliser, ce workflow GitHub est la première habitude à installer. Office Claws donne aux équipes de style OpenClaw la gestion desktop, l’isolation de runners VPS, l’exécution adossée à Codex et une gestion locale des clés plus sûre pour garder ces habitudes.
Lectures liées
- OpenClaw vs Codex — où chaque runtime convient.
- OpenClaw Desktop Manager — la couche de gestion Office Claws pour le travail de style OpenClaw.
- OpenClaw Security Best Practices — gestion des clés, isolation des runners et logs d’audit.