Arbor is a pull request review companion. It walks changed code paths and tells solo devs, small teams, and AI agents what might break before merge.

Can AI coding agents use Arbor?

Yes. Arbor produces a compact PR brief with risky paths, likely side effects, unknown edges, and the first test to write so agents can keep edits scoped.

Does Arbor work with GitHub pull requests?

Yes. Arbor installs as a GitHub App, analyzes pull requests, and comments with the breakage path reviewers should inspect.

Back to Arbor

Features

Arbor shows the paths your PR might break.

Every feature is built around one workflow: open a PR, see the changed paths, understand the likely downstream side effects, and hand a tight brief to the person or agent fixing it.

The core walk is deterministic: parse the diff, build the graph, trace the reachable paths, and show the unknowns instead of treating the graph as complete.

Capabilities

Built for devs and agents moving faster than review.

Arbor is the deterministic context layer between a PR and the next edit. It tells you what the change touches, what might break, and how to hand that context to a human reviewer or AI agent.

Breakage path tracing

Trace from changed code into routes, jobs, webhooks, commands, shared helpers, billing flows, auth flows, and data writes.

Diff -> path -> side effectKnown unknowns shownNo vague verdicts

Agent-ready briefs

Give AI coding agents a compact handoff: risky files, likely side effects, unknown edges, first test to write, and where to stop.

JSON/YAML handoffPatch scopeTest-first next action

PR comments people read

One short review note with the paths that matter. No spreadsheet, no giant dashboard detour, no ceremony.

Test suggestions

Arbor names the regression test or manual check that best matches the path it found.

Small-team path heat

See the downstream files and workflows touched by a change before the reviewer has to mentally page in the repo.

Honest unknowns

Dynamic imports, generated files, and unresolved edges stay visible so nobody treats a partial walk as a full answer.

Open graph core

The Rust parsing and graph pieces are inspectable, so advanced users can understand what Arbor saw.

Framework entrypoints

Next.js, Express, FastAPI, Axum, Spring, and other stacks get real route and handler detection before the walk starts.

Deterministic run

The same code produces the same structural walk, which makes the brief useful to both humans and automation.

AI agent workflow

Give agents a map before they touch the repo again.

Arbor can be used as a pre-edit context source: run the PR walk, pass the compact brief to the agent, then let the agent write the missing test or constrained patch with less wandering.

Question

Arbor answers

AI agent uses it to

Reviewer gets

What changed?

Changed symbols, affected entrypoints, and downstream call paths.

Reads the Arbor brief before writing another patch.

Checks the small set of files that actually matter.

What might break?

Billing, auth, data, jobs, emails, CLI commands, and shared helpers touched by the diff.

Generates the missing regression test first.

Reviews the side effect instead of the whole repo.

What is unknown?

Dynamic imports, generated code, unresolved edges, and confidence limits.

Stops or asks for a human decision at unknown boundaries.

Sees where judgment is still needed.

Breakage model

Arbor watches the parts of a small product that usually surprise you.

The model is built around product breakage: billing weirdness, auth regressions, background jobs, webhook retries, release scripts, and data writes.

Common fragile areas

PR note levels

FIX FIRSTwide reach

Likely breakage path found. Add a test or patch before merge.

REVIEWsome reach

Path touches something fragile. Human review should focus here.

WATCHnearby

No obvious break, but the change is adjacent to important behavior.

CLEARnarrow

No meaningful downstream path found. Unknowns are still listed.

Analysis pipeline

PR Webhook

GitHub event

Parse Repo

AST

Build Map

calls

Walk Paths

impact

Name Break

likely issue

Brief

human + agent

Agent workflow: ask Arbor for the brief, let the agent write the missing test or constrained patch, then rerun the walk before merge.

Why Arbor

Tests pass. AI says LGTM. The side effect is still hiding.

Arbor exists for the gap between a clean diff and the thing it accidentally touches three calls later. It gives humans and agents the map before the merge.

