Kibi MCP

Prompt the intent. Kibi makes the agent remember it—and prove the implementation.

Simplified from what Kibi reports in each case.

Kibi is an agent-native requirements compiler and enforcement layer. You describe product intent in natural language; the agent creates and maintains the structured requirements, scenarios, tests, semantic facts, and code links. Kibi then checks that the implementation remains coherent with that intent.

Unlike passive memory or retrieval systems, Kibi is designed to place itself in the agent's workflow. The agent does not have to remember to consult a ticket, board, or requirements folder: Kibi's hooks, tools, and validation gates continuously bring the relevant product context back into the work.

[Documentation](https://looted.github.io/kibi/) · [Quick start](https://looted.github.io/kibi/guide/quick-start.html) · [Kibi's own health report](https://looted.github.io/kibi/kibi-report/)

Why Kibi

Most project knowledge is scattered across prompts, tickets, code, and conversations—and most AI agents eventually forget part of it. Kibi turns that knowledge into an enforceable, branch-local model:

• Humans maintain intent, not artifacts — The prompt is the primary authoring interface. Agents own the routine work of creating and evolving requirements, scenarios, tests, facts, and symbol links; humans resolve genuine ambiguity and product decisions.
• Memory is enforceable — Symbols need requirement ownership, requirements need complete semantics and scenarios, scenarios need tests, and proof-bearing tests need fresh execution evidence.
• Prolog guards against drift — Typed properties, predicates, and safe rules let deterministic checks expose contradictions, unsupported invention, and incomplete semantics before they become accepted project knowledge.
• E2E behavior is traceable — Kibi records what an end-to-end test proves, not merely which lines it happened to execute. You can navigate from a symbol to its requirement or from a test to the scenario and intent it verifies.
• Intent survives branch changes — Each Git branch has its own KB snapshot, so feature context stays isolated and is there when you return.
• Works across languages — TypeScript and JavaScript symbols are built in. The optional kibi-plugin-treesitter adds offline symbol extraction for Python, Go, Rust, Java, C#, PHP, C, C++, Bash, Ruby, SWI-Prolog, and Terraform/HCL using pinned WASM grammars. Each language installs as a small kibi-lang-* grammar pack (kibi-lang-python, kibi-lang-go, kibi-lang-prolog, ...), and kibi doctor names the ones a repository needs: generated files count only when the KB uses them, and any pack can be declined in kibi.declinedLanguagePacks. Generated code (linguist-generated, a generator header, or kibi.generatedPaths globs) also needs no requirement links in the commit gate unless the KB tracks it. Code and source proofs read TypeScript, JavaScript, Python and SWI-Prolog, so a Prolog project can prove its claims against its own predicates, imports, calls and pack.pl. With the plugin active for proofs, source proofs also read what Go, Java, C#, Rust, PHP, C and Bash files import, call and read from the environment, and the property values of PHP, C and Terraform/HCL files, without compiling or running them.
• Optional UI design guard (experimental) — kibi-plugin-ui keeps React and Angular components on their agreed design patterns. Pixels, colours and spacing stay with your linter.
• Questions in your own words (optional) — kibi-plugin-search-hints suggests which requirements a weakly answered kb_search question probably means, by meaning rather than shared words, with a small offline model.
• Keep knowledge local — KB state lives in your repository's .kb/ directory and is never sent anywhere. The Kibi packages send anonymous usage statistics, which you can turn off (see Usage telemetry); the documentation website counts visits with cookieless Umami analytics.

Quick start

Kibi is meant to be set up and driven by your coding agent, so the recommended install is a prompt rather than a list of commands. Kibi requires Node.js 22+. SWI-Prolog is bundled: on Linux (x64 or arm64, glibc 2.28+) and macOS (Apple silicon or Intel) there is nothing else to install. On other platforms, such as Alpine/musl or native Windows (use WSL), install SWI-Prolog 9.0+ and put swipl on your PATH (details).

Recommended: let your agent set it up. Paste this into Claude Code, Cursor, Codex, OpenCode, or any coding agent that can run commands in your repository:

Set up Kibi (https://github.com/Looted/kibi) in this repository, then bootstrap its knowledge base.

1. Install: confirm Node.js 22+ is available. With the package manager this repository already uses, add kibi-core, kibi-cli and kibi-mcp as dev dependencies. Do not skip optional dependencies; the bundled SWI-Prolog runtime is one.
2. Initialize: run every kibi command through the package manager's local runner (npm: npm exec -- kibi ). Run kibi init; if it reports a problem, run kibi doctor and fix what it names. If this platform has no bundled SWI-Prolog, tell me what to install and stop.
3. Connect: register the project-local kibi-mcp server for the agent host you are running in, following https://looted.github.io/kibi/guide/connect-an-agent.html. Prefer project-scoped configuration, and ask me before installing a plugin or changing global settings. Until the kb_* tools are visible to you, use Kibi's CLI JSON routes instead.
4. Bootstrap: run kibi skills load kibi-bootstrap --format markdown and follow that skill exactly. It starts by asking me where product intent lives outside the code (issue trackers, wikis, specs) and which sources to trust; read them through the connectors you have and cite them. Show me the complete plan and its hash, and write nothing until I approve it.
5. Verify: run kibi check and kibi status, fix anything they report, and summarize what was added. Do not commit; I will review the changes.

What happens next:

1. Setup. The agent installs the packages, runs kibi init, and connects itself to Kibi.
2. Interview. It asks where your product intent already lives (issue trackers such as Jira or YouTrack, wikis, specs) and which of those sources to trust.
3. Plan. It reads those sources through the connectors it has and drafts a bootstrap plan. Every requirement in the plan cites the ticket or page it came from. Open questions and conflicts it finds between sources are flagged for you rather than turned into requirements.
4. Your approval. It shows you the plan and its hash. Nothing is written until you approve.
5. Apply and check. It applies the plan, validates the result, then fills in what the plan could not write, such as scenarios from acceptance criteria and machine-checkable facts for the new requirements. It tells you what it added.

After that, work normally: prompt for features, fixes, and refactors, and the agent keeps requirements, scenarios, tests, and code links in step with the code.

Manual installation

In your repository:

npm install --save-dev kibi-core kibi-cli kibi-mcp

npm exec -- kibi init

kibi init creates the .kb/ layout and installs the Git hooks that keep it in sync. It never overwrites a hook it did not write; with lefthook, husky or the pre-commit framework it installs none and prints the configuration to add instead. It does not infer product knowledge. So that a fresh clone (a teammate's, a cloud agent's) uses Kibi too, it also writes a Kibi section into AGENTS.md (imported from CLAUDE.md) that tells any agent the knowledge base exists, and adds a prepare step that installs the hooks when dependencies are installed; the first Kibi query in a clone compiles the branch's store from the committed knowledge. Each of these can be turned off (setup choices). Connect your coding agent, then ask it:

Bootstrap Kibi for this repository.

pnpm, Yarn, and Bun work the same way through their local runners. The installation guide has their equivalents, how Kibi finds SWI-Prolog, and package-manager caveats. npm exec -- kibi doctor tells you whether everything is in place.

Upgrading. After updating the Kibi packages, run kibi migrate (or ask your agent to). It shows what would change and applies nothing until you approve; the CLI reference covers each schema version.

Versions. Each release has one Kibi release version, such as 2026.11.0, that names its exact package set and declares the KB schema it uses. kibi --version and kibi doctor show it, and doctor warns when installed packages come from different releases. When a newer kibi-cli is out, the CLI says so in one stderr line at a terminal (checked at most daily in the background, silent in CI, JSON output and agent runs, off with KIBI_UPDATE_CHECK=0), and kibi doctor reports it for every host. See Kibi release versions.

Connect your coding agent

The setup prompt above does this step for you. To do it by hand: every client starts the same project-local kibi-mcp server (npx --no-install kibi-mcp, stdio, working directory = your repository). Optional plugins add bundled skills and hooks on top.

Claude Code

Install the optional kibi-claude plugin from this repository's marketplace. It brings the MCP server, the bundled skills, and hooks that show the agent the linked requirements, what they must keep true, and the decision behind them before it reads or edits code, including through shell commands. The agent connection guide has the details:

claude plugin marketplace add Looted/kibi

claude plugin install kibi-claude@kibi

Without the plugin, register the server for the project:

claude mcp add --scope project kibi -- npx --no-install kibi-mcp

Cursor

Add Kibi to .cursor/mcp.json:

{

"mcpServers": { "kibi": { "command": "npx", "a