perbo · free and open source
Only what needs you reaches you.
perbo plans a piece of work with you, runs it in its own worktree, reviews it independently and brings back only the decisions a person has to make. Everything else it closes itself.
Free and open source, Apache-2.0. Desktop app and CLI, built from source. No account.
Agents produce more than anyone can hold in their head: plans, diffs, transcripts, findings, rounds. perbo holds it instead. You see the spec you wrote, the graph you approved, and the one decision that is yours.
written with your own agent
back to agent
back to agent
back to agent
for you
1 decision
6 closed by perbo · 1 needs you
Plan it once, with your own agent.
Create opens planning mode for one piece of work: four panes and the interview docked beside them. When you approve, the plan can't change under you.
Planning · Retry a failed check once, then stop
perbo · main
waiting for your approval
Retry a failed check once, then stop
retry-failed-check · 3 requirements · a page per node
committed first · read-only to the executor
src/components/1 2 3
src/screens/4a
src/settings/4b
generated/
core/src/migrations/
specs/** · perbo executors never change specs
.github/workflows/** · repository settings
8 paths never appear here: secrets, git and agent configuration
prohibited paths · read by the write guard
Approve once
size · M
Impact warnings are advice, and nothing here changes the plan on its own. A check looks outside this draft's scope for files and packages that import what the draft changes or what the spec names, and flags sensitive kinds of path: migrations, config, security and dependencies. Each warning can become a scope change or a No-Go, or be dismissed.
advisory · shown to a person
a folder in your repository · an id on every requirement · a page per node
A spec is a folder in your repository, with an id on every requirement and a generated page per node, so a node reads on its own. The loop commits it first, as the branch's first commit, and the executor may read it and never write to it. This is the executable spec: the plan is drafted from it, and what it says is what runs.
you mark the paths · the write guard enforces them
Mark the paths a node may touch, and the ones nobody may: the repository's standing prohibited list. Paths become action parameters only through your approval.
no graph yet → generate once → curate by hand → approve once
Large work stays one ticket. Its plan groups acceptance criteria into nodes, an execution graph, which you curate by hand and approve once. Checks run per node, narrowed to its paths; review runs per node and once over the whole change. While it runs, each node's state comes from the sealed change set, the checks and the review, never from what the executor said.
warnings go to you, never to a model
While you plan, impact warnings name code outside the draft's scope that depends on something it changes, from a symbol and import index perbo builds on demand. Warnings go to you, never to a model.
Create
Interview
Generate plan (once)
Refine by editing
Approve (once)
Run
Pull request
nothing is generated again unless you start over from the spec
One window. The loop as it runs.
Desktop app and CLI over the same local store, .focrux/ in your repository.
perbo — ~/Developer/perbo
approved
A node's state comes from the sealed change set, the checks and the review, never from what the executor said.
Six stages, named the same in the app and the CLI.
Retry counter is not reset between attempts.
remediable · back to agent
The stop reason isn't in the acceptance criteria. Needs a person.
escalates · for you
Touches a file outside the approved scope.
blocks
Test name no longer matches what it asserts.
advisoryThe reviewer never sees the agent's transcript. Its prompts are published in full.
Retry a failed check once, then stop
Merging stays yours.
Three things, in order.
Create · Plan in the works
You write the spec first
You write the spec in an interview with your own agent, curate the execution graph and approve once. After that it can't change under you.
Loop · Reliability
The reviewer is independent
It sees the approved plan, the diff and your repository's own checks, never the agent's transcript. Findings it can close go back to the agent, round after round.
Build · Refine
It fixes what it can
You see what's left. perbo opens the pull request. Merging it stays yours.
Desktop app, CLI, your machine.
Desktop app
One window, your repositories, the loop as it runs. Built from source for now.
build it from the repository →CLI
$ focrux run --repo .
the CLI keeps the repository's name, focrux, for now
The same loop over the same .focrux/ store.
Your machine
No perbo server. Your checkout, your tools, your login.
Questions
in the works Create's surface for one piece of work: Spec, Explorer, Graph and Impact panes with the interview docked beside them. You approve the graph once; the loop runs it per node.
in the works In your repository, as a folder, committed first on the ticket's branch. The executor reads it and can't write to it.
Yes. Apache-2.0, on GitHub. Build it from the repository today.
Only to the model provider you already use through Claude Code or Codex. There is no perbo server and no account.
Claude Code and Codex, using your own login.
The approved plan, the diff and your repository's own checks. Never the agent's transcript. The prompts are published in full.
No. The CLI runs the same loop over the same .focrux/ store.
For opening pull requests, yes: the GitHub CLI, signed in.