Understands the impact pathYes

Arbor

Walks changed code through routes, jobs, helpers, and downstream side effects.

Partial

Typical review

Usually summarize the diff or flag individual files.

Gives agents useful constraintsYes

Arbor

Returns scope, likely breakage, unknown edges, and the first test to write.

Typical review

Agents often keep editing from prompt context alone.

Helps tiny teams review fasterYes

Arbor

Compresses repo context into one note reviewers can act on immediately.

Partial

Typical review

Senior reviewers still reconstruct the path manually.

Names the unknownsYes

Arbor

Dynamic imports and unresolved edges stay visible in the PR.

Typical review

Uncertainty often gets hidden behind confident prose.

Works before mergeYes

Arbor

Posts while the PR is still fresh and fixable.

Partial

Typical review

Runtime tools catch the fallout later.

Language support

14 languages. Real AST parsing.

Syntax-accurate parsing for every supported language. The graph is built from actual function definitions, call sites, and imports.

TypeScript.ts .tsx

JavaScript.js .jsx

Python.py

Rust.rs

Go.go

Java.java

C#.cs

Ruby.rb

PHP.php

Swift.swift

Kotlin.kt

C / C++.c .cpp .h

Scala.scalabeta

Elixir.ex .exsbeta

Framework-aware entry points

Next.jsTypeScript

App Router, Pages API, Middleware

ExpressJavaScript

Route handlers, Middleware chains

FastAPIPython

Endpoint decorators, Dependencies

SpringJava

Controllers, REST resources

AxumRust

Handlers, Extractors, Layers

Gin / EchoGo

Handler funcs, Group routing

Every language uses a dedicated grammar for precise AST parsing. No regex, no line-level matching, no heuristics.

60-second product demo

Watch Arbor turn a tiny diff into a useful review plan.

The point is not another giant report. The point is one PR comment that tells a human and an AI agent where the change reaches, what might break, and which test or patch should happen next.

arbor-botcommented just now

For the solo dev

You get the side effects you did not have time to trace manually: billing, auth, jobs, emails, CLI commands, and shared helpers.

For AI agents

Agents can read the Arbor brief before they keep editing, then limit their next patch to the risky path and generate the missing test first.

For tiny teams

Reviewers see the exact regression to test instead of re-learning the whole codebase in the PR thread.

Open source core

The graph engine is open. Inspect what Arbor sees.

Parsing and graph construction are open-source Rust crates. Read the code, run it locally, verify the call graph.

arbor-coreLanguage parsing for 14 languages

crate

arbor-graphCall graph engine + reachability analysis

crate

MIT licensedUse it in your own tooling

license

View on GitHub

example.rs

1use arbor_graph::ArborGraph;
2
3// Parse the repository into a call graphlet graph = ArborGraph::from_directory("./src")?;
4
5// Walk upstream from a changed functionlet impact = graph.analyze_impact(node_id, 5);
6
7// Every caller, callee, and transitive pathfor upstream in &impact.upstream {    println!("{} → {} ({} hops)",        upstream.node_info.name,        upstream.node_info.file,        upstream.hop_distance,    );}

RustUTF-8 | LF

Arbor shows the paths your PR might break.

Every feature is built around one workflow: open a PR, see the changed paths, understand the likely downstream side effects, and hand a tight brief to the person or agent fixing it.

The core walk is deterministic: parse the diff, build the graph, trace the reachable paths, and show the unknowns instead of treating the graph as complete.

1use arbor_graph::ArborGraph; 2 3// Parse the repository into a call graphlet graph = ArborGraph::from_directory("./src")?; 4 5// Walk upstream from a changed functionlet impact = graph.analyze_impact(node_id, 5); 6 7// Every caller, callee, and transitive pathfor upstream in &impact.upstream { println!("{} → {} ({} hops)", upstream.node_info.name, upstream.node_info.file, upstream.hop_distance, );}