Looted/kibi

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** · **Quick start** · **Kibi's own health 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, keeping feature context isolated and available when you return. A detached checkout of a commit no single branch points at (a CI checkout of a SHA, a bisect) still answers reads from a read-only snapshot of that checkout and says so; writes wait until a branch is checked out. A branch created without Kibi's Git hooks starts uncompiled; kibi status, kibi check, and kibi doctor (and kb_status and kb_check over MCP) report that once and point at kibi sync instead of listing every relationship as missing.
- **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, and Terraform/HCL using pinned WASM grammars.
- **Optional UI design guard (experimental)** — kibi-plugin-ui, offered by /kibi-bootstrap when it finds React or Angular components, makes kb_check require each component to implement a design requirement and flags a component that loses the markers of its agreed pattern (a timeline rewritten as cards). Pixels, colours and spacing stay with your linter.
- **Keep knowledge local** — KB state lives in your repository's .kb/ directory; the Kibi packages send no external telemetry or analytics. Only 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:
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.