Connect GitHub, Slack, Notion and Jira to your coding agents.

What a connector actually does

A source is one tool your team already uses, watched for the things that would be non-obvious to somebody new. When a pull request merges or a decision lands in a channel, the connector reads that one unit of work and proposes what it learned.

It proposes rather than decides. Whether that proposal waits for a person is a workspace setting, and it is the same setting that governs what your agents capture. One dial covers both inlets, so a fact distilled from Slack is treated exactly like the same fact recorded by an agent. On the default setting, Hybrid, a routine extraction goes live straight away, marked as not yet reviewed: it is on trial, and it ranks below reviewed rules until something reinforces it. See what gets in, and what stays for the setting and what each position does.

Six things wait for a person in every setting, including the most permissive one, and the row in Review says which after Waiting because:

• A review of a coding agent’s pull request, read while the pull request is still open, so the correction lands before the agent’s next session.
• A review comment on a person’s pull request, because about one in three of those is a bug report rather than a rule.
• A check that failed while Harbor was deciding, so it waits rather than go live unchecked.
• No author: nobody in your workspace can be named as the one who wrote it.
• An author Harbor could not match to anyone in your workspace: an outside contributor on a public repo, a Slack Connect guest, or a colleague whose email in that tool differs from their Harbor email.
• A contradiction Harbor could not settle: it reverses a live rule, and the conditions below for replacing it do not hold.

A private repo answers for an author it cannot name, because an admin decided who can push to it. A public one does not. On Hybrid, two more wait: a Sentry error, and a quote from a Granola meeting. Only Auto adds those on its own.

A connected source never replaces a live rule on its own, whoever wrote the message, the page or the pull request. When an item reads as reversing a rule, both wait in Review as a pair and the old rule keeps serving until a person picks. Approve retires it, and Knowledge keeps a Restore.

It also declines a great deal without asking you. The filter is whether a fact would be non-obvious to a new joiner, so a convention that can be read off the code does not become a rule about the code.

What each connector reads, and what it never reads

Two columns matter here and the second one matters more. Every string below is read from the same constant the product’s own connector tiles render from, so what this page promises and what your Sources page says cannot drift apart.

Gmail and Outlook Mail also appear on your Sources page, folded under Coming soon with an Ask for it button. They cannot be connected and read nothing yet, which is why they are not rows here.

Import history or start from today

Above a tool’s list of channels, repos or folders, Sources shows one choice: Import history or Start from today. Every unit you switch on in that tool follows it, and Import history is the default.

• Import history reads what was already there. The line under the choice says how far back, in that tool’s own words, and the third column below is that line.
• Start from today reads only new work. The line says Harbor reads only what happens after you switch it on. Nothing from before. The unit’s row then reads no history imported and offers Import history, in case you change your mind.

How far back an import reaches depends on your plan: on the Free plan it reads the last 30 days instead of 12 months (see plans and limits). Google Drive does not follow that window: it reads every file already in the folder, however old, on every plan. Sentry follows it but never reaches back past 90 days, so on a paid plan it reads 90 days, not 12 months.

How often each source syncs

Four sources push work to Harbor the moment it happens: Slack, GitHub, GitLab and Sentry. The other six are checked every 15 minutes. Either way, whatever goes live reaches your agents the next time they look up your team’s rules.

Connecting one

Sources is admin-only. A member has no nav entry, the route bounces, and the API answers 404 rather than 403, so the surface does not confirm its own existence to somebody who cannot use it. Every Sources screen asks for source.manage, which owners and admins hold. A curator holds source.read, but no screen accepts it today, so a curator does not see Sources either. See roles and access for the full table.

1. Open Sources and pick the tool

   Sources is one list, with All, Connected and Available tabs. Each row states what that connector reads before you grant anything, and Connect starts the grant. Most tools open their own consent screen: You will be asked to approve access in a pop-up window. Notion, Granola and Sentry take an API key you paste into Harbor instead: You will be asked to paste an API key. No pop-up opens. For Sentry the key is the token of a Sentry internal integration. Harbor also asks for its client secret and your organization slug, and shows the webhook URL to give Sentry before you paste them.

2. Pick the units

   Channels, repos, folders, teams, spaces, projects. This is the step that decides everything: an unenabled unit is not watched, not polled and not readable. Granting the integration does not turn on a single channel. Above the list, choose whether a unit you switch on imports its history (see above).

   The Free plan reads one channel, repo, folder or space at a time (see plans and limits). Past it, every other switch is greyed out and explains: Your plan includes 1 source, and it is already in use. A source is one channel, repo, folder or space. Turn one off to swap it, or upgrade for more.

3. Attach each unit to a Space

   Every unit you enable has to be attached to at least one scope, and this is the step people skip. It decides who the knowledge is served to, and on GitHub and GitLab it decides whether any knowledge is produced at all. See below.

