ARBOR
Home›How it works
How it works

Three steps. Under 30 seconds. Zero config.

From GitHub App install to your first blast-radius report in under a minute. No YAML. No CI changes. No secrets to manage.

Try it freeSee all features →
The Pipeline

Webhook to PR comment in 6 steps

1Webhook receivedGitHub PR event2Shallow clonegit clone --depth 13Git diffchanged files only4Tree-sitter ASTper changed file5Petgraph BFSblast radius traversal6PR comment posted< 30s total
< 30sCold start latency
O(V + E)Graph traversal
0%False positive rate
01
Step

Install in 30 seconds

One click. Zero configuration. Immediate monitoring.

Click Install on GitHub, pick your repositories, and Arbor immediately begins monitoring. No YAML config files, no CI pipeline changes, no environment variables to set on your side.

Arbor uses a GitHub App (not a personal access token), which means permissions are scoped and auditable. You can remove it anytime from GitHub's app settings.

  • Works on public and private repos
  • Org-level install covers all repos
  • Permissions are minimal and read-only except PR comments
# GitHub App permissions requested:
✓ Read repository contents
✓ Read pull requests
✓ Write pull request comments
✓ Write commit statuses
That's it. No tokens, no secrets,
no CI changes, no .arbor.yml
02
Step

Graph built automatically on every PR

Shallow clone → Tree-sitter parse → petgraph BFS. Sub-30 seconds.

When a PR is opened (or updated), GitHub sends a webhook event to Arbor. The server does a shallow git clone of just that commit — no full history needed — and identifies exactly which files changed using git diff.

Each changed file is parsed with Tree-sitter to produce a concrete syntax tree. Arbor extracts function definitions, call sites, imports, and class relationships, then wires them into a directed graph using petgraph (Rust).

Finally, BFS traversal walks the graph upward from each changed symbol, collecting every transitive caller. This is provably complete — there are no heuristics or approximations.

  • Tree-sitter grammars for 14+ languages
  • Cross-file edge resolution (imports ↔ exports)
  • BFS terminates in O(nodes + edges) — scales to any codebase
03
Step

Blast radius posted to your PR

Structured report. Specific actions. Under 30 seconds.

The analysis report is posted as a GitHub PR comment within 30 seconds of the PR being opened. It includes: a normalized risk score (0–100%), a summary table with per-file risk and caller counts, a list of high-centrality nodes, and — critically — a specific "Before You Merge" checklist.

The checklist isn't generic boilerplate. It's computed from the blast radius data: if 20+ callers are affected, it suggests splitting the PR. If a high-centrality node changed, it names that specific function and recommends test coverage. If overall risk is HIGH, it requests a senior review.

  • Comment posted in < 30s on every PR open/update
  • Commit status check blocks merge on HIGH (configurable)
  • Dashboard stores all analyses — searchable history
## 🔥 Blast Radius Report
Risk: HIGH Score: 74%
Changed: 3 files · 8 symbols
Affected callers: 24 upstream
| File | Risk | Callers |
|------|------|---------|
| auth.ts | HIGH | 14 |
| token.ts | MED | 6 |
### ✅ Before You Merge
- Test the payment checkout flow
- Request a senior engineer review
- Run full test suite locally
Real world impact

What changes when Arbor is in your review process

Without Arbor
PR opened: refactor auth middleware
✦ Reviewer A looks at the diff
✦ Reviewer B approves after 1hr
✦ PR merged
⚠ 3 hours later:
payment flow breaks in prod
Nobody knew auth.ts was a
dependency of checkout.ts
With Arbor
PR opened: refactor auth middleware
🤖 Arbor: HIGH blast radius
↳ checkout.ts calls validateToken
↳ payment.ts → checkout.ts → auth
✅ Before you merge:
↳ Test the payment flow manually
↳ Request senior review
✓ Issue caught before merge
FAQ

Common questions

Does Arbor slow down my PR review process?
No. The analysis runs in the background in under 30 seconds. Reviewers see the report appear while they're still reading the diff. It adds context, not latency.
What happens when Arbor can't resolve an import?
Arbor reports a lower confidence level and explains why. Unresolved imports (e.g., dynamic requires, complex re-exports) are noted explicitly so you know the blast radius might be incomplete, rather than silently giving you a wrong answer.
Does the graph get rebuilt from scratch on every PR?
Currently yes — each PR triggers a fresh shallow clone and parse. This is intentional: it avoids cache staleness and ensures the graph reflects the exact state of the PR. Graph caching is on the roadmap.
How does it handle monorepos?
Arbor analyzes the files changed in the diff and traces their edges across the full checkout. For large monorepos, the shallow clone ensures only the necessary files are fetched. Cross-package edges are resolved if they're within the same checkout.
Will it work if my codebase mixes languages?
Yes. The same graph engine processes all supported languages. A TypeScript frontend calling a Python API won't be edge-resolved (different runtimes), but within each language layer the analysis is complete.

See it on your first PR

30 seconds to install. Your next PR will have a full blast-radius report.

Install on GitHub — FreeRead the docs →