Feed
Team conventions for coding agents: what gets in, and what stays.
What gets in, and what stays. Harbor keeps your team’s conventions, decisions and gotchas from agent sessions, Slack and pull requests, one setting decides whether a capture waits for a person, and stale rules leave on evidence rather than on anyone’s memory.
What should a coding agent remember?
The things your team would otherwise explain again in every session: the conventions you hold to, the decisions you made and why, the traps that cost someone an afternoon, and the facts about the team that are not in the code. A CLAUDE.md or AGENTS.md file holds some of that for one repo; Harbor holds it for the team, and hands each agent the part that fits the task.
What an agent is told not to record: its own machine setup, anything phrased “currently broken” or “not yet”, how it got a throwaway script working, and an error that went away on a retry.
Everything on the Knowledge page is one of seven kinds:
| Kind | What it is | For example |
|---|---|---|
| Rule | A standard your team holds to, or a decision and its reason | "Database columns are snake_case, including in migrations." |
| Pattern | A shape that recurs, and where to copy it from | "Every endpoint validates in middleware, never in the handler." |
| Gotcha | A trap that cost somebody an afternoon | "The deploy script needs the VPN up or it fails at the last step." |
| Always-on | A rule pinned to every session, whatever the task | "Every change to main goes through a pull request." |
| Memory | A durable fact that is not about code | "We tried GraphQL in 2024 and dropped it, for these three reasons." |
| Source | A document you uploaded or linked, kept with the rules read out of it | "The on-call runbook, as a PDF." |
| How-to | The steps for a job your team repeats, one page per job | "How to stand up a new service from the template." |
They live in one list, which you can search and filter by kind, by status (active, draft, archived), by Space, by who added it and by source, and sort by least used, most used, recently used, recently added or A to Z. There is no separate page per kind. The Add knowledge menu is where you add one by hand: Upload or link a document, Write a rule, Pin an always-on rule, or Record a memory.
Always-on means pinned
A rule can be pinned, which means it is sent every session regardless of whether anything in that session looked relevant. Knowledge labels a pinned rule Always-on, but it is still a rule, and pinning is the one setting on this page that can quietly do nothing.
How-tos
A how-to is a page of numbered steps for one job your team repeats: a deploy, a release, a report in an outside tool. An agent that has just worked one out saves it with harbor_save_how_to, and teammates’ agents see its title at the start of a session, under “How-tos for this repo”, and open the whole page by title when they need it. The steps are never served as a rule.
Saving under the same title makes a new version of the same page. Each how-to has its own page on Knowledge with “What agents get”, every earlier version, and a way to revert to one. Most saves go live at once. One that adds a link, an install step, a risky shell command or something that looks like a secret, or that changes a page someone else wrote, waits for Approve or Decline, and agents keep the previous version until then.
Your preferences stay private
When you tell your agent how you like to work (“I prefer pnpm”), it keeps that as a preference, not as a team rule. A preference is never reviewed and never shared, and it comes back at the start of your own sessions. You see yours on Knowledge under Your preferences, which appears once you have one, and each has a delete button. The panel says it plainly: “Only you and your own agents see these.”
Suggested rules: what your agents could not find
When your agents keep searching for something the brain does not hold, Knowledge shows a suggested rules button with a count. It opens “Asked about, never answered”: the words they searched for, how often, and from how many sessions. Write opens a new rule with the search shown above it. A curator of the whole workspace can dismiss one that is not a gap at all, with an Undo.
What decides whether a capture waits for you
When an agent records something, or a connector distils something out of a merged pull request, one workspace setting decides whether it goes into the brain or into a queue. It is the same setting for both, which is the point: a fact your agent noticed and the same fact written in Slack should not be governed differently.
| Setting | What happens to a capture | Who it suits |
|---|---|---|
| Manual | Everything waits for review. | Teams with a compliance reason to have a human on every rule. |
| Hybrid | Your team’s rules, gotchas, patterns and memories go in on their own, on trial. Agent-instruction files, meeting notes and Sentry errors wait. | The default, and right for almost everyone. |
| Auto | Agent-instruction files, meeting notes and Sentry errors go in on their own too. | Teams who would rather archive a bad rule than clear a queue. |
Hybrid is the default, and it is worth knowing that before you go looking for an empty queue and conclude nothing is working. Under the setting, the settings page lists what still waits in the mode you picked, from the same list this page prints below. Only admins can see or change it.
When a capture reverses a live rule
A newer capture takes the place of the live rule it reverses only when two things are true: it would have gone live anyway, and the person whose agent recorded it could have retired that rule on their own, because they may curate every Space the rule reaches or because they wrote it. It is the same bar whether the agent named the rule in replaces or Harbor found the clash itself.
When it clears the bar, the new rule takes the old one’s place at the old one’s reach, anything the old rule said that the new one does not is kept as a rule of its own, and every session that used the old rule is told on its next prompt. The old rule’s author gets an email, “A newer rule replaced one you wrote”, with both rules quoted, and a notification in Harbor. Knowledge keeps a Restore on the old rule, which a curator of its Space can press.
When it does not, nothing is replaced and the pair waits in Review, “Waiting because it reverses a live rule that its recorder could not retire on their own.” Three more cases always wait: a capture from a browser sign-in connection, a rule Harbor read out of a correction, which waits beside the rule it seems to reverse, and any contradiction under Manual. In any setting a clash waits when Harbor cannot settle which one stands.
What waits in every setting, including Auto
- Anything an agent should not act on unchecked. A secret, a step that downloads or installs something, or a shell command that can do harm on its own, such as
sudo,rm -rfor a pipe into a shell. - Anything Harbor cannot place inside your company. An outside contributor on a public repo, a guest in a Slack Connect channel, an author Harbor could not match to anyone in your workspace, or anything nobody in your workspace can be named as the author of. “Auto” is a statement about trusting your own team’s captures and was never a statement about trusting strangers. A private repo is treated as trusted even when the author is just a handle, because an admin decided who can push to it. A public one is not.
- Anything with no Space. Harbor could not tell which Space it belongs to, so a person picks one.
- What your team asked to see first. Rules
harbor initorharbor bindimported from a repo’s committed rules files (CLAUDE.md, AGENTS.md,.cursorrules,.cursor/rules/*.mdcand.github/copilot-instructions.md), pull request review comments, because about one in three is a bug report rather than a rule, and a review of a coding agent’s pull request, read while it is still open. - A clash only a person can settle. A capture that reverses something live when Harbor could not settle which one stands, or that reverses or names a live rule its recorder could not retire on their own. Anything read from a connected source that reverses a live rule waits too, whoever wrote it: the old rule keeps being sent until a person decides.
- A failed check. When a check fails while Harbor is deciding, waiting is the safe answer.
Learn from corrections
On by default, under the capture mode. In the setting’s own words: “When a member corrects their agent, Harbor reads the correction with the agent’s last answer and writes the rule they meant. It goes live on trial at once; in Manual it waits in Review, in the member’s own words.”
What leaves the machine is the words you typed, with pasted blocks, code fences and attachments cut first, and the end of the agent’s last answer, at most 1,500 characters, both with secrets masked. A prompt with under 25 characters of your own words, a plain “ok”, or no answer to pair it with is not sent. A rule a reviewer dismissed before is not proposed again.
Every waiting row says why
Open a row in Review and its first line is “Waiting because” and the reason, in the words of the list above. When rows wait only because Harbor could not match their author to anyone in your workspace, a line above them names that person: “… isn’t linked to anyone in Harbor, so 2 of their items wait for review.” An admin can link them to a member right there, which re-checks their items. Anyone else is told “Ask an admin to link them.”
On trial, and what clears it
A capture that goes in without a person does not go in on the same terms as one you approved. It goes live on trial: it is served to agents like any other rule, and an agent reading it sees it marked “recorded by an agent, not yet reviewed”. Until something reinforces it, it ranks a little below rules a person vouched for, so when two rules fit a task equally well the reviewed one is sent first. Reinforcement is what clears the mark: the same thing being observed again, from somewhere else. Editing a rule on trial does not clear it.
The Review queue
Review is where held captures wait. Under the default setting that is the list above, plus agent-instruction files, meeting notes and Sentry errors, rather than everything. Each row says where it came from and why it waits, and a connector row links back to the message or pull request it was distilled from, so you can judge the extraction against the source instead of on its own wording.
Two filters narrow it. Kind groups rows as Rules, Skills, Memory, Conflicts and How-tos. Source lists each origin the queue holds right now, such as your agents’ sessions or a connector by name, which is how you approve six proposals from one PR review without reading past the Slack ones.
For each row you can approve it, edit it and then approve, change its Space first, or dismiss it. Editing before approving is worth the ten seconds: a distilled proposal is a machine’s reading of someone else’s prose, and it is usually right about the fact and clumsy about the sentence. A dismissal sticks: an agent that records the same learning again is told a reviewer dismissed it, and it is not proposed twice.
Seeing Review requires knowledge.publish, which owners, admins and curators hold. A member can propose but not approve, which is the whole distinction between the two roles. See roles and Spaces for who sees and approves what.
Putting documents in by hand
You do not have to wait for a connector. Choose Add knowledge, Upload or link a document, and Harbor keeps the document on Knowledge as a Source and reads candidate rules out of it. Those wait in Review for you to judge: the useful unit is a rule an agent can be served, not a twelve-page file it has to read.
Markdown, plain text, CSV, PDF, Word, Excel, PowerPoint and HTML, up to 10MB each. .mdc is accepted too, so a Cursor rules file can go straight in. You can also paste text, or add a link and take every page under that address. The Free plan limits uploads; see plans and limits.
How do outdated rules get removed?
Five ways, and only the last waits for somebody to notice: a newer rule replaces it, its end date passes, an admin turns on automatic archiving, a push deletes the file it is about, or a person archives it. A brain that only grows is a brain that stops being read, so all five exist on purpose.
- A newer rule replaces it, on the bar in when a capture reverses a live rule.
- Its end date passes. A fact recorded with an end date (“staging is read-only until Thursday”) is archived after that day.
- “Archive rules agents don’t use”. In Settings, Brain governance, under Unused rules: Never, which is the default (“Unused rules are suggested in Review instead of archived.”), or after 60, 90 or 180 days. A rule no agent has been sent in that long is archived. It runs every Sunday, the rules quiet longest go first, each run is capped, and anything you tick under “Never archive these kinds” is skipped.
- A push deletes the file it names. With GitHub connected, Harbor archives such a rule on its own when it was recorded in the repo that deleted the file. When it cannot tell, the rule stays live and Knowledge shows a band above the list: “2 rules may be out of date. A push deleted files they name, and they are still being sent to your agents.”
- A person archives it, from Knowledge or from Review.
Review keeps the list for that last one, under “Rules time has caught up with”. Its lane, Nobody uses this, reads “No agent has received these in 30 days. Longest silent first.” Each row offers Archive or Keep, and Keep stops suggesting it. A rule older than Harbor’s record of what reaches agents is not called unused: it sits under “Cannot be judged yet” with no buttons, because “These are here because we cannot say whether anybody used them, not because nobody did.” The lane names the day the record starts, so you can see the edge of what Harbor knows.
Archived is never deleted, whichever way a rule left: the body stays readable on Knowledge, with a Restore. What Harbor owes you is a defensible list and the evidence behind each row. A count of rules an agent said it used is an upper bound, because agents claim more uses than really changed their work, which is the subject of how to tell whether your agent follows team rules.
Next, who all of this is served to: scope agent memory by repo and team with Spaces.