4. Read the first few, wherever they land

   Some will be waiting in Review and some will already be live on Knowledge, depending on your capture setting. Either way, judge two or three by hand early: what you approve, edit or archive is what teaches Harbor where your team draws the line, and the first week is when that teaching is cheapest.

Scoping each unit to a Space

Knowledge is scoped so that a backend convention is not served to somebody working on the mobile app. You choose that scope where the knowledge comes in, which for a connector means on the unit: this repo feeds that Space. Most connectors take the first scope on the unit, whether that is the whole workspace or one Space. GitHub and GitLab do not: a repo has to name a Space, and the next section is what happens when it does not.

Why does my GitHub repo produce nothing?

Most often because the repo is attached to no Space: GitHub and GitLab drop every pull request from such a repo before spending anything on it, because a repo’s knowledge must never spread to the whole workspace. The repo’s row says so. It reads Not scoped, with a line saying nothing from the repository becomes knowledge until you pick a Space. When the repo is already bound to a Space with harbor bind, the row starts on that Space.

If the row names a Space, check these in order:

• The repo is switched on. The source’s status reads Nothing selected when no repo is. On the Free plan, another channel, repo or folder may be holding the one source it includes.
• A pull request merged into the default branch. Harbor reads a person’s pull request once it merges, and skips one opened by a bot (Dependabot, Renovate, GitHub Actions, Snyk, or any account ending in [bot]), a revert or auto-merge, and one whose description has under 80 characters of real prose. A review comment needs 80 characters of prose too.
• It landed in Review, not Knowledge. Review comments always wait for a person, so check Review as well.
• Nothing in it was new to a new joiner. The filter keeps what would be non-obvious to somebody new, so a quiet week of routine merges can produce nothing. This is common and is not a fault.

A source that has read nothing for 7 days says so in its status: Nothing read yet, or Nothing new in 9 days with the real count.

Pull requests from coding agents, and rules files

A review of a coding agent’s pull request is read while the pull request is open. A person correcting an agent (“not like this, regenerate the migration”) is the most useful thing a repo says, and waiting for the merge would be too late: the agent’s next session has already started without it. Harbor treats a pull request as an agent’s when GitHub Copilot’s, Jules’s or Devin’s bot account opened it, or when its branch starts with claude/, cursor/, copilot/, codex/, jules/ or jules-. Each review and inline comment a person leaves on it goes to Review at once, and waits there for a person in every setting. A pull request a person opened is still read only when it merges.

Rules files do not come through this connector. Connecting a repo does not read its CLAUDE.md or AGENTS.md. Those reach Harbor when somebody runs harbor init or harbor bind in the repo, which files each rule in Review for a person. See how Harbor imports CLAUDE.md, AGENTS.md and Cursor rules.

How do I give my agent context from Slack?

Connect Slack in Sources, switch on the public channels where your team settles things, and give each one a Space: the decisions, blockers, completions and questions answered there become rules that Claude Code, Codex, Cursor and GitHub Copilot are handed while they work. Switching a channel on adds the Harbor bot to it, and Harbor reads that channel and nothing else. DMs and private channels are never read.

For one decision, you do not have to switch a channel on. Type /harbor remember with the rule, or pick Remember in Harbor from a public message’s menu. The tutorial for saving a decision from Slack walks through it, and the Slack knowledge bot answers questions from the same brain.

When Harbor cannot tell who wrote it

GitHub, GitLab and Slack give Harbor a handle, not an email, so a colleague’s captures can wait in Review only because nobody has linked their account. Their rows say Waiting because Harbor could not match its author to anyone in your workspace. Two places fix it, both for admins:

• People, on the source’s page in Sources. It lists everyone that source has shown Harbor, unlinked first, with a line like 3 of 12 aren’t linked to anyone in Harbor yet. Linking them names everything they have added. Each row reads Not linked until you pick the person. For Slack, GitHub and GitLab, Import people fills the list from the tool’s roster before anyone has written anything.
• Review. Above the queue, one line per person, with the same picker: Dana isn’t linked to anyone in Harbor, so 4 of their items wait for review. A reviewer who cannot link sees Ask an admin to link them. after it.

Linking names that person as the author of everything they already added. What is already waiting stays in Review for a person to decide, and their next captures are judged like any colleague’s.

Where to start

The order below is the one that gets a team to a useful brain fastest, and it is worth following even on a plan that lets you connect everything at once.

• Start with GitHub. Review discussion on merged pull requests is the richest tribal knowledge most teams have written down anywhere. On the Free plan, pick the one repo where most decisions get argued, since Free reads one source.
• Add one Slack channel. The one where engineering decisions actually get made, not the busiest one.
• Then stop. Clear that queue before connecting a third source. A queue nobody reviews is the failure mode for this whole surface, and it arrives fastest for the teams who connect everything on day one.