PR review bot

The Repowise PR bot is a GitHub App that runs the same intelligence layers as the CLI and dashboard against every pull request, and posts one comment. In Signals, the default mode, the comment is deterministic and posts only when there is something worth saying: no model, no per-PR tokens, and free forever for public / OSS repos. AI triage and Full AI review add a model and are part of Pro, billed from credits. Private repos need the Pro plan too. See review modes.

Install#

Permissions requested: Contents: Read · Pull requests: Write · Metadata: Read · Issues: Write (GitHub treats PR comments as issue comments). The optional merge gate and findings on lines additionally need Checks: Write; existing installs re-consent when you turn either on. The one-click coverage setup needs Contents: Read and write and Workflows: Read and write.

Review modes#

Each repository picks one mode in the dashboard (Settings → PR bot). The mode is set only there: the bot ignores it in .repowise/bot.yaml, so a pull request from a fork cannot turn on a paid pass.

AI review draws on the same credit balance as chat, docs and MCP. Pro includes $5 of credits a month, about 50 full reviews. Each repository also has a monthly AI spend limit ($5 by default). When the plan does not include AI review, the balance is empty, or the limit is reached, the bot posts only what Signals would and notes the pause on its next comment.

The silence rule#

This applies in Signals and AI triage. Most PR bots are noise. This one stays silent unless there is a measurable signal worth interrupting a reviewer for. A green PR with no findings gets no comment at all. Full AI review is the exception: it reviews every PR and posts one line on a clean one. When the bot does comment, improvements are shown alongside problems so cleanup gets credit. It posts when any of these fire:

• net repo health degrades, or any modified file's score drops;
• a hotspot file (high churn + many dependents) is touched;
• a top co-change partner of a modified file is missing from the PR;
• new dead code is introduced (or removed, which is a win);
• a modified file is on a declining-health trajectory;
• a changed file carries substantial recent bug-fix history;
• the diff's change-risk score lands in this repo's high band.

The bot edits its existing comment when new commits land rather than posting a wall of duplicates; if the silence rule fires after an earlier comment, the stale comment is deleted.

What's in the comment#

Each section is independent and only renders when it has something to say:

Every signal is deterministic: health scoring is tree-sitter + git + the calibrated marker scorer, and refactoring suggestions are template strings keyed off the marker type. In Signals nothing is generated by a model, so every comment is reproducible. AI triage and Full AI review write their part of the comment with a model, and the pull request page names the model that wrote it.

Findings on lines#

With show_findings_on_lines, the bot marks findings on the diff as Check Run annotations, so they show in Files changed next to the code: high and critical health findings on lines this PR added, and changed signatures that code outside the PR still calls. In Full AI review its points on code this PR wrote are marked too, capped by the review sensitivity; they are posted as review threads either way. It is off by default. With the merge gate off, the annotations ride on a neutral check that is posted only when there is something to mark.

The merge gate#

Beyond commenting, the bot can post a GitHub Check Run that a branch protection rule can require, turning code health into a merge gate. It is off by default and configured per repo (health_gate.mode):

• off: no check is created.
• advisory: always concludes neutral. The verdict is visible on the PR but never blocks. The safe default to start with.
• blocking: concludes failure when a rule trips, which a required check will block the merge on.

The rules (evaluated only in blocking mode) let you adopt a clean-as-you-code policy without forking any constants:

Or start from a named profile and nudge single knobs: health_gate.profile accepts warn-only, block-new-file-floor, block-any-decline, or block-on-ai-regression. The profile seeds the rules; any explicit key set alongside it wins.

CI checks#

Beside the review comment, the bot posts a second checks comment with what the tests, the security scan and the docs say about the change. It is on by default and never repeats the review comment: while it is on, doc drift and the "run these tests first" line move out of the review comment and into it.

When it posts. With checks_comment_mode: on_signal, the default, the comment is created only when a check has something to say. Once it exists it is always updated, to an all-clear line when the findings are gone, so a stale finding never lingers. always posts on every pull request.

Pass/fail checks#

Each check can also post its own GitHub check run, which a branch protection rule can require. All three are off by default and work with or without the checks comment:

Coverage setup#

