Un dépôt que vous n'avez jamais vu, lu par trois agents à la fois.
Dans un code que vous ne connaissez pas, la première journée passe à chercher où sont les choses. Dirigez une session principale vers le dépôt et elle répartit la lecture : un assistant prend la couche de données, un autre l'API, un troisième le frontend et le build. Chacun renvoie un court résumé avec les chemins de fichiers, et la session principale en tire une seule vue d'ensemble.
Gratuit et open sourceTourne sur Mac et LinuxVos propres connexions Claude et Codex
Enregistré sur une machine de démo : la session principale résume ce que ses assistants ont renvoyé.
Demandez à un agent seul d'expliquer un gros dépôt et vous aurez la visite du premier dossier
Une seule session lit tout elle-même, et un gros dépôt n'y tient pas. Les parties lues en premier ressortent en détail, et le reste a droit à une phrase chacune.
Un agent tout seul
Un seul lecteur qui avance dans tout le dépôt
Du détail là où il a commencé, des suppositions ailleurs
Chaque question de suivi relance la lecture
Des agents côte à côte dans Overvibe
Un assistant par zone, tous en lecture en même temps
Une vue d'ensemble écrite à partir de chaque rapport
Les questions de suivi vont à l'assistant qui a lu cette partie
Trois lecteurs et une vue d'ensemble
Vous tapez
❯Je découvre ce dépôt. Fais cartographier les parties principales par des assistants en parallèle et écris-moi une vue d'ensemble dans ARCHITECTURE.md.
1La session principale découpe le dépôt
Elle regarde les dossiers de premier niveau et donne à chaque assistant une zone et les trois mêmes questions : qu'y a-t-il ici, qu'est-ce qui l'appelle, qu'est-ce qui est risqué à modifier.
2Les assistants lisent, personne ne modifie
Chacun dans son terminal sous la session principale, avec un compte rendu de ce qu'il a trouvé et les chemins de fichiers.
3La vue d'ensemble revient
La session principale écrit ARCHITECTURE.md à partir des rapports et termine par ce qu'elle ne sait toujours pas.
En coulisses, un assistant par zone. La deuxième ligne sert plus tard : l'assistant qui a lu l'API revient avec sa conversation et répond à partir de ce qu'il a déjà lu. Lire la référence CLI
$ overvibe new --attach --tool codex --cwd . --name "repo: map api" \
--prompt "Read src/api. What is here, what calls it, what is risky to change? Give paths. Do not edit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<map>\""
$ overvibe resume "repo: map api" --prompt "Where does the API check auth?"
Un seul agent fera l'affaire quand
le dépôt est assez petit pour être lu d'une traite, ou que seul un coin vous intéresse. Demandez directement à Claude. Les assistants deviennent rentables quand le dépôt a plusieurs parties qui demandent chacune un moment à lire.
Questions
Les assistants vont-ils modifier quelque chose ?
La consigne leur dit de ne pas le faire. Pour un dépôt auquel vous ne faites pas encore confiance, lancez-les avec --mode ask : chaque outil demande avant de lancer quoi que ce soit, et vous répondez dans Overvibe.
Quelle différence avec un brief de recherche ?
Le même principe, tourné vers le code. Le brief de recherche couvre les sources hors du dépôt, comme la doc, le web et les exports.
Puis-je poser des questions le lendemain ?
Oui. Arrêtez les assistants une fois la vue d'ensemble livrée, et overvibe resume en ramène un avec sa conversation quand vous avez une question sur sa partie.
D'autres façons de faire travailler les agents à deux
