How the repowise PR Bot Comments Only When It Matters

pr bot silent default is the only sane default for review automation. A GitHub PR bot should stay out of the way on green changes, then speak only when it has a concrete reason to add noise. That is the design behind the repowise PR Bot: it posts one deterministic comment per pull request only when repo health changes, hidden coupling appears, or dead code shows up. GitHub already gives humans a place to review and comment on PRs, so a bot should earn its place in that thread, not flood it. (docs.github.com)

Part of the Change Risk guide.

The PR-bot noise problem

Most PR bots fail the same way: they comment on every diff, every run, every file, every time. The result is comment fatigue. Reviewers start scanning past the bot before they scan the code. Authors learn to ignore it. Then the bot becomes a tax on attention instead of a source of signal.

That pattern is easy to create and hard to undo. GitHub pull request reviews are built for human back-and-forth, with comments, line notes, and review states. A bot that posts like a chatty reviewer competes with that workflow instead of fitting into it. (docs.github.com)

The better model is a github pr bot less noise posture: no comment unless something changed in the repo’s actual health. That means fewer pings, fewer screenshots pasted into Slack, and fewer “thanks bot” replies.

Why “comment on every PR” fails

A bot that comments on every PR creates three kinds of waste:

1. Cognitive waste. People re-read boilerplate.
2. Workflow waste. Maintainers triage the bot before triaging the change.
3. Trust waste. Once the bot says obvious things, people stop believing the less obvious things.

In practice, a bot gets one shot at being useful. If it is loud on trivial changes, its signal is gone.

What “green PR = no comment” should mean

A true pr bot silent default is not “the bot is off.” It means the bot has a strict no-op path for the common case. If the PR does not change the repo in a meaningful way, it stays quiet.

For repowise, that means the bot is silent when the change does not move any of the tracked health indicators. repowise’s current platform includes a code health layer with 49 markers across three pillars, per-file health scoring, module rollups, untested-hotspot detection, refactoring target ranking, and declining-health trend alerts. The bot only comments when a PR changes one of those measurements in a way that matters. (repowise.dev)

That silence is a feature. GitHub already supports reviews, approvals, and inline comments for human judgment; the bot’s job is to surface repo-level risk that humans would otherwise miss, not to restate what the diff already shows. (docs.github.com)

The default should be boring

If a PR adds tests, fixes a typo, or moves code without changing health, the bot should do nothing. That keeps the review thread clean and makes the rare comment feel worth reading.

The six conditions that trigger a comment

repowise’s PR bot posts only when one of six deterministic conditions is met. Each one is rooted in repository intelligence rather than a vague “AI opinion.”

These are deterministic checks. No prose generation is needed to decide whether a comment should exist.

Net health degradation

The first trigger is the simplest: if the repo’s overall health score drops enough, the bot comments.

This is the top-level warning sign. It does not try to explain every line item in the comment. It just says the PR made the repository less healthy and points to the scored changes. That is enough to pull a reviewer back to the right spot in the diff.

repowise added code health in v0.10.0 as a fifth intelligence layer, with per-file scoring and module rollups. That matters here because the bot is not guessing from style alone. It is reading health deltas produced by the platform. (github.com)

Per-file health drop

A repo can look fine overall while one file gets worse. That is common in large codebases. One PR can tuck complexity into a helper, a service boundary, or a low-traffic module, and the aggregate score barely moves.

The bot comments when a file’s health drops sharply enough to be worth attention. This is the right level for a code review bot signal because it gives reviewers a target. They do not have to inspect the entire repo health report to find the regression.

Hotspot touch

Hotspots matter because churn and complexity multiply each other. A change in a hotspot deserves a different review posture than a change in a cold file. repowise’s git intelligence layer already computes hotspot analysis as churn × complexity, plus ownership maps, co-change patterns, and bus factor detection. (github.com)

A bot comment on hotspot touch is useful because it tells reviewers, “this change landed in code that already absorbs a lot of maintenance pain.” That is a higher-value warning than a generic “consider refactoring” note.

Missing co-change partner

Some files travel together. If two modules almost always change in the same PRs and only one of them appears in the current diff, that can mean the patch is incomplete.

This trigger is valuable because it catches hidden coupling. The bot is not saying the PR is wrong. It is saying the historical pattern suggests a sibling file might need a matching edit. That is a concrete prompt for the reviewer.

New dead code

Dead code is cheap to add and expensive to forget. A bot comment on new unreachable files or unused exports makes the cost visible while the branch is still open.

repowise’s dependency graph and dead-code detection exist for exactly this kind of check. The graph finds what still matters. Dead-code analysis finds what no longer does. A comment here is not noise; it is cleanup pressure applied at the right time. (repowise.dev)

Declining-health alert

The fifth and sixth triggers are similar but not identical. A declining-health alert means the module is already trending down before the PR lands. The bot comments when the new change pushes that trend further in the wrong direction.

That is useful because it changes the review frame. Reviewers can ask, “Should this module be refactored before we keep adding to it?” instead of only asking whether the current diff is syntactically correct.

How the bot stays cheap: zero LLM calls

The bot is deterministic by design. It does not call an LLM to decide whether to comment. That keeps it fast, reproducible, and cheap.

This matters more than it sounds. A review bot that depends on model inference for its basic gating logic can change behavior across runs, providers, or prompt revisions. A deterministic bot review system avoids that drift. repowise supports multiple LLM providers in the broader platform, but the PR bot’s comment decision path does not need one. (repowise.dev)

What determinism buys you

1. Stable output. Same input, same result.
2. Lower cost. No token bill for gating.
3. Easier debugging. You can trace the rule that fired.
4. Better trust. Maintainers can predict when it will speak.

