Wire
Install the Harbor GitHub App and review your first pull request.
Install the Harbor GitHub App from Harbor, pick its repos on GitHub, turn on Code review, and read what Harbor posts on your first pull request.
One app does two jobs, and you turn each on in its own place. Each needs the app. Neither needs the other: a repo can be reviewed without being read into the brain, and the other way round.
| Job | What it does | Where you turn it on |
|---|---|---|
| Learn | Reads pull requests merged into the default branch, with their review discussion, and turns the decisions in them into rules in your team’s brain. | Sources, one switch per repo |
| Review | Checks each pull request against the repo’s rule files and your brain, and comments on the lines that break a rule. | Code review, one switch for the workspace |
This page walks through both, in order. For the review’s settings and states at a glance, see how the pull request review works.
Before you start
- A Harbor workspace where you are an owner or admin. Only owners and admins see Sources and the Code review page.
- The right to install apps on the GitHub account that owns the repos. On an organization that is an owner. A member can still start, and GitHub sends an owner the request (see “If an owner has to approve it” below).
- Rules to check against. A rule file in the repo (CLAUDE.md, AGENTS.md, Cursor or Copilot rules, CONTRIBUTING.md and more, see which agent reads which rules file), rules in your brain, or both. A review checks against those and nothing else.
- Your plan’s limits. On Free you can switch on one repo to learn from, and you get 10 reviews in all. On Pro, GitHub is one source however many repos it reads. See plans and limits.
Install the app
Open GitHub in Sources
In the web app, open Sources and press Connect on the GitHub row. The page that opens has two steps, Authorize and Pick repositories, and lists what Harbor reads and what it never reads. Press Authorize GitHub.
A pop-up opens. If your browser blocks it, Harbor says
Couldn’t open the GitHub sign-in window
. Allow pop-ups for the site and press the button again.Sign in and authorize Harbor Brain
The first time, GitHub asks you to authorize Harbor Brain, the app’s name on GitHub. This tells Harbor who you are, so it can check that you manage the installation it is about to connect.
If you already manage exactly one installation of the app that no Harbor workspace has, Harbor connects it now, with no install page.
Install it on the account that owns your repos
GitHub shows the install page for Harbor Brain. Pick the organization or personal account, then the repositories: All repositories, or Only select repositories and pick them. Below that, GitHub lists what the app may do:
What the Harbor GitHub App asks GitHub for, and why Permission Access What Harbor uses it for Contents Read Copy the repo for a review and read its rule files. Harbor cannot push, so nothing is ever committed. Metadata Read List the repos you give it. GitHub requires this of every app. Issues Read Read the pull request conversation, which is where @harbor-brain commands are written. Pull requests Read and write Read pull requests and their review discussion. Post the summary comment, the line comments and the replies. Checks Read and write Post the Harbor review check, and hear the Re-run button. Press Install. GitHub also sends Harbor events from these repos: pull requests opening, changing and merging, comments on them, and the Re-run button.
Back in Harbor
The pop-up closes itself. If it stays open, it says Connected or Could not connect: close it, or press Return to Harbor. Once connected, Harbor moves to Pick repositories and says
GitHub is connected. It reads nothing until you switch something on.
If an owner has to approve it
A member who cannot install apps sees Request on GitHub instead of Install, and GitHub sends the request to the organization’s owners. Harbor says Request sent, and until an owner approves it, GitHub shows as Waiting for approval on Sources.
The owner who approves it finishes connecting it:
ask them to connect GitHub from Sources in Harbor.
On an organization, only the person who installed the app can connect it, and the owner who approves the request counts as that person, so pressing Connect yourself afterwards does not work. They need to be an owner or admin of your Harbor workspace, so invite them first if they are not in it.If you installed it from GitHub first
Installed from the app’s page on GitHub instead of from Harbor, the pop-up ends on
The Harbor GitHub App is installed. Finish connecting from Harbor: open Sources and click Connect on GitHub.
Do that, and Harbor finds the installation.If it did not connect
Harbor says What to do That GitHub installation is already connected to another workspace. One installation belongs to one Harbor workspace. Disconnect it in the other workspace first. You administer Harbor on more than one GitHub account (…) Harbor cannot tell which one this workspace means. Uninstall it from the accounts you do not want connected, then try again. That GitHub installation is not one you administer. Nothing was connected. Ask someone who manages that installation on GitHub to connect it. Only the person who installed Harbor on ‹account› can connect it. On an organization, the person who installed the app connects it, and an owner who approved your request counts as that person. Ask them to press Connect in Harbor. They need to be an owner or admin of your Harbor workspace. This authorization was started in a different browser. Start it again from Harbor, in the browser you are using now. OAuth state expired The link lasts 10 minutes. Press Authorize GitHub again. GitHub is temporarily unavailable. Please try again. Wait a minute and press it again.
Choose what Harbor learns from
Switch on the repos that carry decisions
The repos you gave the app are listed, all switched off. Switch on the ones whose pull requests record how your team works. When you switch one on, you pick how far back it reads:
- Import history, the default: pull requests merged in the last 30 days on Free, or the last 12 months on a paid plan, with their reviews. The card says your plan’s window.
- Start from today: only what merges after you switch it on.
The import runs in the background, a few repos at a time, and the repo’s row shows how far it has got: history import queued, then importing history. The first decision it finds shows up in Review.
Give each repo a Space
A repo you switch on needs a Space: pick one in Pick a space on its row. A repo with no Space produces nothing, and Harbor spends nothing on it. The row’s ⋯ menu holds two separate switches:
- Read into the brain: learn from this repo’s merged pull requests, into that Space.
- Serve agents working here: link the repo to the Space, so coding agents working in it get the Space’s rules. A review of a private repo reads the rules of the Space it is linked to, plus the rules for the whole workspace.
The row says which of the two it does, for example
reads and serves Engineering
.
Learning reads pull requests merged into the default branch: the description, the conversation, and the review comments. Pull requests opened by Dependabot, Renovate, GitHub Actions and other bots are skipped. What becomes a rule, and what waits for a person, is in what coding agents remember and who approves it. Every connector side by side is in connect GitHub, Slack, Notion and Jira.
Turn on Code review
Open Code review and turn it on
Open Code review in the sidebar and turn on Review pull requests. Every setting on the page:
Setting Choices What it does Review pull requests On or off. Starts off. Turns reviews on for the workspace. Installing the app alone starts nothing. Repos All connected repos, or Only these repos. Starts on all. Every repo the app can see on GitHub, or only the ones you tick. A repo does not need to be switched on in Sources to be reviewed. Review Every pull request, or Only on @harbor-brain review. Starts on every pull request. When a pull request opens or is marked ready for review, or only when someone asks. Review again on each push On or off. Starts off. A push to an open pull request gets another review two minutes later. Findings already posted are not posted again. Block merging until the review finishes On or off. Starts off. The Harbor review check appears the moment a pull request arrives, so GitHub can wait for it. See “Hold a merge until the review has run” below. Whose key pays Harbor’s key, or Your own Anthropic key. Starts on Harbor’s key. Who pays the model. Claude Haiku 5.5 reviews, and Claude Sonnet 5.5 checks what it found. If the page says Approve Harbor’s new GitHub permissions, your installation is older than what reviews need. Press Open the installation on GitHub, accept the new permissions there, and come back.
Using your own Anthropic key
Choose Your own Anthropic key, paste the key, and press Test key, then Save key. Harbor tests it again before saving, refuses a key Anthropic turns down, and stores it encrypted. After that the page shows only its last four characters. Forget the saved key moves reviews back to Harbor’s key. The test answers one of:
The key works.
Anthropic does not accept this key.
Check you copied the whole key.Anthropic accepts the key but refuses it this call; check its permissions.
Could not reach Anthropic. Try again in a moment.
Open your first pull request
Open a pull request on a repo the app can see
Open it as you always do, or let a coding agent open it. Agents’ pull requests are reviewed like anyone else’s. A draft is not reviewed until it is marked ready, or someone asks.
Wait about two minutes
Harbor waits about two minutes so that a burst of pushes makes one review, and reads the pull request as it is when the review starts. With Block merging until the review finishes on, the Harbor review check is already there, queued:
Harbor will check this pull request against the team’s rules in about two minutes.
Read the result
The check turns to in progress, then posts its result, usually a few minutes later. Harbor posts three things:
- The Harbor review check, with a one-line title.
- One summary comment, which lists every finding. A later review edits it in place, and a
@harbor-brain reviewgets a new one. - Up to 8 line comments, in one GitHub review. Past 8, a finding is in the summary only. A later review does not post the same comment twice.
Read the review
The check
The title next to Harbor review says what the review found. Harbor never fails a check, so a broken rule informs the merge and does not block it. Some titles you will see:
| Title | What it means |
|---|---|
| 2 team rules broken · 1 rule out of date · 1 worth a look | Grey. The counts of what it found. The summary lists each finding, and line comments mark them in the code. |
| 212 rules checked, from AGENTS.md and CLAUDE.md · none broken | Green. What it checked against, and that nothing broke. The numbers and files are your repo’s. |
| no rule applies to the files changed | Green. It had rules, and none of them covers these files. |
| … · partial review | Grey. Part of the review did not run. The summary says which part and how to run it again. |
| nothing to check | Grey when it found no rule file and no brain rule to use. Green when the pull request changes only lockfiles, minified files or test snapshots. |
| not reviewed | Grey. The summary says why: Code review is off, the repo is not ticked, the workspace has used its reviews, the pull request changes more than 300 files or became a draft, or it is a dependency update or an outside fork. |
| did not start | Grey. Harbor could not start the review. Comment @harbor-brain review to try again. |
| not reviewed on this push | Grey. Review again on each push is off. |
| not reviewed until asked | Grey. The workspace reviews only when someone asks. |
| will run again | Grey. The model provider was busy. Harbor tries again in a few minutes. |
| did not finish | Grey. The summary says what stopped it and what to do next. |
| replaced | Grey. A newer review of the same commit took its place. Read that one. |
The summary comment
It opens with Harbor review and the check’s title, then, in this order:
- A Partial review: line, only when part of the review did not run: a reviewer failed, or the review reached its $3.00 spend cap ($1.50 on Free).
- A few sentences on what the pull request does.
- One line per finding, for example
. A finding with no line comment also says why.src/db/user.ts:14Team rule: … - Worth a look: up to three lines worth a second look that break no rule, for example two rules that
say opposite things here
. They never turn the check grey. - The last line: how many commits it read, the models, whose key, how long it took and what it cost, for example
Reviewed 3 commits · Claude Haiku 5.5, checked by Claude Sonnet 5.5 · 1m 5s · $1.20
.
A line comment
A line comment has up to five parts, top to bottom:
| Part | What it holds |
|---|---|
| Team rule · path:line | What kind of finding it is, and where. Rule out of date when the pull request makes a rule stale. |
| The explanation | What the change does against the rule, in a sentence or two. |
| Fix: … | What would bring the line back in line with the rule, when there is a clear fix. |
| Rule: … | The rule’s own words, up to 300 characters, and where it lives: a link to the lines in a rule file (from CLAUDE.md:12-14), or to the rule in Harbor (in Harbor). |
| The last line | What you can do about the rule. The next table lists every version of it. |
The last line is one of these, and tells you what you can do:
| Last line | What it means |
|---|---|
| This PR also changes this rule, so approving it approves the new rule. | The pull request edits the rule it breaks. A reviewer approving the pull request is approving the new rule. |
| Disputed since 2026-11-06. | Someone already disputed this rule, with the date. Its owner has not decided yet. |
| Rule wrong? Change it in this PR. | The rule is in a rule file in the repo. Edit the file in this pull request. |
| Harbor flags this rule for an update when this PR merges. | The pull request makes a rule in your brain out of date. Nothing to do: the merge files it for its owner. |
| Rule wrong? Reply @harbor-brain wrong and say why. | The rule is in your brain. Reply under this comment with your reason. |
A rule out of date
A Rule out of date finding means the pull request makes a rule stale: it changes the thing the rule describes. It is not a mistake in the pull request. It is the rule that needs updating.
Ask Harbor on a pull request
Two commands, written in a comment on the pull request:
| Write | Where | What it does |
|---|---|---|
| @harbor-brain review | A comment in the pull request conversation. | Asks for a review, which starts about two minutes later. It works on a draft, and when the workspace reviews only on request. Code review still has to be on, and the repo ticked. |
| @harbor-brain wrong, then why | A reply under Harbor’s line comment. In the conversation it works only when the summary cites one rule. | Marks that brain rule disputed, with your reason, for its owner to decide in Review. |
@harbor review works too, in any case. When Harbor takes a review command it answers at once, Harbor will check this pull request against the team’s rules. The result replaces this comment in a few minutes.
The Re-run button on the check does the same as @harbor-brain review, except on a pull request from a fork, where only the comment works.
Harbor takes commands from members of the GitHub organization and collaborators on the repo. On a public repo it also takes them from anyone with write access. Anyone else gets no answer at all, and comments from bots and on closed pull requests are ignored.
When a rule is wrong or out of date
Every finding names its rule, and the rule can be the problem. What to do depends on where it lives.
A rule in a rule file
Change the file in the pull request. The comment’s last line says Rule wrong? Change it in this PR.
Reviews read rule files from the base branch, never from the pull request, so a pull request cannot rewrite the rules it is checked against. Your edit counts from the next pull request after it merges, and the people who approve the pull request approve the new rule.
A rule in your brain
Reply under the line comment, with your reason:
@harbor-brain wrong We moved to cursor pagination in October, so offset is the old way.Harbor marks the rule disputed. It does not change or archive it: one person cannot overwrite a team rule from a pull request. Only people who can push to the repo can dispute a rule, and the rule’s owner is notified. Until the owner decides, the rule stays live, and later comments that cite it end Disputed since
and the date.
The owner decides in Review in the web app, on a Conflicting rules · needs your call card: A is the rule as it stands, B is the reason from the pull request. They can keep either one, merge the two into one rule, or say the two do not conflict. Harbor never assumes the newer words are right.
What Harbor can answer:
| Harbor replies | What it means |
|---|---|
| Marked this rule disputed, with your reason. Its owner decides in Review in Harbor. | Done. The rule stays live until its owner decides. |
| This rule is already disputed, so your reason was not added. Its owner decides in Review in Harbor. | Someone disputed it first, from this or another pull request. |
| This rule was already disputed from this pull request. Review in Harbor shows where that stands. | One dispute per rule per pull request. |
| Say why after @harbor-brain wrong, for example what the rule should say now. Its owner reads that to decide. | There was no reason. Reply again with one. |
| This rule is in ‹file:lines›. If it is out of date, change it in this pull request: approving the pull request approves the new rule. | It is a rule file in the repo, not a rule in your brain. Edit the file. |
| Harbor cited more than one rule here, so it cannot tell which you mean. Reply @harbor-brain wrong under the line comment that cites it. | You wrote it in the conversation. Reply under the line comment instead. |
| Harbor has not cited a rule on this pull request, so there is nothing to dispute. | There is no finding to dispute here. |
| Harbor cannot tell which rule this comment cites, so nothing was filed. | Reply under a line comment that ends with Rule wrong?. |
| Only people who can push to this repository can dispute a team rule here, so nothing was filed. | Disputing a brain rule needs write access to the repo. |
| This rule is no longer live in Harbor, so there is nothing to dispute. | It was already archived. |
| Harbor did not file this: the team turned down the same words before. | The owner already said no to the same reason. |
| Harbor could not file this: something failed on our side. Try again in a few minutes. | Nothing was filed. Reply again later. |
A rule out of date, at merge
When a pull request on a private repo merges, Harbor files the brain rules its last review found out of date, up to five, to Review for their owners. It posts no comment and sends no notice, so a merge never floods anyone. Rules in rule files are skipped: the pull request is where those change.
Hold a merge until the review has run
Turn on the check at arrival
On the Code review page, turn on Block merging until the review finishes. The check now appears the moment a pull request arrives, and Harbor shows a link to each repo’s branch rules.
Require it on GitHub
In each repo, open Settings, then the branch rule or ruleset for your default branch, turn on Require status checks to pass, and add Harbor review. Harbor cannot change branch rules for you.
The check always completes, even on a pull request no review will run on, where it says not reviewed and why. Its result is green or grey and never failed, and GitHub lets both through. So it holds a merge until a review has run, and never for a review that is not coming.
What it costs
| Plan | Reviews | Good to know |
|---|---|---|
| Free | 10 reviews in all, on Harbor’s key or your own. They do not come back each month. | A review that stops before it costs anything, and a pull request too big to review, do not count. |
| Pro | $8 of reviews a seat each month on Harbor’s key, then review credit. A seat is a person in the workspace. | The included amount starts again on the first of the month (UTC). Credit never expires. On your own key there is no limit, and its spend does not count. |
| Premium | $12 of reviews a seat each month on Harbor’s key, then review credit. | The same as Pro. |
Each review shows its price on the summary’s last line. Most cost under $1.50; a large pull request checked against many rules can cost a few dollars. The Code review page shows what is left: on Free, N of 10 free reviews left
; on Pro and Premium, the dollars of the included amount left this month, and the review credit.
At the limit, a new pull request gets a not reviewed check that says so, and the workspace gets a banner and an email. On Free, upgrade to Pro to keep reviewing. Your own key does not lift Free’s 10. On Pro and Premium, buy review credit, add your own Anthropic key on the Code review page, or wait for the first of the month.
Buy credit
On the Code review page or the billing page, an owner or admin picks a pack of $10, $25, $50, $100 or $250 and pays in a Paddle checkout. The credit is added once Paddle confirms the payment, and reviews spend it only after the month’s included amount. It never expires, and the founding discount does not apply to it.
Auto top-up, off by default, adds the pack you choose whenever credit falls below $10 or $25, charged to the payment method on the workspace’s subscription, never more than the monthly limit you set. Turn it off any time.
What happens to your code
- Each review copies the repo into a temporary folder, with a token for that one repo that expires within the hour, and deletes it when the review ends.
- The changed code and the parts of the repo the review reads go to Anthropic, on Harbor’s key or yours, to run the review.
- A public repo is checked against its own rule files only, never your brain, because a finding quotes its rule and public comments are public.
- Harbor keeps a record of each review: the pull request’s title and number, the result, the kind, file and line of each finding, the time and the cost. It keeps no code and no model text.
- Everything Harbor posts is checked for secrets first. For a dispute it keeps the reason, with secrets removed, the GitHub login and a link to the comment.
- Harbor never commits to your repo. It posts comments, replies and a check, and that is all it writes.
Change repos, pause, or remove the app
Add or remove repos
Which repos Harbor can see is set on GitHub, not in Harbor. In Sources, open GitHub and press Manage on GitHub, which opens the installation’s page in the organization’s or your own GitHub settings, and change Repository access. Harbor updates its list at once. A new repo arrives switched off in Sources. A repo you take away that was switched on shows as unreachable on Sources, until you turn it off there.
Pause
Turn off Review pull requests to stop reviews, or switch a repo off in Sources to stop learning from it. Suspending the app on GitHub stops both: Sources shows Suspended, and nothing is read until you unsuspend it. Your repo choices are kept.
Disconnect or uninstall
In Sources, open GitHub, then ⋯ and Disconnect GitHub. Harbor stops reading GitHub, deletes its access, and removes the app from GitHub too, so Code review stops there as well. The dialog says so before you confirm. What GitHub already taught your brain stays, no longer linked to the people who wrote it.
If you uninstall the app on GitHub instead, Sources shows Access expired: The Harbor GitHub App was uninstalled. Reconnect to install it again.
Reviews stop either way.
Why is there no Harbor review check?
A pull request Harbor skips gets no check at all, unless Block merging until the review finishes is on or someone asked. Then the check says why. The fastest test is to comment @harbor-brain review. The usual reasons:
- Review pull requests is off.
- The repo is not ticked under Only these repos.
- Review is set to Only on @harbor-brain review, or the pull request is a draft.
- It is a dependency update, or a fork of a public repo from outside the team.
- The app is not on that repo, or it is suspended on GitHub.
A workspace that has used its reviews does get a check, titled not reviewed, that says so.
Why does the check say nothing to check?
Harbor found no rule file it could read on the base branch and no brain rule it may use for this repo. A public repo never uses the brain, and a private one uses the rules for the whole workspace and for the Space the repo is linked to. Commit a rule file with your team’s rules to the base branch, then comment @harbor-brain review. A rule file added in the same pull request does not count, since rules are read from the base branch.