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 workbench, not a wall of warnings.

One comment on the pull request, and a single-file HTML report where the review happens. On the left, the risk that is left and what to read next; on the right, the file you are reading.

69

A merge risk that drops as you review0–100, with what makes it up. Tick a file once you read it and its share leaves the score. When the risk is low and nothing is left to check, the report says the merge is likely safe to approve.

!

Must checkBreaking API changes, security findings, lint errors and vulnerable dependencies, above every file. Reading the file does not clear them: you confirm each one.

≡

Files by risk: high, medium, skimEach with its diff, the lines no test ran marked in red, and a link to comment on any line in GitHub. Dependency bumps say what changed and how to check it; test files sit apart.

%

How much of the new code is testedDiff coverage per file and per line, with the files the coverage report never saw listed apart (types and constants are often excluded on purpose).

✓

What it can affectThe pages and endpoints that run the changed code, riskiest first, to try by hand. Mark the ones behind a feature flag and their files leave the score.

↗

Results for the pull requestWhat you checked, as Markdown for a PR comment: risk before and after, what is still open, your notes on each file.

Also in the report: suggested reviewers from git history, production traffic and errors from Datadog (optional), and a Details page with every route, its import graph and the raw signals. After a push, a second report covers only the new commits.

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