If the bot commented, there is a measurable reason. If it stayed quiet, that was also a measured choice.

What it does not do

It does not write a long narrative about code style. It does not guess intent from tone. It does not hallucinate architectural advice. The review thread stays focused on the actual regression signal.

PR Bot Noise Grid

What the comment looks like

A useful bot comment should read like a terse incident note, not a blog post.

A good comment has four parts:

1. Trigger name. What fired.
2. Evidence. The file, module, or metric that changed.
3. Impact. Why the change matters.
4. Next step. What the reviewer should inspect.

That structure keeps the comment short while still being actionable.

Example format

repowise PR Bot: comment triggered

- net health: 82 → 74
- hotspot touched: src/payments/ledger.ts
- missing co-change partner: src/payments/reconciliation.ts usually changes with this file
- new dead code: src/payments/legacy.ts

Why this matters:
This PR touched a high-churn module and introduced unreachable code.

Suggested review:
Check whether reconciliation.ts needs the same API change.

That is the shape you want: deterministic, compact, and tied to evidence.

GitHub supports review comments and review requests in the pull request flow, so the bot comment should feel native to that interface rather than like an external alert feed. (docs.github.com)

What it should avoid

• Praise.
• Generic advice.
• “Looks good to me.”
• Long summaries of unchanged files.
• Repeating what the diff already says.

If a human already sees it in the patch, the bot should not restate it.

Installing and configuring

repowise is self-hostable and open source under AGPL-3.0. The broader platform includes auto-generated docs, git intelligence, dependency graphs, and MCP tools for agents. The PR bot sits on top of that same index, so it can make its comment decisions from the repo intelligence already computed by the system. (github.com)

Step 1: Install repowise

pip install repowise
repowise init

If you are starting from scratch, use the install flow on the site and connect your repo. repowise also documents a GitHub App setup for private repo indexing and PR review bot support. (repowise.dev)

Step 2: Index the repository

Let repowise build its intelligence layers:

• auto-generated docs
• dependency graph
• ownership and hotspot data
• dead code detection
• health scores

If you want a concrete example, the FastAPI dependency graph demo shows how the graph layer fits into real code. The hotspot analysis demo shows what churn and complexity look like on a live repo. The architecture page explains how the layers fit together. The live examples page is a good place to see the outputs before wiring it into your own repo.

Step 3: Turn on the PR bot

Install the GitHub App and configure it to watch pull requests. Once connected, the bot reads the repo’s health data and applies the six deterministic triggers.

Because the bot is silent by default, there is no need to tune a bunch of comment thresholds just to stop it from spamming you. You tune the signal rules once, then let the default do the rest.

Step 4: Decide what counts as a comment

This is the part teams should be opinionated about.

A strong default policy is:

• comment on net health regression
• comment on file health drop above a threshold
• comment on hotspot touches
• comment on new dead code
• comment on declining-health modules
• comment on missing co-change evidence

Do not add more triggers unless they survive real use. Every extra trigger is a chance to turn signal back into noise.

Health Trigger Matrix

Why this is better than a chatty reviewer bot

A chatty bot treats every PR as equal. A silent-default bot treats each PR as evidence.

That difference is the whole point.

GitHub’s built-in review flow already supports comments, reviews, and approvals. The bot should add information that humans do not already have at a glance. The current research on reviewer bots also points in the same direction: bot comment quality, relevance, and conciseness matter more than raw volume. (docs.github.com)

repowise’s choice is to comment less, but only when the repo-level signal is real. That makes the bot easier to trust and cheaper to keep around.

The maintainer test

Ask one simple question:

If this bot disappeared tomorrow, would the team miss its comments?

If the answer is no, the bot is too noisy. If the answer is yes, you have a useful bot.

Where this fits in repowise

The PR bot is one piece of a larger system. repowise also generates file-level docs, ownership maps, dependency graphs, and code health reports that feed agents through MCP tools. MCP itself is an open standard for connecting AI apps to tools and data sources, and the current spec uses dated version identifiers such as 2025-11-25. (modelcontextprotocol.io)

That matters because the PR bot is not a separate guesser. It is a thin surface on top of a repository intelligence layer that already knows where the risk is.

If you want to see the surrounding pieces, start with auto-generated docs for FastAPI to see the output shape, then look at repowise's architecture to see how the index feeds the bot. If you want to try it, try repowise on your own repo and let the GitHub App wire up the rest.

Deterministic PR Comment Card

FAQ

What does “pr bot silent default” mean?

It means the bot does nothing on the common case. No comment, no ping, no background chatter. It only speaks when a measurable condition changes the repo’s health.

Why is a silent GitHub PR bot better than a chatty one?

Because review threads are limited attention spaces. GitHub already provides review comments and approvals for human feedback, so the bot should only add repo-level signal that humans might miss. (docs.github.com)

What makes repowise PR Bot deterministic?

Its comment decision is based on fixed rules and repository metrics, not on an LLM’s generated judgment. That makes it stable across runs and cheap to operate. repowise’s broader platform supports multiple LLM providers, but the PR bot does not need one for the comment gate. (repowise.dev)

Does the bot comment on every pull request?

No. It stays quiet unless one of the six trigger conditions fires: net health degradation, per-file health drop, hotspot touch, missing co-change partner, new dead code, or declining-health alert.

Is repowise open source?

Yes. repowise is open source and self-hostable, and the project is published under AGPL-3.0. (github.com)

How do I try the PR bot on my repo?

Install repowise, index the repo, and connect the GitHub App. Start with pip install repowise && repowise init, then follow the install flow on the repowise site. (repowise.dev)