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.

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

Documentation

Run Arbor as the map before the next edit.

Install the GitHub App, read the PR breakage map, tune the repo rules, and hand clean context to a reviewer or AI agent without turning every PR into archaeology.

Quickstart

Four minutes to the first useful PR note

Install the GitHub App

Install Arbor on the repositories you want analyzed. Arbor needs code and PR read access, plus permission to post comments and commit statuses.

Open a pull request

When a PR opens or updates, Arbor reads the diff, builds the surrounding graph, and traces downstream paths from the changed code.

Read the breakage map

The PR note names changed files, reachable paths, likely side effects, unknown edges, and the first check worth running.

Hand it to a person or agent

Use the note as a reviewer checklist or as a compact pre-edit brief for an AI agent.

PR note

What Arbor posts back to GitHub

The comment is designed for fast scanning. It should tell you what changed, what it can reach, where path heat is high, and what is still unknown.

Part

Meaning

Changed scope

Files, functions, and symbols touched by the PR.

Reachable paths

Routes, jobs, webhooks, helpers, and writes that can be reached from the change.

Likely breakage

Concrete downstream behavior that deserves review before merge.

Unknown edges

Dynamic imports, generated code, framework magic, or other paths Arbor could not fully resolve.

First check

The smallest useful test, manual click path, or command to run next.

Agent handoff

Use Arbor as pre-edit context for AI agents

The agent workflow is simple: run Arbor before asking an agent to continue. Give the agent the path map, likely break, unknowns, first test, and stop condition. That turns a vague prompt into bounded work.

Keep the agent inside the changed scope unless the test proves a wider edit is needed.
Ask for the first regression test before the fix when the path points to risky behavior.
Stop the run if the agent needs to edit files Arbor marked as unrelated.

Agent briefjson

{
  "task": "Fix PR #184 without widening the checkout path",
  "changed_scope": [
    "src/billing/checkout.ts",
    "src/jobs/retry-invoice.ts"
  ],
  "likely_break": "Retry job can now enqueue duplicate invoice attempts",
  "path": [
    "POST /checkout",
    "createCheckoutSession",
    "queueInvoiceRetry",
    "retryInvoiceJob",
    "stripe.invoices.create"
  ],
  "unknown_edges": [
    "Dynamic provider import in billing/provider.ts"
  ],
  "first_test": "Add duplicate retry regression for failed invoice creation",
  "stop_condition": "Do not edit auth/session.ts unless the failing test proves it is involved"
}

Configuration

Teach Arbor your repo shape

Arbor works without config, but local rules make the PR note sharper. Add the paths and symbols that matter in your codebase, and ignore generated or vendor folders.

.arbor/security.ymlyaml

# .arbor/security.yml
security:
  enabled: true

  sensitive_paths:
    - pattern: "src/auth/**"
      category: auth
    - pattern: "src/billing/**"
      category: payment
    - pattern: "src/db/**"
      category: database
    - pattern: "src/workers/**"
      category: network

  sensitive_symbols:
    - verify_admin
    - process_payment
    - execute_raw_sql
    - decrypt_token

  ignore:
    - "test/**"
    - "vendor/**"
    - "**/*.test.ts"
    - "**/*.generated.*"

Limitations

Where Arbor stays explicit

Arbor is a structural graph walk. It is not a claim that every bug has been found.
Dynamic imports, reflection, generated code, and runtime dependency injection can create unknown edges.
Macro-heavy, template-heavy, or generated source may parse partially depending on the language grammar.
A reachable path is not proof of a bug. Treat it as a strong clue about what deserves review.
If Arbor cannot resolve enough context, the right output is an explicit unknown, not a silent pass.

Troubleshooting

Fix the common rough edges

Issue

What to check

No PR comment appears

Check GitHub App installation, webhook delivery logs, and whether the repo is included in the installation.

Status links feel wrong

Use the dashboard analysis page from the PR comment. The link should land on the exact run.

Too many noisy paths

Start by narrowing sensitive_path rules and ignore generated folders until the note matches how your repo is organized.

A path looks missing

Add explicit path and symbol rules in .arbor/security.yml so Arbor can classify your local architecture.

Private repo says free plan

Upgrade the billing plan or move that repo into a public-repo workflow.

API

Inspect the current API contract

Public token-based run export is not exposed yet. Today, run output is available through the signed-in dashboard and the GitHub PR comment. The Rust API publishes its current health, webhook, repo, graph, and dashboard contracts through OpenAPI so the shipped surface stays inspectable.

Inspect API routesbash

curl https://arbor-h3v2.onrender.com/openapi.json

{ "task": "Fix PR #184 without widening the checkout path", "changed_scope": [ "src/billing/checkout.ts", "src/jobs/retry-invoice.ts" ], "likely_break": "Retry job can now enqueue duplicate invoice attempts", "path": [ "POST /checkout", "createCheckoutSession", "queueInvoiceRetry", "retryInvoiceJob", "stripe.invoices.create" ], "unknown_edges": [ "Dynamic provider import in billing/provider.ts" ], "first_test": "Add duplicate retry regression for failed invoice creation", "stop_condition": "Do not edit auth/session.ts unless the failing test proves it is involved" }

# .arbor/security.yml security: enabled: true sensitive_paths: - pattern: "src/auth/**" category: auth - pattern: "src/billing/**" category: payment - pattern: "src/db/**" category: database - pattern: "src/workers/**" category: network sensitive_symbols: - verify_admin - process_payment - execute_raw_sql - decrypt_token ignore: - "test/**" - "vendor/**" - "**/*.test.ts" - "**/*.generated.*"