How do I keep one team’s rules out of another’s?

Put each team’s repos in its own Space. A rule filed in a Space reaches only the repos bound to that Space, and only the people who can read it, so the backend team’s conventions never land in the mobile app’s prompts.

A Space is a team or project area inside your workspace: Backend API, Mobile, Infrastructure, Design System. A rule is filed either for the whole workspace or for one or more Spaces. A memory and a source belong to the workspace or to one Space. A preference belongs to the person who stated it, and nobody else ever sees it. Team knowledge cannot be scoped narrower than a Space, which is a deliberate floor rather than a gap: a per-repo or per-person scope is a permission question nobody can answer on their own behalf.

The scope is what keeps the brain focused rather than merely private. A convention that applies to the backend should not be served to somebody working on the mobile app, and the cost of getting that wrong is not a leak, it is a prompt full of rules that do not apply and an agent that starts ignoring all of them.

You choose the scope where the knowledge comes in: approving a proposal, uploading a document, or attaching a connector unit. See connect GitHub, Slack, Notion and Jira to your agents for the connector half, which has one trap worth reading before you connect anything.

How do I share rules across repos?

Bind every repo that should share rules to the same Space, and each one gets that Space’s rules. A rule can also be filed in more than one Space, or made workspace-wide so every bound repo gets it. That is how one team keeps a single set of rules across many repos instead of a CLAUDE.md copied into each: a rule from one repo’s CLAUDE.md, once Harbor imports it and a person approves it, reaches every repo in its Space.

Binding a repo turns Harbor on in it. In a bound repo your agent gets your rules before each prompt and saves what it learns as it works. Every other repo is left alone, and nothing is sent from it. Each bound repo belongs to one Space, which decides whose rules it gets. A new workspace has one Space, the one you just named, and that is all a solo developer needs.

To move a repo to another Space, run harbor bind --project <Space> inside it. That takes repo.bind, which owners, admins and curators hold.

Work outside a repo

Folders that are not a git repo with a remote, such as a scratch folder, a notebook or a training run, are off by default. An admin can send that work to a Space in Settings, Spaces, under “Work outside a repo”, where Goes to is Off or a Space. Then agents in those folders get that Space’s rules, and what they learn is saved to it. Harbor never sends the folder’s path.

Repos with a remote stay off until someone runs harbor bind in them, and an agent started directly in your home folder stays off. Anyone can turn it off on their own machine by running harbor off in such a folder. After an admin changes the setting, each person runs harbor update once to get it.

The five roles

Roles are presets over capabilities rather than the other way round, which is why the interesting question is never “what is a curator” but “which of the thirteen powers does this person hold, and where”.

Workspace roles, strongest first.
Role	Holds	Who it is for
Owner	Everything, including deleting the workspace.	One person. The app has no action that moves ownership; see the ownership section below.
Admin	Everything except deleting the workspace: connectors, members, billing, Spaces, and all of the knowledge powers.	The people who run the account.
Curator	Publish, curate, distribute and bind repos at their scope. No Sources page today; see below.	A senior engineer who should approve rules for their team and touch nothing about the company account. No members, no billing, no credentials, no Spaces.
Member	Read the brain, and capture a learning.	Everybody who uses Harbor. They cannot approve what waits in Review, their own or anybody else’s.
Viewer	Read, and nothing else.	Guests, auditors and trials. The only difference from a member is that a viewer cannot capture.

The thirteen capabilities

This is the matrix the product itself renders on the roles page in settings, so you never have to take a docs table’s word for it. Each row is one hard boolean about one button or endpoint.

Capability	What it grants	Answerable at
`knowledge.read`	See rules, skills and memories at a scope	Space or workspace
`knowledge.capture`	Capture a learning; the workspace setting decides if it goes live or waits in Review	Space or workspace
`knowledge.publish`	Approve or dismiss a proposal, resolve a conflict	Space or workspace
`knowledge.curate`	Edit, archive or re-scope a published rule, skill or memory	Space or workspace
`knowledge.distribute`	Connect a document or skill to repositories and people	Space or workspace
`repo.bind`	Re-point, unbind or pause sync on a repository	Space or workspace
`source.read`	See connectors and what they cover	Workspace only
`source.manage`	Connect, configure or disconnect a connector	Workspace only
`space.manage`	Create, rename or delete a Space and manage who is in it	Workspace only
`member.manage`	Invite or remove people, and change workspace roles	Workspace only
`billing.manage`	Plans, seats and invoices	Workspace only
`workspace.manage`	Rename the workspace and change its settings	Workspace only
`workspace.transfer`	Delete the workspace or transfer ownership	Workspace only

Owner holds all thirteen.
Admin holds twelve: everything but workspace.transfer.
Curator holds seven: knowledge.read, knowledge.capture, knowledge.publish, knowledge.curate, knowledge.distribute, repo.bind and source.read.
Member holds two: knowledge.read and knowledge.capture.
Viewer holds one: knowledge.read.

Why a curator holds source.read but sees no Sources

source.read without source.manage was meant to let a curator see what feeds the brain they curate, without being able to re-point it at a different Slack. Today no screen checks source.read: the Sources page and every action on it ask for source.manage, so a curator sees no Sources entry at all. And because source.read is workspace-rung, a curator of one Space would not get it in any case.

The rest of the role is the answer to the request that has no answer in most products: this senior developer should approve rules for his team, but must not touch billing, members or our Slack credentials. Before curator existed, approving a learning and paying the invoice were the same grant.

What reaches into a Space

A workspace role and a Space role are two different facts, and your effective role in a Space is the stronger of them.

Workspace role	Reach
Owner	Every Space, without being added to any of them.
Admin	Every Space, without being added to any of them.
Curator	Every Space, without being added to any of them.
Member	Only the Spaces they are explicitly added to.
Viewer	Only the Spaces they are explicitly added to.

Inviting people

Admins and owners invite people with the Invite button at the top right of the app; nobody else sees it. Roles change afterwards in Settings, under Members and Access, and Spaces are created, renamed and deleted in Settings, under Spaces. The Free plan caps how many people a workspace holds; see plans and limits.

Moving ownership, and deleting a workspace

The app has no action that transfers ownership, although the roles page still names it under workspace.transfer. To hand a workspace to someone else, contact us.

Only the owner can delete a workspace, in Settings, General, Delete workspace, by typing its name. Every other member has to be removed first. Deleting it revokes Harbor’s Slack bot, its GitHub App installation and every sign-in grant it holds for your connected tools, then removes the workspace and all its data. It cannot be undone.

Start with one or two Spaces

Not five. A Space earns its existence when a rule in it would be wrong somewhere else, and until you have seen that happen, a workspace-wide scope is both simpler and more useful. You can re-scope a published rule later, which is what knowledge.curate is for.

The one thing worth doing early is making somebody a curator for their own area. The failure mode for this whole product is a review queue nobody clears, and the fastest cause of that is one admin being the only person allowed to approve.