In a codebase you don't know, the first day goes on finding where things live. Point a lead session at the repo and it splits the reading: one helper takes the data layer, one the API, one the frontend and the build. Each sends back a short summary with file paths, and the lead writes one overview from all of them.

One session reads everything itself, and a big repo doesn't fit. The parts it read first come out detailed, and the rest gets a sentence each.
I'm new to this repo. Have helpers map the main parts in parallel and write me one overview in ARCHITECTURE.md.
It looks at the top-level folders and gives each helper an area and the same three questions: what's here, what calls it, what's risky to change.
Each one in its own terminal under the lead, reporting what it found with file paths.
The lead writes ARCHITECTURE.md from the reports and ends it with what it still doesn't know.
Behind it, one helper per area. The second line is for later: the helper that read the API comes back with its conversation and answers from what it already read. Read the CLI reference
$ 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?"
the repo is small enough to read in one go, or you only care about one corner of it. Ask Claude directly. Helpers earn their keep once the repo has several parts that each take a while to read.
The prompt tells them not to. For a repo you don't trust yet, start them with --mode ask, so each tool asks before it runs anything and you answer in Overvibe.
Same pattern, pointed at code. The research brief covers sources outside the repo, like docs, the web and exports.
Yes. Stop the helpers once the overview is in, and overvibe resume brings one back with its conversation when you have a question about its part.
A few agents read different sources at the same time, and one of them writes the brief from what they send back.
Refactor by moduleA big refactor or migration split by module, one helper per area in its own worktree, and a reviewer reading the merged result.
Plan reviewClaude writes the plan, Codex reads it with the repo open and pushes back, all before a line of code exists.
Install Overvibe, open a lead session in the repo, and ask for one helper per area.
