kaibo

Your team's engineering doctrine, one command away from every coding agent.

Every team has a way it builds things: how tests are tiered, what a base image is pinned to, what a pull request has to show before it merges. Most of it lives in a few people's heads, and the rest is pasted into each repo's AGENTS.md, where the copies drift apart. Agents never see the version that was actually agreed on, so they produce work that is plausible, locally consistent, and quietly not how you do things.

kaibo (Knowledge AI Backoffice) keeps that doctrine in one place, reviewed before it counts, and gives agents one command to load it when they start a kind of work and to research it before they decide something.

• For the lead: one definition of how the organisation builds, owned per domain, reviewed like code, with standards that can be marked binding.
• For the engineer: stop copying conventions from repo to repo. Write them down once; every agent session can read them, cite them, and propose additions.

	Without kaibo	With kaibo
Where the doctrine lives	Heads, Slack threads, a drifting copy in every AGENTS.md	One reviewed repository, owned per domain
What the agent knows	General training and whatever repo is open	The version your team agreed on, with citations
When nobody knows	The agent guesses, confidently	kaibo reports a gap, and the agent can propose the page
How it changes	Someone edits a copy; the others go stale	A pull request, reviewed by the domain's owners

The loop

flowchart LR
    team(["Leads and engineers"])
    repo[("Doctrine repo<br/>one folder per domain")]
    agent(["Coding agent"])
    work["Work done<br/>your team's way"]

    team -- "write and review<br/>by pull request" --> repo
    repo -- "kaibo sync<br/>local index" --> agent
    agent -- "kaibo doctrine / query<br/>cited guidance" --> work
    agent -. "gap (exit 3)<br/>kaibo contribute" .-> team

1. Load. Entering a kind of work (testing, deployment, observability), the agent runs kaibo doctrine <domain> and starts from the agreed standard.
2. Research. Before deciding something, it runs kaibo query and cites what it found. kaibo retrieves; the agent writes the answer.
3. Fill the gap. When there is no answer, kaibo says so with exit 3, and the agent drafts the missing page with kaibo contribute. It merges only after the domain's owners review it.

Status: early release, used internally. The verb surface is settling, and a breaking change is called out in the changelog.

What it looks like

An agent about to touch your test suite loads the relevant doctrine first:

$ kaibo query "should integration tests hit the network"
self-heal: not needed
result: 2 hit(s)
- engineering-practices/reference/lean-hermetic-test-pyramid.md - The Lean Hermetic Test Pyramid (relevance 0.84, status current)
<<<UNTRUSTED CORPUS CONTENT path="engineering-practices/reference/lean-hermetic-test-pyramid.md">>>
...

And when nobody has written the answer down, kaibo says so instead of guessing:

$ kaibo query "how do we version database migrations"
self-heal: not needed
result: gap, no hits
known domains: kaibo, ai-systems, observability, infrastructure, engineering-practices, ...
$ echo $?
3

Exit 3 means the organisation has no position yet. That gap is something to fill, and the same agent can open the pull request that fills it with kaibo contribute.

Install

brew install tenex-hq/tap/kaibo

Or, on macOS and Linux without Homebrew:

curl -LsSf https://github.com/tenex-hq/kaibo/releases/latest/download/kaibo-installer.sh | sh

kaibo searches with qmd, on your machine:

npm install -g @tobilu/[email protected]

Then point it at your knowledge repo and set up the agent side:

export KAIBO_REPO=your-org/knowledge   # or `repo = "..."` in ~/.kaibo/config.toml
kaibo install                          # places the Claude Code skills; they load in the next session
kaibo sync                             # clones the corpus and builds the index

No knowledge repo yet? Getting Started shows how to start one.

How it works

The doctrine is a git repository of plain markdown: one folder per domain, pages typed as reference, how-to or FAQ, changes merged by pull request under CODEOWNERS. It stays readable with nothing but a browser or grep.

kaibo is a single Rust binary that orchestrates git, gh and qmd so that an agent's side of the round trip is one command per turn with a typed result:

doctrine <domain>	Load a domain's standing guidance in one call, on entering that kind of work.
query <question>	Retrieve ranked, cited passages. The calling model does the synthesis.
domains	List what the corpus covers: each domain and its topics.
contribute plan / apply	Find where a piece of knowledge belongs, then lint it and open the PR.
sync, status	Keep the local clone and index fresh; say what is wrong and the command that fixes it.
lint	Check the corpus against its conventions. Drops into CI.
install	Place the agent skills this binary carries. Skills and binary never drift apart.

Every verb takes --json, --full and --explain. --explain prints the git and qmd commands underneath and runs nothing.

What it is not

• Not a chatbot. query retrieves; it holds no API key and calls no model. Your agent writes the answer, citing the pages kaibo returned.
• Not a wiki over everything. The corpus is prescriptive: what the team decided should be true, not everything anyone ever wrote down.
• Not an enforcer. kaibo keeps doctrine ready to read. Whether an agent reads it depends on the agent invoking the skill, which the evals measure rather than assume.

What it guarantees

Anyone who can merge a knowledge PR can put words in the corpus, so kaibo treats retrieved content as data: it reaches the agent fenced, and it can never change a command kaibo runs, a path it reads, or a flag it sets. No verb accepts a flag naming a repo or index, git hooks in the knowledge repo never run, and no code path discards uncommitted work. Usage telemetry stays on your machine unless you name an OpenTelemetry collector. The full list is in the overview.

Documentation

• Overview: the problem, the feature surface, and the guarantees.
• Getting Started: from install to a first query and a first contribution.
• Corpus conventions: the folder, frontmatter and wikilink rules kaibo lint checks.
• AXI: the design frame behind the verb surface.
• Decision records: why the guarantees are what they are, and what was deliberately not built.
• QMD contract: the exact qmd commands kaibo depends on.
• Evals: the suites that grade whether the skills fire and behave.
• Contributing: commit conventions and the release flow.

Licence

MIT.