Say what the software should do.

No. You describe the behavior. Your agent turns that into requirements, scenarios, tests, and links to the code. You step in when the product decision is actually ambiguous.

No. Keep the tracker you have. During bootstrap the agent asks which trackers, wikis, and specs hold your product intent, reads them through its own connectors, and cites the ticket or page behind each requirement. Kibi then connects that decision to the code that implements it, and to evidence that the code still does it.

TypeScript and JavaScript work out of the box. Add the optional kibi-plugin-treesitter package for Python, Go, Rust, Java, C#, PHP, C, C++, Bash, Ruby, and Terraform/HCL. It runs offline with pinned grammars. Setup is in the plugin reference.

Partly, and only if you opt in. The experimental kibi-plugin-ui package, which /kibi-bootstrap offers when it finds React or Angular components, makes kb_check require every component to implement a design requirement, and flags a component that loses the class names or test ids that mark its agreed pattern. That catches an agent rewriting a timeline as cards. It cannot see pixels, colours or spacing; those stay with your linter. Details are in the plugin reference.

Yes. kb_search accepts a plain question and, alongside ranked matches, returns the current requirements that govern the topic with their linked facts, scenarios, tests, and ADRs (with an excerpt of each decision). For each requirement it also reports any contradiction or infeasible-scenario finding that names it, the approved exceptions that exempt it, and what the checks could not decide, and it names the branch and KB snapshot the answer came from. On a new branch whose store was never compiled, the answer says so and points at kibi sync instead of returning a silent empty result. Superseded requirements are listed separately so they are not read as current policy, and a top match that no requirement owns is named as such rather than dressed in lower-ranked requirements. No finding is not proof: full consistency and proof status still come from kb_check, which also says which rules it evaluated and how many fact pairs it compared, and kb_coverage. The answer is ten rows by default, and on Claude Code it is sent once, as structured content with a short text summary rather than a second JSON copy in the text.

Yes. kb_query asks the modeled facts directly, without the agent writing Prolog: {predicate: "permission_rule", where: {actor: "admin"}} returns each rule with its allow or deny effect, {predicate: "has_role", where: {user: "alice"}, distinct: "role"} counts a user's roles, and {subjectKey: "user.role_assignment", propertyKey: "max_roles"} returns a limit with its operator and value. {factKind: "predicate_schema"} lists the predicates and argument names the project models, an unknown argument name comes back with the declared ones, an empty answer lists the values that do exist, and every answer names the next call to make. The facts that kb_search links to a requirement carry the same typed claim and the query that asks about it, and {id, includeBody: true} returns a requirement's authored body so a stale sentence in it can be corrected.

Yes. kb_upsert with dryRun: true runs the validation a real write runs, including the contradiction check for a requirement, and with plannedFacts it stages the facts kb_model planned, so an allow rule that would contradict a stored deny on the same actor, action and resource is refused before either is written, with the conflict named. kb_model also returns such a grounding as a hash-bound plan: its contradiction analysis is computed over the current knowledge base, a conflict leaves the plan blocked, and a clean plan writes the fact and its link in one kb_apply_plan call, all or nothing. kb_delete also takes dryRun: true, and deleting an authored entity first returns a hash-bound plan with the exact kb_apply_plan call that applies it.

With the Claude Code, Cursor, Codex, ZCode, or OpenCode plugin, the pre-edit hook (OpenCode: the edit prompt) names the requirement the file implements, what it must keep true (from its linked facts), and the decision behind it (its ADR), before the change is made. With the Claude Code plugin this also covers edits the agent makes through shell commands, which get the same context right after the command runs. A superseded or retired requirement is not shown as current. Afterwards kb_check, scoped to the changed files, names any changed function in a file no requirement owns, so the agent records what it now does without being asked; it quotes the statement and firmness of each requirement the changed code implements, and opens with "no structural violations" rather than "no violations", because it never compares code with a requirement's prose; for a file with no linked symbols, both the hook and the check name the requirements whose titles share the file's path words, so "nothing linked" is not read as "no rule applies"; and reports conflicts it can decide, such as an allow and a deny for the same actor, action and resource, and says when an analysis is incomplete instead of calling it clean. A scenario that assumes something a current requirement forbids, on its own or only in combination with its other assumptions, is flagged and blocks proof. Conditional requirements count: "checkout may happen only when the cart total is positive" becomes a typed rule, and a checkout scenario with a zero total is flagged unless a human approved an exception for it.

For reading, yes. On a commit no single branch points at, such as a CI checkout of a SHA or a bisect, search, query, status, check, coverage, and graph answer from a read-only snapshot compiled from that checkout, and every answer says so. Writes are refused until you check out a branch or set KIBI_BRANCH. Details are in the CLI reference.

Each entity can record its origin: written by a human, an agent, a migration or an import, and who approved it. New entities from your agent are marked as agent-written. kb_check lists agent-written requirements nobody has approved, exceptions whose approval only the agent recorded, and requirements that do not say why they exist. Kibi cannot confirm that a person approved something. It shows you what still needs your review.

Requirements and ADRs also record how firmly they were decided. A rule you stated is firm and points at your words; only another firm decision can replace it, so the agent is told to ask you first, and the agent cannot reword it in place unless it cites your new words. Kibi checks that the reference is there, not that you really wrote it. A choice you delegated, or one the agent made, is default: a later agent may replace it when it has evidence, and every replacement must say why it changed. A guess is exploratory. A rule with no firmness counts as firm unless the agent wrote it, and bootstrap marks the rules it imports from your documents as firm. When your request conflicts with any recorded rule, the agent names the rule and asks before changing it. Search results and the edit hooks show which is which.

A requirement is proven only when a test that claims to verify it has fresh end-to-end evidence for the current code. A passing unit test, a coverage percentage, or an old receipt does not count. The one exception is a requirement that only names a UI pattern, such as "this list is a line-and-dots timeline in both views": an isolated component test with a fresh receipt proves it, because rendering the component shows everything the requirement says. Freshness is computed from repository-relative paths and file contents, so CI and your own checkout of the same commit agree on what is proven.

No. kibi init creates the directory and the Git hooks; it leaves hooks it did not write alone, and kibi init --print-hook pre-commit prints a snippet you can add to them. It does not infer behavior. Checks prove what was encoded. Missing knowledge stays visible.