roborev : revue de code continue pour agents IA avec hooks Git, TUI et boucle de fix locale

roborev ajoute une couche de revue continue autour des agents de code. Le projet ne remplace ni Codex, ni Claude Code, ni OpenCode. Il se place a cote: vous committez, roborev relit en arriere-plan, garde les findings ouverts dans une file locale, puis reinjecte ou automatise la correction tant que le contexte est encore frais (README: https://github.com/kenn-io/roborev, Docs: https://roborev.io).

Le point interessant, surtout pour un lecteur xavki.blog, c est que l outil parle autant a une logique DevOps qu a une logique IA outillee. On retrouve des hooks Git, un daemon, une TUI, des worktrees isoles, des agents multiples, des commandes d analyse, des boucles de remediation et meme une integration avec les sessions d agents via agent-hook (README: https://github.com/kenn-io/roborev, Commands: https://roborev.io/commands/, Agent Hook: https://roborev.io/agent-hook/).

Mots-cles : roborev, revue de code continue, agents IA, Git hooks, TUI, Claude Code, Codex, Go, DevOps, agentic loop.

TL;DR

• roborev installe un hook post-commit pour relire les commits en arriere-plan (Quick Start: https://roborev.io/quickstart/).
• Les retours restent visibles dans une file locale persistante consultable en TUI (Quick Start: https://roborev.io/quickstart/).
• roborev fix sert a corriger des findings ouverts, alors que roborev refine boucle jusqu a une branche re-reviewee et propre (Commands: https://roborev.io/commands/, Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/).
• agent-hook peut relancer la correction directement dans la session d agent quand les reviews en echec s accumulent (Agent Hook: https://roborev.io/agent-hook/).
• Le projet reste local-first: daemon, SQLite, hooks et agents deja installes sur votre machine (Docs: https://roborev.io).

Overview

roborev est un outil de revue de code continue pense pour les agents de code en ligne de commande. Le depot principal le presente comme un systeme qui tourne en arriere-plan, relit chaque commit au fur et a mesure, puis remonte des problemes rapidement avant qu’ils ne s’accumulent (README: https://github.com/kenn-io/roborev). La page d’accueil officielle reprend la meme idee sous une forme plus courte: revue immediate des commits, correction rapide et boucle write -> review -> fix integree au flux de travail local (Docs: https://roborev.io).

L’angle important ici est que roborev ne se place pas comme une plateforme SaaS de revue distante. La documentation explique au contraire que l’outil orchestre la revue directement sur la machine de l’utilisateur, avec les agents deja installes localement (README: https://github.com/kenn-io/roborev, Docs: https://roborev.io). Pour une equipe ou un solo dev qui travaille deja avec Codex, Claude Code, Gemini, Copilot ou OpenCode, cela change surtout le moment ou la revue arrive: elle ne tombe plus uniquement au niveau de la Pull Request, mais au niveau du commit.

La page d’accueil de la documentation decrit aussi quelques briques d’architecture utiles pour comprendre le comportement de l’outil: un daemon HTTP, un pool de workers paralleles, un stockage SQLite local et des fichiers de configuration globaux et par depot (Docs: https://roborev.io). Ce point compte parce que roborev n’est pas juste une commande ponctuelle: c’est une boucle de travail persistante.

Objectif

Le probleme vise par roborev est explicite dans la documentation: les agents de code avancent vite, mais le feedback de revue arrive souvent trop tard, quand le contexte de generation est deja perdu (Docs: https://roborev.io). Le README insiste sur la meme idee avec une formulation operationnelle: l’outil tire la revue dans la boucle agentique tant que le contexte est encore frais (README: https://github.com/kenn-io/roborev).

Concretement, roborev cherche a couvrir quatre besoins:

• lancer une revue automatiquement apres un commit via un hook Git (README: https://github.com/kenn-io/roborev, Quick Start: https://roborev.io/quickstart/)
• conserver les revues ouvertes dans une file consultable en TUI jusqu’a cloture explicite (Quick Start: https://roborev.io/quickstart/)
• permettre une correction assistee ou automatisable avec roborev fix (README: https://github.com/kenn-io/roborev, Commands: https://roborev.io/commands/)
• iterer jusqu’a une branche propre avec roborev refine, y compris avec re-revue entre chaque passage (Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/)

Le projet couvre aussi un besoin de pilotage plus large. La reference des commandes expose par exemple summary, cost, insights, compact ou encore analyze, ce qui montre que roborev ne se limite pas a afficher des commentaires: il maintient aussi un historique et une couche d’exploitation autour des revues (Commands: https://roborev.io/commands/).

Le vrai probleme que roborev resout

Le probleme est facile a reconnaitre si vous travaillez deja avec des agents de code. L agent avance vite, committe parfois beaucoup, mais le moment ou l on relit vraiment le code arrive trop tard. Soit la review ne tombe qu en Pull Request, soit elle existe mais reste separee de la session de generation. La page d accueil de roborev insiste justement sur ce decalage entre vitesse d ecriture et vitesse de retour (Docs: https://roborev.io).

Le resultat est classique:

• le contexte du commit est deja perdu;
• les erreurs s accumulent sur plusieurs tours;
• les petites regressions deviennent des corrections plus couteuses;
• la revue n est plus une boucle, mais un lot arrive trop tard.

roborev essaie de casser ce probleme avec une logique tres mecanique: commit frequent -> review immediate -> feedback visible -> fix rapide -> nouvelle review (README: https://github.com/kenn-io/roborev, Quick Start: https://roborev.io/quickstart/).

Liens utiles

• Depot principal
• Site et documentation
• Quick Start
• Guide d’installation
• Reference des commandes
• Agent Hook
• Guide Auto-Fix avec refine
• Agents supportes
• Releases GitHub
• Changelog du projet
• Go
• Homebrew on Linux

Installation

La documentation officielle propose plusieurs chemins d’installation documentes, sans forcer une methode unique (Installation: https://roborev.io/installation/).

Installation rapide via script

La voie la plus directe sur macOS et Linux est le script d’installation:

curl -fsSL https://roborev.io/install.sh | bash

La documentation precise que ce script installe le binaire dans ~/.local/bin par defaut sur macOS et Linux (Installation: https://roborev.io/installation/).

Installation via Homebrew

Le projet documente aussi une installation Homebrew:

brew install kenn-io/tap/roborev

Ou en deux temps:

brew tap kenn-io/tap
brew install roborev

La page d’installation indique que cette approche fonctionne aussi sur Linux avec Homebrew (Installation: https://roborev.io/installation/). La documentation officielle de Homebrew rappelle justement que Homebrew peut etre utilise sur Linux et WSL2, avec une installation orientee mono-utilisateur et un prefixe adapte aux bouteilles binaires (Homebrew Docs: https://docs.brew.sh/Homebrew-on-Linux).

Installation via Go

Comme roborev est un projet Go, la documentation propose aussi:

go install go.kenn.io/roborev/cmd/roborev@latest

Le guide d’installation ajoute qu’il faut ensuite verifier la presence de $GOPATH/bin dans le PATH (Installation: https://roborev.io/installation/). Cette voie est coherente avec le positionnement de Go comme environnement bien adapte aux outils CLI et aux systemes distribuables sous forme de binaire unique (Go: https://go.dev).

Paquets et prerequis

Depuis la serie 0.57.0, la documentation mentionne aussi des artefacts .deb et .rpm dans les releases GitHub pour Linux amd64 et arm64 (Installation: https://roborev.io/installation/, Releases: https://github.com/kenn-io/roborev/releases). La release v0.60.0 expose bien ces paquets ainsi que des archives pour macOS, Linux et Windows (Releases: https://github.com/kenn-io/roborev/releases).

Il faut enfin garder un prerequis important en tete: roborev ne remplace pas l’agent de code, il l’oriente. La documentation des agents supportes indique qu’il faut au moins un CLI agent installe, par exemple Codex, Claude Code, Gemini, Copilot, OpenCode, Cursor, Kiro, Kilo, Droid ou Pi (Agents: https://roborev.io/agents/).

Notions et concepts

La revue post-commit

Le coeur du workflow est le hook Git installe par roborev init. Le quickstart indique que cette commande installe un hook post-commit et demarre le daemon, puis que chaque commit du depot est relu automatiquement en arriere-plan (Quick Start: https://roborev.io/quickstart/). Le README resume ce comportement en trois etapes: initialiser, committer, consulter les revues dans la TUI (README: https://github.com/kenn-io/roborev).

Cela signifie que la maille de base de la revue est le commit, pas seulement la branche ou la PR. C’est utile si vous travaillez deja en commits frequents avec un agent.

La file de revue et la TUI

La TUI n’est pas seulement un viewer. Le quickstart la presente comme une sorte de ledger local: chaque revue reste ouverte tant qu’elle n’a pas ete explicitement close, ce qui permet de savoir quelles generations ont deja ete relues et quelles findings restent ouvertes (Quick Start: https://roborev.io/quickstart/).

La reference des commandes montre aussi que l’outil sait lister, afficher, attendre, commenter et cloturer les jobs de revue via list, show, wait, comment et close (Commands: https://roborev.io/commands/). Autrement dit, roborev apporte une couche d’etat persistante autour du feedback produit par les agents.

fix vs refine

Le guide Auto-Fix with Refine donne une distinction nette entre les deux commandes (Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/):

Commande	Role
roborev fix	correction ponctuelle des revues ouvertes, sans boucle de re-revue attendue
roborev refine	boucle iterative: corriger, re-reviewer, recommencer jusqu’au passage ou a la limite d’iterations

La documentation precise aussi que refine travaille via des worktrees isoles et attend la re-revue des nouveaux commits, alors que fix sert plutot a un traitement plus direct des findings ouverts (Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/, Commands: https://roborev.io/commands/).

agent-hook

Une des idees les plus interessantes du projet est agent-hook. La documentation le decrit comme une integration optionnelle avec Codex et Claude Code: roborev surveille les seuils de session et les revues echouees, puis renvoie une instruction courte pour demander a l’agent de lancer roborev-fix avant que la session ne refroidisse (Agent Hook: https://roborev.io/agent-hook/).

Ce mecanisme evite un probleme classique: une revue se termine en arriere-plan, mais l’agent a deja avance sur autre chose. Le hook essaie donc de reinjecter le feedback au bon moment dans le flux de travail (Agent Hook: https://roborev.io/agent-hook/).

Multi-agent et configuration

roborev n’est pas limite a un seul fournisseur. La documentation des agents supportes liste plusieurs CLIs detectables automatiquement, avec un ordre de fallback et la possibilite de forcer --agent ou --model a la commande, ou bien de fixer cela dans .roborev.toml ou ~/.roborev/config.toml (Agents: https://roborev.io/agents/).

Le README ajoute aussi que certains types d’analyse peuvent pinner leur agent et leur modele directement dans la configuration, par exemple pour refactor avec Claude Code et un niveau de raisonnement rapide (README: https://github.com/kenn-io/roborev).

Le modele mental minimal

Avant d aller plus loin, on peut resumer roborev avec cinq briques simples:

1. Un hook Git lance la revue apres commit (Quick Start: https://roborev.io/quickstart/).
2. Un daemon local orchestre les jobs de revue (Docs: https://roborev.io).
3. Une file de revue garde les findings ouverts et consultables (Quick Start: https://roborev.io/quickstart/).
4. Un agent de code relit ou corrige selon les commandes choisies (Agents: https://roborev.io/agents/).
5. Une boucle de remediation passe par fix, refine ou agent-hook (Commands: https://roborev.io/commands/, Agent Hook: https://roborev.io/agent-hook/).

Dit autrement, roborev ne fait pas juste “une review de plus”. Il organise la circulation du feedback entre Git, la revue, l agent et la correction.

Architecture minimale a retenir

Pour un lecteur technique, le modele mental minimal peut etre resume comme suit:

• un daemon local orchestre les jobs de revue (Docs: https://roborev.io)
• des hooks Git declenchent des revues automatiquement apres commit (Quick Start: https://roborev.io/quickstart/)
• une base SQLite locale conserve les revues et leur etat (Docs: https://roborev.io)
• une TUI permet de parcourir, filtrer et cloturer les jobs (README: https://github.com/kenn-io/roborev, Commands: https://roborev.io/commands/)
• des commandes comme fix, refine et compact servent de couche d’action au-dessus des findings (Commands: https://roborev.io/commands/, Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/)

Ou roborev brille vraiment

roborev devient interessant des qu on a un flux de travail avec commits frequents et corrections rapides, par exemple:

• une session Claude Code ou Codex avec beaucoup de petits commits;
• un depot de scripts, manifests ou code Go/Python ou les regressions de structure se voient vite;
• une branche de fonctionnalite qui doit etre nettoyee avant PR;
• une equipe qui veut une revue locale sans attendre une chaine CI complete.

L outil semble moins justifie si vous committez peu, si votre flux repose deja entierement sur une revue humaine tardive, ou si vous ne voulez pas introduire de daemon ni de hooks locaux. Ce n est pas une faiblesse du projet, c est juste son terrain de jeu.

Commandes

Les commandes ci-dessous sont directement reprises de la documentation et du README, ce qui permet de rester sur un socle verifiable (README: https://github.com/kenn-io/roborev, Commands: https://roborev.io/commands/, Quick Start: https://roborev.io/quickstart/).

# installation
curl -fsSL https://roborev.io/install.sh | bash
brew install kenn-io/tap/roborev
go install go.kenn.io/roborev/cmd/roborev@latest

# initialisation dans un depot
cd your-repo
roborev init

# navigation et inspection
roborev tui
roborev status
roborev show
roborev list --open

# revue manuelle ou ciblee
roborev review
roborev review --branch
roborev review --dirty

# correction des findings
roborev fix
roborev fix 123
roborev refine
roborev refine --max-iterations 5

# integration avec les agents
roborev skills install
roborev agent-hook install

La reference des commandes montre aussi des sous-commandes utiles dans un contexte plus avance, par exemple roborev compact pour reverifier et consolider les findings ouverts, roborev analyze <type> pour lancer des analyses ciblees, ou roborev summary et roborev cost pour l’exploitation du backlog de revues (Commands: https://roborev.io/commands/).

Demo

Cette demo reprend le workflow documente par le projet. Elle n’a pas ete executee localement ici, donc elle doit etre lue comme un scenario de prise en main base sur les sources officielles, pas comme un compte-rendu de test (README: https://github.com/kenn-io/roborev, Quick Start: https://roborev.io/quickstart/).

Preparation du run

La premiere etape consiste a installer roborev, puis au moins un agent compatible. Le projet supporte notamment Codex, Claude Code, Gemini, Copilot et OpenCode, avec auto-detection du premier agent disponible si rien n’est force explicitement (Agents: https://roborev.io/agents/).

Si vous etes sur un poste Linux avec Homebrew, vous pouvez rester sur un chemin assez classique:

brew install kenn-io/tap/roborev

Si vous preferez la voie Go ou si vous gerez deja vos outils de cette maniere:

go install go.kenn.io/roborev/cmd/roborev@latest

Ensuite, placez-vous dans un depot Git que vous utilisez deja avec un agent de code:

cd your-repo

Lancement dans un depot existant

Le quickstart propose ensuite une commande unique pour brancher la boucle de revue:

roborev init

D’apres la documentation, cette commande installe le hook post-commit et demarre le daemon. A partir de ce moment, les nouveaux commits de ce depot sont automatiquement envoyes dans la boucle de revue en arriere-plan (Quick Start: https://roborev.io/quickstart/).

Si votre environnement Git utilise deja un gestionnaire de hooks comme Husky ou un core.hooksPath personnalise, le quickstart indique que roborev essaie de le detecter automatiquement (Quick Start: https://roborev.io/quickstart/). Le README ajoute qu’en environnement gere par un version manager, il est possible de forcer un binaire stable avec --binary lors de init ou de agent-hook install (README: https://github.com/kenn-io/roborev).

Suivi des revues dans la TUI

Une fois quelques commits produits, la documentation recommande d’ouvrir la TUI:

roborev tui

Le quickstart decrit cette file comme un registre persistant des revues executees. Chaque entree reste ouverte jusqu’a cloture explicite, ce qui permet de visualiser les findings encore actifs (Quick Start: https://roborev.io/quickstart/).

Dans un usage tres simple, vous pouvez alors:

1. laisser votre agent produire un commit;
2. attendre que roborev cree la revue en arriere-plan;
3. ouvrir le detail dans la TUI;
4. copier le contenu de la revue dans votre session agent si vous voulez une correction guidee;
5. fermer la revue une fois traitee.

Cette logique est decrite explicitement dans le quickstart avec la copie vers le presse-papiers et la fermeture manuelle de la revue une fois le feedback traite (Quick Start: https://roborev.io/quickstart/).

Correction assistee avec fix

Si vous voulez limiter les manipulations manuelles, le projet expose deux chemins. Le premier passe par la ligne de commande:

roborev fix

La documentation explique que fix prend les findings des revues ouvertes, les envoie a un agent, applique les changements, cree un commit et cloture la revue correspondante (Quick Start: https://roborev.io/quickstart/, Commands: https://roborev.io/commands/).

Le second chemin passe par l’installation des skills agents:

roborev skills install

Puis, dans Claude Code ou Codex, par l’appel du skill de correction:

/roborev-fix
$roborev-fix

Le quickstart precise que ce skill recupere les revues ouvertes, groupe les findings par fichier, les traite par priorite, lance des tests et propose ensuite un commit (Quick Start: https://roborev.io/quickstart/).

Boucle plus automatique avec agent-hook

Si vous utilisez Codex ou Claude Code et que vous voulez reinjecter automatiquement le moment de correction dans la session, la documentation propose:

roborev agent-hook install

Le guide agent-hook explique que cette integration surveille trois signaux de session: les turns, les commits et le nombre de revues ouvertes en echec. Quand le seuil est atteint, elle renvoie une instruction simple du type Invoke the $roborev-fix skill now. pour rappeler a l’agent de traiter les findings (Agent Hook: https://roborev.io/agent-hook/).

Dans un workflow pratique, cela donne une boucle proche de celle-ci:

1. l’agent code et commit;
2. roborev relit le commit en arriere-plan;
3. le hook detecte que des reviews en echec s’accumulent;
4. la session agent est poussee a executer le skill de correction;
5. le travail repart ensuite sur une base plus propre.

Sortie et reutilisation avant une PR

La commande la plus interessante pour une phase de finition est roborev refine:

roborev refine

Le guide Auto-Fixing decrit refine comme une boucle iterative complete: trouver la plus ancienne revue en echec, lancer un agent dans un worktree isole, appliquer un commit de correction, attendre la re-revue, puis recommencer jusqu’a ce que les revues passent ou qu’une limite d’iterations soit atteinte (Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/).

Le README pousse d’ailleurs clairement cette commande avant l’envoi final d’une branche: re-reviewer et corriger toute la branche jusqu’au passage complet (README: https://github.com/kenn-io/roborev).

FAQ rapide sur roborev

roborev remplace-t-il GitHub review ou une revue humaine ?

Non. Le projet ajoute une couche de revue continue locale autour des commits. Il peut remonter des findings plus tot, mais il ne supprime pas le besoin de validation humaine selon le contexte (README: https://github.com/kenn-io/roborev).

Faut-il changer d agent pour l utiliser ?

Non. La documentation liste plusieurs agents supportes et un mecanisme d auto-detection. L idee est justement de reutiliser les agents deja installes sur votre machine (Agents: https://roborev.io/agents/).

Quelle difference entre fix et refine ?

fix sert a traiter des reviews ouvertes sans boucle complete de re-review attendue. refine enchaine correction, nouveau commit, attente de re-review et nouvelle iteration jusqu au passage ou a la limite configuree (Commands: https://roborev.io/commands/, Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/).

Est-ce que roborev fonctionne seulement pour Go ?

Non. Le binaire est ecrit en Go, mais le projet se place au niveau du depot Git et de l agent de code. La documentation montre des usages generiques, pas reserves a un langage unique (README: https://github.com/kenn-io/roborev, Docs: https://roborev.io).

Est-ce que le projet peut vivre entierement en local ?

Oui pour le coeur du workflow. Le site et le README insistent sur une orchestration locale, sans service heberge obligatoire. Des options plus avancees existent ensuite, comme la synchro PostgreSQL entre machines (Docs: https://roborev.io, README: https://github.com/kenn-io/roborev).

Conclusion

roborev propose une reorganisation tres concrete du flux de travail avec agents: au lieu d’attendre une revue lointaine, il place la revue au niveau du commit, garde les findings dans une file locale, puis fournit plusieurs niveaux de correction, de fix jusqu’a refine (README: https://github.com/kenn-io/roborev, Guide Auto-Fixing: https://roborev.io/guides/auto-fixing/).

Pour un lecteur technique, le point le plus important a retenir est probablement celui-ci: roborev n’essaie pas d’etre un nouvel IDE ni un nouveau fournisseur d’IA. Le projet se place plutot comme une couche de coordination autour d’agents existants, de hooks Git, d’une TUI locale et d’un daemon de revue continue (Docs: https://roborev.io, Agents: https://roborev.io/agents/).

Si vous voulez l’explorer, le bon ordre de lecture me semble etre le suivant: README, quickstart, installation, commandes, puis agent-hook et auto-fixing pour les workflows plus pousses. Toutes ces briques sont deja documentees dans le depot et sur le site officiel (README: https://github.com/kenn-io/roborev, Quick Start: https://roborev.io/quickstart/, Installation: https://roborev.io/installation/, Commands: https://roborev.io/commands/).

Explorer les formations Xavki

Pour apprendre dans l ordre, repartez depuis la roadmap ou une playlist thematique.

Roadmap DevOps YouTube