Measured coverage needs a coverage report from your CI. In the dashboard (Settings → PR bot → a repo's settings → CI checks), Set up coverage has the bot open a draft pull request that adds .github/workflows/repowise-coverage.yml: it runs your tests with coverage and uploads the report with the step below. The bot detects the stack (Python, Node, Go, Java with Maven or Gradle) and the pull request says how to adjust the test command. If your tests already run in another workflow, it explains how to move the upload step there so they run once. Review it, mark it ready and merge it; the next pull request carries a coverage line.

The one-click setup needs two extra repository permissions on the PR bot: Contents: Read and write and Workflows: Read and write. Existing installs see "Approve the new permission" in the dashboard, which links to the installation's settings on GitHub. Everything else (the checks comment, check runs, uploads) works without them.

Or add it yourself. The dashboard shows the generated workflow, and the upload step alone, to copy. Add the step to the job that runs your tests, after the step that writes the coverage report, and give the job the id-token: write permission:

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # lets the upload prove it comes from this repository
    steps:
      # ... check out, install, and run your tests with coverage ...
      - name: Upload coverage to Repowise
        if: always()
        continue-on-error: true
        env:
          REPORTS: "coverage.xml"   # space-separated paths or globs
          HEAD_SHA: ${{ github.event.pull_request.head.sha || github.sha }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
        run: |
          shopt -s globstar nullglob
          files=()
          for pattern in $REPORTS; do for f in $pattern; do [ -f "$f" ] && files+=(-F "report=@$f"); done; done
          if [ ${#files[@]} -eq 0 ]; then echo "::warning::Repowise: no coverage report found at: $REPORTS"; exit 0; fi
          auth=()
          if [ -n "${ACTIONS_ID_TOKEN_REQUEST_URL:-}" ]; then
            token=$(curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=repowise" | jq -r '.value // empty' || true)
            [ -n "$token" ] && auth=(-H "Authorization: Bearer $token")
          fi
          curl -sS --fail-with-body --max-time 60 "${auth[@]}" "${files[@]}" \
            -F "repository=$GITHUB_REPOSITORY" -F "head_sha=$HEAD_SHA" -F "pr_number=$PR_NUMBER" \
            -F "event=$GITHUB_EVENT_NAME" -F "run_url=$RUN_URL" -F "workspace=$GITHUB_WORKSPACE" \
            https://api.repowise.dev/ci/coverage \
            || echo "::warning::Repowise: coverage upload failed; see the message above."

It is plain curl and jq, so it needs no extra action. It never fails the job: a missing report or a failed upload is a warning in the log, and the server's answer (including how many report paths did not match a file in the repository) is printed there too.

REPORTS is a space-separated list of report paths or globs (** works), relative to the repository root. Supported formats: LCOV, Cobertura XML, JaCoCo XML, Clover XML, Go coverprofile, and the Repowise coverage JSON. The format is detected from each file, and absolute paths in a report are made relative to the checkout. Typical values:

Runners. GitHub-hosted runners have curl and jq installed. Self-hosted runners need curl and jq; without jq the upload has no identity and is refused.

Fork pull requests. The upload proves which repository it comes from with a short-lived identity token from the workflow, so no secret is needed. A pull request from a fork gets no such token. Its upload is accepted only when the repository is public and the upload is for the open pull request's current head commit; the comment then labels it "uploaded from a fork pull request without verified identity". Such an upload never replaces a verified one for the same commit. On a private repository, fork uploads are refused.

CI checks settings#

All of them can be set in .repowise/bot.yaml under bot: or on the dashboard.

Configuration#

Two ways to configure, with the dashboard taking precedence:

1. In-repo .repowise/bot.yaml (committed, versioned with the code):

bot:
  enabled: true
  comment_mode: on_signal      # or "always" to post a clean bill of health
  verbosity: standard          # compact | standard | detailed
  show_dead_code: true
  show_change_risk: true
  apply_labels: false          # opt in to repowise:* PR labels (default off)
  ignore_paths:
    - "vendor/**"
    - "**/*.generated.*"
  health_gate:
    mode: advisory             # off | advisory | blocking
    repo_drop_block: 0.3
    min_new_file_score: 7.0
    block_on_introduced: false
    block_ai_regression: false
  checks_comment: true         # the separate CI checks comment
  coverage_check_run: true     # Repowise / coverage
  coverage_fail_under: 80      # percent of changed lines; omit to report only

You can toggle any section (show_summary, show_health, show_hotspots, show_ownership, show_coupling, show_dead_code, show_refactoring, show_declining_alert, show_change_risk, show_review_priority, show_checklist, show_change_map), set the comment threshold, choose the verbosity, and ignore paths.

PR labels (opt-in)#

With apply_labels: true the bot also applies repowise:* labels, created on demand and reconciled on every run: a label is removed once its signal clears, and labels outside the repowise: namespace are never touched.

They are off by default, and the list is short on purpose. A label is permanent, binary, and public in the pull-request list, so it reads as a verdict on the author in a way an editable comment does not, which means it has to be reserved for things that are actually rare. Signals that fire on ordinary work (a repo score that dipped, a hotspot touched, a moderately-sized diff) stay in the comment, where they carry their context with them.

2. The hosted dashboard (Settings → PR bot). The dashboard config overlays the YAML: any field set there wins, fields it omits keep the YAML/default value, and ignore_paths is unioned (the dashboard can only add scope, never silently un-ignore a path the repo author chose to skip). A malformed value is skipped, never wedging the analyzer.

Pricing#

Signals is free forever for public / OSS repos: no model, no tokens, no PR cap. AI triage and Full AI review are part of Pro and billed from credits (see review modes). Private repos require the Pro plan as well. Private installs still index on connect, so the snapshot is ready when you upgrade. See the pricing page.

How it relates to the rest of Repowise#

Same engine, different surface. The bot reads the code-health, git-intelligence, and dependency-graph layers, and every comment links to the live dashboard snapshot, where the same data is queryable by humans (the web UI) and by AI agents (the MCP tools, including get_health for a pre-PR self-check).