Know the risk of merging, and where it lives.

Review effort should follow risk.

Agents now write much of the code and review it too, so the human approval is the scarce part. Spread evenly over every pull request it turns into a skim, and a skim is how a one-line change to a shared hook breaks forty pages.

farol makes the risk explicit before anyone approves: a verdict that says how much review the merge needs, and the files that carry the risk, ranked. Low-risk pull requests can go fast; risky ones get read line by line, starting where it matters. The Claude Code team describes the same principle in how they do code review: “The change sets the tier, not the author.”

After the AI review, before the human approval.

farol does not replace your review agent. Let the agent comment on the lines; when it is done, farol gives the person who approves what the agent cannot reliably give: the risk of accepting the change, and where it lives.

What each one is good at:

A review plan, not a wall of warnings.

One comment on the pull request and a single-file HTML report, built for the person reviewing it.

⚠

Verdict and merge risk scoreFast track, quick review or careful review, with the reasons and what adds to the score.

1

Start hereThe riskiest files first, with inline diffs: untested lines marked ○, findings ⚠. Tick them as you go and watch the score drop.

↳

Pages and endpoints reachedEvery entry point the change runs, drawn as the chain of files that reaches it.

≠

Contract changesBreaking, dangerous and safe changes to what each endpoint receives and returns.

✓

Test planWhat to try by hand. It follows your review: items whose files you reviewed are marked.

±

Since your last lookAfter a push, a second report with only the new commits, so a second round starts where the first ended.

Also in the report: suggested reviewers from git history, findings from your linters and audits, production traffic and errors from Datadog (optional), pages behind a feature flag, and a copyable record of the review.

A CLI and a GitHub Action. Nothing to sign up for.

farol is MIT-licensed and free to use, on any repository. There is no account, no hosted service and no telemetry: it runs on your machine or in your CI runner.

npx @winninjs/farol analyze --base origin/main --head HEAD --out farol.json
npx @winninjs/farol html --in farol.json --out farol.html

# .github/workflows/farol.yml (excerpt)
- uses: winnin/farol/action@main
  with:
    command: analyze
    base: ${{ github.event.pull_request.base.sha }}
    head: ${{ github.event.pull_request.head.sha }}
    out: farol.json

Reads the frameworks you already use.

Entry points come from your routes, operations and jobs. Diff coverage, lint and vulnerabilities come from the reports your CI already produces.

Static analysis, end to end.

No model in the loop and nothing executed: the same pull request always gives the same report.

One config line, then run it.

# 1. describe the project
echo '{ "routes": { "file": "src/routes.tsx" } }' > farol.config.json

# 2. check the pages and endpoints farol sees
npx @winninjs/farol routes

# 3. analyze your branch and open the report
npx @winninjs/farol analyze --base origin/main --head HEAD --out farol.json
npx @winninjs/farol html --in farol.json --out farol.html