kibi-cursor 2.8.2 → 2.9.1

package/agent-plugin/skills/kibi-decisions/resources/signoff-views.md

@@ -0,0 +1,66 @@
+# Signoff views
+
+`kibi signoff` renders what a person signs off, so the agent never retypes
+requirement text from memory. It is a CLI command, not an MCP tool.
+
+| View | Command | When |
+| --- | --- | --- |
+| Decisions to confirm | `kibi signoff --questions <file or ->` | Mid-work: rules to record as firm, a change to a recorded rule, a conflict |
+| Requirements signoff | `kibi signoff` (`--staged` for the index) | End of work: before asking to commit |
+
+Both print plain Markdown by default (`--format chat`): headings, quoted
+statements and lists that render in any chat or messaging surface. Put it in
+your reply unchanged: never wrap it in a code block, summarize it or retell a
+requirement in your own words. Every run also writes
+`.kb/briefs/signoff/latest.json`, `latest.md` and `latest.html` (git-ignored);
+`latest.html` is a self-contained page with the full view.
+
+## Showing it on your host
+
+| Host | Best view |
+| --- | --- |
+| Claude Code, Codex, Cursor, ZCode, VS Code chat | Paste the default output; `/kibi-signoff` (Claude Code, Cursor, ZCode) runs it. Offer `kibi signoff --format html --open` for the page |
+| OpenCode terminal | `kibi signoff --format md` and paste the fenced block unchanged: kibi-opencode draws it as a card, and `/kibi-signoff` reopens it |
+| Replies sent through a messaging tool (cloud or project threads, chat bots) | Pass the default output as the message text, and attach or publish `.kb/briefs/signoff/latest.html` next to it when the tool can carry a file or a page |
+| VS Code or Cursor with the kibi-vscode extension | The **Kibi: Show Requirements Signoff** panel follows every run |
+| Remote machine, no browser | Give the person the path of `latest.html` |
+
+`--format md` wraps the same Markdown in a ```` ```kibi-signoff ```` or
+```` ```kibi-questions ```` fence for host renderers; use it only where one
+draws it, because everywhere else a fence shows as raw code.
+`KIBI_SIGNOFF_FORMAT` sets the default for a host. `--format html --open`
+writes and opens the page; `--format json` prints the view.
+
+## Questions input
+
+`{"questions":[...]}` or a bare array. Each question:
+
+| Field | Required | Meaning |
+| --- | --- | --- |
+| `statement` | yes | The rule as it would be recorded |
+| `title` | no | A short name for the card |
+| `id` | no | The recorded requirement the question would change; the view quotes its current statement and firmness |
+| `quote` | no | The person's words that would go in `origin.ref` |
+| `firmness` | no | `firm`, `default` or `exploratory`, as it would be recorded |
+| `governs` | no | Files or symbols the rule governs |
+| `conflictsWith` | no | Recorded requirement ids it conflicts with; the view quotes them |
+| `question` | no | What you ask, when it is more than "record this?" |
+| `answer` | no | The person's answer; answered questions are struck out |
+
+The person answers by number ("1 yes, 2 exploratory, 3 reword: ..."). Copy
+each answer into `answer`, render again, and record the rules only once every
+question is answered. An answer is the person's words: quote it in
+`origin.ref`; a view itself is never an approval.
+
+## Summary contents
+
+| Section | Meaning |
+| --- | --- |
+| New | Requirement documents the change adds |
+| Changed | Rewritten requirements; a changed statement shows before and after |
+| Affected by the code change | Unchanged requirements whose implementing code changed (the `requirement_statement_unverified` set) |
+| Superseded or retired | Requirements the change retires, supersedes or deletes |
+
+Each requirement shows its firmness, origin, superseded rules, changed code
+symbols, scenarios and proof state (the earliest unmet proof gate). Parts
+Kibi could not compute are named in a `Note:` line instead of failing.

package/agent-plugin/skills/kibi-freshness/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-freshness
 name: kibi-freshness
 description: Check exact Git attachment, branch migration/quarantine, compiled-store freshness, source linkage, and repair state before decisions or writes.
-version: 2.0.0
+version: 2.1.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -53,6 +53,8 @@ echo '{}' | npx --no-install kibi status --input -
   `committed_with_repairs`, follow required typed `nextActions`; never retry the
   original operation.
 
+For every freshness, branch, or completion question, call `kb_status` first, then `kb_query` the entities and source files that status names, then `kb_check` as the last Kibi call before answering. Never skip the query step, even when status alone seems to answer the question. If another query or write follows a check, run `kb_check` again before answering. When asked whether requirements are consistent or proven, run `kb_query`, then `kb_check` with the rules `domain-contradictions`, `kb-consistency` and `kb-consistency-unresolved`, then `kb_coverage`, and read whether the analysis was complete. `domain-contradictions` compares facts two at a time; `kb-consistency` checks every fact of a property together, so a clean pairwise result is not proof. Report a `kb-consistency` violation as a conflict, name every requirement it lists, and give superseding or changing one of them as the next step; never edit or delete facts to make the check pass. Report a context `kb-consistency-unresolved` names as unresolved, never as consistent, with the step that would make it comparable. Report any unmodeled or unknown clause as incomplete analysis, not as consistent. Only when every clause is fully modeled and compatible, state plainly that no conflict was found. For authorized knowledge changes, keep the exact supplied target and intended relationship edges, and discover and query those targets first. Validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized `kb_upsert` with that same payload and read the result back exactly before the final checks. A passing dry run is validation, not completion. Distinct authorized payloads may need several sequential writes, each validated and read back, but never retry a mutation that already committed. If a mutation returns `committed_with_repairs`, follow its typed `nextActions` instead of repeating the original operation.
+
 ## Guidance
 
 - Treat MCP and the trusted project-local CLI as equal peer surfaces.

package/agent-plugin/skills/kibi-traceability/SKILL.md

@@ -29,6 +29,8 @@ interfaces. Select the surface by capability; neither is semantically preferred.
 For CLI JSON, use a dedicated route such as
 `printf '%s\n' '{}' | kibi status --input -`.
 
+For every traceability answer, begin with `kb_search` even when an identifier is already named, then exact-filter with `kb_query`, inspect relationships with `kb_graph`, and make `kb_status` the final Kibi call, including after `kb_graph` or `kb_coverage`; report no conclusions until that closing `kb_status` returns. When judging scenario feasibility, ground each step in the queried requirements, scenarios, tests, and symbols, and state missing links, ambiguity, or stale evidence explicitly rather than inferring them. For authorized coverage or link work, keep the exact supplied target and intended edges, discover and query those targets, then validate the payload with `kb_upsert` and `dryRun: true`. A passing dry run is only validation, not completion: next perform the real `kb_upsert` with the same payload, exact-read the result back with `kb_query`, run `kb_check` and `kb_coverage`, report the resulting proof state, and finish with `kb_status`. Distinct authorized payloads may each need their own sequential dry run and write, so there is no single-write limit, but never retry a mutation that already committed; on `committed_with_repairs`, execute the typed repair action instead.
+
 ## Workflow
 
 Use the visible approved MCP tools or trusted project-local CLI as equal peer
@@ -50,6 +52,8 @@ plan_returned` with a hash-bound plan whose `nextActions[0].input` is the exact
 through a new requirement linked with `supersedes`. Relationship deletes patch
 shards while preserving unrelated records.
 
+For executable coverage work, keep the production symbol's implements link to its requirement and link that same production symbol to its qualifying test with covered_by; reserve executable_for for a symbol that stands for the executable test itself, and never put executable_for on a symbol that also carries production ownership or coverage. Preserve the exact supplied target and intended edges, discover and query those targets, validate the payload with `kb_upsert` and `dryRun: true`, then perform the authorized real `kb_upsert` with the same payload and exact-read the result with `kb_query` before final checks, because validation alone is not completion. A passing dry run does not guarantee the commit: if the real `kb_upsert` returns an error, read its message and correct only the conflicting relationship on the same target rather than working around it with a new entity, then validate again with `dryRun: true`, write again, and exact-read it back. Distinct authorized payloads may each need their own sequential validation and write, so there is no single write limit, but never retry a mutation that already committed; on `committed_with_repairs`, execute the typed repair action instead. Then run `kb_check` and `kb_coverage`, report the proof and verification state they return, treating a dirty verification snapshot after a write as expected rather than as a failure, and finish with `kb_status`.
+
 ## Typed recovery and proof
 
 Parse `kibiProtocol`, `resultVersion`, `status`, `effects`, diagnostics, and

package/agent-plugin/skills/kibi-usage/SKILL.md

@@ -2,7 +2,7 @@
 id: kibi-usage
 name: Kibi Usage
 description: Use Kibi's source-first, exact-Git, migration-aware, proof-aware operations safely across MCP or the trusted local CLI, including partial completion repair.
-version: 2.20.0
+version: 2.24.0
 kibiCompatibility: ">=1.0.0"
 tags:
   - kibi
@@ -121,6 +121,10 @@ component that renders it) with `implements` through `kb_upsert`. Without a read
 still answers and `kibi sync` regenerates the manifest. The search tip and the
 `.kb/` note appear once per session and need no action.
 
+Before you edit a source file that Kibi tracks, run `kb_search` with that file in `sourceLocations`, and treat both its ranked results and its `data.answer` layer as discovery only, not as the governing text. Then call `kb_query` by `id` on each current governing requirement that the search names, read what each one requires, and make the edit only after those exact reads. A `kb_check`, `kb_status` or `kb_coverage` result does not replace that `kb_query` read. This rule only adds an exact read before the edit and does not change the order of any other step in this workflow. It adds nothing to a modeling or write task: that task still ends with the real `kb_upsert` of every planned fact and requirement and the closing `kb_check`.
+
+For an edit that keeps the governing rule, limit the consultation before the edit to exactly two Kibi calls: `kb_search` with the file in `sourceLocations`, then one `kb_query` (by the governing requirement's `id`, or by `sourceFile` when several requirements govern the file). Do not start with `kb_status`, and do not repeat the search or the query before editing; run `kb_status`, `kb_check` and `kb_coverage` after the edit. This limit applies only to source edits. A task that models a claim keeps its full order, one step after the other: `kb_search`, then the exact `kb_query` of the supplied target, then `kb_model` with `mode: "analyze"` on the complete claim, then `mode: "predicates"` for each relational clause, then `kb_model` with `mode: "requirement"` for a strict or typed-rule clause, and only then the real `kb_upsert` of every planned fact and requirement and the closing `kb_check`. Never call `kb_model` before that exact `kb_query`, and never stop at a dry run.
+
 ## Safe workflow
 
 1. Always discover before you mutate: start with `kb_search`, then exact-filter with `kb_query`. Use
@@ -164,7 +168,7 @@ End every task with these five independent fields:
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 
@@ -356,7 +360,9 @@ authored. Each one is the order the write path accepts.
 
 Entities record `origin` (`kind`: `human`, `agent`, `migration`, or `import`,
 plus optional `ref` and `approved_by`). `kb_upsert` records `kind: agent` on
-entities you create; leave `origin.approved_by` to the person who reviews them.
+entities you create; leave `origin.approved_by` to the person who reviews them,
+and ask for that review with `kibi signoff` (see `kibi-decisions`), never with
+a summary in your own words.
 An exception (a requirement that `exempts` another) exempts nothing until a
 human sets `approved_by`; `kb_check` flags approvals an agent recorded without
 corroboration. Never fill in an approval yourself. Record why a requirement
@@ -365,6 +371,8 @@ exists in `rationale`, or link the ADR that explains it.
 ## Decision firmness
 
 Requirements and ADRs carry `firmness`, which says what you may do with them.
+Load `kibi-decisions` when a person states a rule, a hook asks before an edit
+of firm code, or a request conflicts with a recorded rule.
 Search answers, `kb_query` rows and hook snippets show it (snippets label only
 `[firm: ask before changing]` and `[exploratory]`; an unlabeled decision is
 `default`).
@@ -394,17 +402,12 @@ task or in reply: then supersede it with `firmness: firm` and `origin.ref` to
 their words (or, for a correction they asked for in place, update it with
 `origin.ref` to those words), and say in the final answer which rule changed.
 
-Set `firmness` from what a human actually said: only their stated rule is
-`firm` (with `origin.ref`); "do whatever" or your own pick is `default`; a
-guess is `exploratory`. Write it explicitly whenever you record a decision,
-including when importing rules from documents, tests or tickets (a rule a
-person wrote there is `firm`, with `origin.ref` to that document). A
-supersede needs `## Why this changed` in the new entity's body (at least 12
-words): name the evidence (a failing test, a measured cost, a constraint the
-old decision missed, a new requirement, the person's instruction) and answer
-the old decision's reasoning; `kb_check` blocks it otherwise. A preference is
-not evidence: propose it instead of superseding. Kibi checks only that a firm
-decision has a reference; never cite words nobody said.
+Set `firmness` explicitly from what a human actually said: only their stated
+rule is `firm` (with `origin.ref` to their words); your own pick is `default`;
+a guess is `exploratory`. A supersede needs a `## Why this changed` section of
+at least 12 words naming the evidence; a preference is not evidence. Never
+cite words nobody said. `kibi-decisions` has the recording and supersede
+payloads.
 
 Conditional clauses ("only when", "only if", "must not ... unless") compile
 into typed `forbid` rules linked by `requires_rule`, not property facts; one
@@ -418,7 +421,8 @@ read `unresolved` as consistent. Compare the intent with each candidate's
 `statement`, then compile again with `conflictReviews`
 (`{requirementId, verdict: "conflict" | "no_conflict", note}`). On a conflict
 the plan is `blocked`: ask the human which rule holds (a firm requirement is
-theirs), then supersede or change it, or change the intent.
+theirs), then supersede or change it, or change the intent (see
+`kibi-decisions`).
 
 ## Semantic and proof guardrails
 
@@ -558,4 +562,5 @@ retrying the same payload; inspect the typed error and `nextActions`.
 Kibi may now author tracked Markdown/YAML evidence transactionally. The former
 statement “Kibi operation writes do not automatically stage markdown evidence”
 means Kibi writes do not Git-stage it: review and commit remain ordinary Git
-workflows.
+workflows. When `kibi check --staged` or the pre-commit hook blocks a commit,
+load `kibi-commit-review`.

package/agent-plugin/skills/kibi-usage/resources/proof.md

@@ -1,6 +1,6 @@
 # Proof and Verification Workflow
 
-Use this resource when a requirement must be proven before handoff, when
+Use this resource when a requirement must be tested end to end before handoff, when
 wiring a proof-bearing test, or when `kb_ingest_proof` or `kibi prove`
 rejected evidence.
 
@@ -97,9 +97,9 @@ Cosmetic edits (descriptions, labels) never stale proof. Execution-relevant
 edits (command, artifact, targets, options, bindings, contract) change the
 effective fingerprint and do.
 
-## What counts toward proofProven
+## What counts toward proofTested
 
-A requirement is proven only by its scenarios' tests, and a scenario test
+A requirement reaches `proofStatus: tested` only through its scenarios' tests, and a scenario test
 counts only when it is an **end-to-end** test with a valid, fresh, passing
 receipt for the current snapshot.
 
@@ -109,7 +109,7 @@ receipt for the current snapshot.
   `source` path contains `e2e`) counts as end-to-end; anything else is
   `unknown` scope.
 - A `unit` or `integration` receipt is still recorded on the test entity, but
-  it does not move `proofProven` for a behavioural requirement: the
+  it does not move `proofTested` for a behavioural requirement: the
   requirement keeps the `missing_passing_e2e` gap in `proofGaps`. The one
   exception is a scenario whose specifying requirements are all grounded only
   in component-scope UI predicates (`ui_pattern`, `same_pattern`,
@@ -120,6 +120,38 @@ receipt for the current snapshot.
   receipt does not change it, and a `passing` status without a fresh receipt
   proves nothing.
 
+## Evidence levels
+
+Every requirement row also carries `evidenceLevel`, the strength of what backs
+it, and `evidence`, the entries that earned it (each with `kind`, `scope` and
+`level`):
+
+- `proved`: a re-checkable certificate covers every case. No proof kind issues
+  certificates yet, so nothing reaches it today.
+- `tested`: `proofStatus` is `tested`; fresh E2E receipts cover every linked
+  scenario.
+- `asserted`: a person stands behind the statement (approved, or firm by
+  `firmness` or a non-agent origin) but nothing current checks it.
+- `unverified`: an agent wrote it, no person approved it, nothing checks it.
+
+Report the level as it is. Never call an `asserted` or `unverified`
+requirement proven or tested, and never call `tested` proved. Firmness is a
+separate axis: it says how sure the person is, not how strong the evidence is.
+
+## Knowledge-base certificates
+
+`kb_check` (`kibi check`) proves facts about the KB itself in its
+`kb-consistency` rule and re-checks each answer with an independent checker:
+property facts are consistent (a model per subject, property and scope, or an
+irreducible contradiction core), predicate facts and allow/deny decisions are
+consistent, and stored rules are stratified. It catches facts that contradict
+only together, which the pairwise `domain-contradictions` rule misses. A
+`kb-consistency` violation names the core facts and the requirements behind
+them: supersede or change one of those requirements; never edit the facts so
+the check passes. Quote a `kb-consistency-unresolved` diagnostic as
+unresolved, never as consistent. Opposing rule pairs and scenario
+feasibility are not certified yet; their own rules still decide them.
+
 ## Attempt semantics (factual, never optimistic)
 
 - `attempts: {status: "complete", entries: [...]}` — known history; the

package/agent-plugin/skills/kibi-usage/resources/workflows.md

@@ -9,7 +9,7 @@ success flag):
 taskOutcome: complete | interim | blocked
 kbState: clean_fresh | stale | dirty | legacy_compat | not_evaluated
 verificationState: fresh | dirty | unavailable | not_evaluated
-proofState: proven | mixed | unresolved | not_evaluated
+proofState: tested | mixed | unresolved | not_evaluated
 limitationDisposition: none | accepted | unaccepted | not_applicable
 ```
 

package/commands/kibi-signoff.md

@@ -0,0 +1,26 @@
+---
+name: kibi-signoff
+description: Show the Kibi requirements signoff view for the current change, or the decisions waiting for the person
+---
+
+# Kibi signoff
+
+Show the person what they sign off, quoted from the knowledge base rather than
+retold from memory.
+
+1. If decisions are waiting for the person (rules to record as firm, a change
+   to a recorded rule, a conflict), build the questions view as the
+   `kibi-decisions` skill describes (`resources/signoff-views.md`) and run
+   `npx --no-install kibi signoff --questions -` with the questions on stdin.
+2. Otherwise run `npx --no-install kibi signoff` (add `--staged` for the
+   staged changes only).
+3. Put the command's output in your reply unchanged. It is plain Markdown that
+   renders as headings, quotes and lists; do not wrap it in a code block or
+   summarize it.
+4. Offer the full page too: `npx --no-install kibi signoff --format html --open`
+   opens it in the browser on this machine, and
+   `.kb/briefs/signoff/latest.html` is the same self-contained page to attach
+   when the person is not on this machine.
+
+A view is never an approval: record a rule as approved only from the person's
+answer, quoted in `origin.ref`.

package/dist/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "kibi-cursor",
   "displayName": "Kibi",
-  "version": "2.8.2",
+  "version": "2.9.1",
   "description": "Optional Cursor adapter for Kibi. Requires project-local kibi-cli, kibi-mcp, and kibi-core (SWI-Prolog is bundled on Linux and macOS) before the bundled MCP server can start.",
   "license": "AGPL-3.0-or-later",
   "author": {

package/dist/commands/kibi-signoff.md

@@ -0,0 +1,26 @@
+---
+name: kibi-signoff
+description: Show the Kibi requirements signoff view for the current change, or the decisions waiting for the person
+---
+
+# Kibi signoff
+
+Show the person what they sign off, quoted from the knowledge base rather than
+retold from memory.
+
+1. If decisions are waiting for the person (rules to record as firm, a change
+   to a recorded rule, a conflict), build the questions view as the
+   `kibi-decisions` skill describes (`resources/signoff-views.md`) and run
+   `npx --no-install kibi signoff --questions -` with the questions on stdin.
+2. Otherwise run `npx --no-install kibi signoff` (add `--staged` for the
+   staged changes only).
+3. Put the command's output in your reply unchanged. It is plain Markdown that
+   renders as headings, quotes and lists; do not wrap it in a code block or
+   summarize it.
+4. Offer the full page too: `npx --no-install kibi signoff --format html --open`
+   opens it in the browser on this machine, and
+   `.kb/briefs/signoff/latest.html` is the same self-contained page to attach
+   when the person is not on this machine.
+
+A view is never an approval: record a rule as approved only from the person's
+answer, quoted in `origin.ref`.

package/dist/hook-runner.js

@@ -3,7 +3,7 @@
 import fs from "node:fs";
 import path from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
-import { captureReminder, claimCaptureReminder, confirmFirmEdits, firmEditNotice, firmRequirementsTouched, hasDecisionFlag, holdRuleNote, markDecisionFlag, recordRequest, settleFirmRequirements, settledFirmRequirements, takeRuleNote, } from "kibi-agent-core/decision-guard";
+import { captureReminder, claimCaptureReminder, claimSignoffReminder, confirmFirmEdits, firmEditNotice, firmRequirementsTouched, hasDecisionFlag, holdRuleNote, isRequirementUpsert, markDecisionFlag, recordRequest, settleFirmRequirements, settledFirmRequirements, signoffReminder, takeRuleNote, } from "kibi-agent-core/decision-guard";
 import { appendHookUsageRows, editTraces, hookTelemetryEnabled, kbUsageTrace, readPackageVersion, } from "kibi-agent-core/hook-usage-log";
 import { stampKibiWorkspace } from "kibi-agent-core/kb-mcp-tools";
 import { createEntitySummarizer, editFocus, fileKnowledgeSnippet, implementedRequirementIds, } from "kibi-agent-core/snippets";
@@ -299,6 +299,10 @@ export async function runHook(rawInput, environment = {}) {
                 kbUsageTrace(input.toolName, input.toolInput)?.kbOperation ===
                     "kb_upsert") {
                 markDecisionFlag(session, "kb-recorded");
+                // implements REQ-kibi-signoff-views
+                if (isRequirementUpsert(input.toolInput)) {
+                    markDecisionFlag(session, "requirement-recorded");
+                }
             }
             const primaryPath = resolvePrimaryPath(input);
             if (!primaryPath || !kibiReady) {
@@ -360,12 +364,15 @@ export async function runHook(rawInput, environment = {}) {
             // implements REQ-agent-hosts-decision-guard
             // Source changed and nothing was recorded: the follow-up asks for the
             // decision to be recorded, once per conversation.
-            const followupMessage = [
-                claimCaptureReminder(session)
-                    ? captureReminder(hasDecisionFlag(session, "rule-prompt"))
-                    : undefined,
-                stopFollowupMessage(state),
-            ]
+            const capture = claimCaptureReminder(session)
+                ? captureReminder(hasDecisionFlag(session, "rule-prompt"))
+                : undefined;
+            // implements REQ-kibi-signoff-views
+            // Requirements were written without a signoff view since: ask once.
+            const signoff = capture === undefined && claimSignoffReminder(session, cwd)
+                ? signoffReminder()
+                : undefined;
+            const followupMessage = [capture, signoff, stopFollowupMessage(state)]
                 .filter((part) => part !== undefined)
                 .join("\n");
             if (followupMessage) {

package/dist/skills/.canon-hash.json

@@ -4,24 +4,29 @@
   "kibi-bootstrap/resources/branch-lifecycle.md": "c854264ce888439140883a3fc636db5e522f020dd27b30a5c1ecc4105b64ed13",
   "kibi-bootstrap/resources/operation-access.md": "b5a6a59e72d800c376e7fad79132897623c32a0ce152a1e8d73f9628b444db51",
   "kibi-bootstrap/resources/source-authoring.md": "bf296e62f69474e01797d6cb9469bf624551dca834dd188abb6e705bd96fa586",
-  "kibi-freshness/SKILL.md": "fa90d34663ddd6f03468008fb26e4417211f7b7d46ffde082291747743464c54",
+  "kibi-commit-review/SKILL.md": "d593f4f879be9aec0ddcd4003612a97fe6fa64298602ff6922f780e2a3ba4152",
+  "kibi-commit-review/resources/staged-gate.md": "993e5a08ab2be5ccd95695ec5f7600cd32ef6d75d1a9b962202183aa05fec51f",
+  "kibi-decisions/SKILL.md": "384749d6a9196c978a6df5a0d89fffe1fab7bad9554bc77e6bc45282567c4184",
+  "kibi-decisions/resources/decision-records.md": "1244ab963f78cfd47fc88dc9700bbfdbe2fad8a0d84da1fb7c40d718ccca710a",
+  "kibi-decisions/resources/signoff-views.md": "f5de0c378de9094949b372485d6e1f06398eb1c60cd234077a89af312f3c9d07",
+  "kibi-freshness/SKILL.md": "7474b7c22ca915006e930850274bc71efaf2e03dcf60d41a2936b70d64547052",
   "kibi-freshness/resources/branch-lifecycle.md": "ebc01b19fe3dca8df5fc0175978963f6f1204f71f7c805cb2a5fb1b277ac78e4",
   "kibi-freshness/resources/operation-access.md": "4e1db9294ee540cd29b8b3a2532a81e7894d5b4228b39e99ba48b37212f489f3",
   "kibi-freshness/resources/source-authoring.md": "41a0547ce4d2a112a0f3671d36720f07c447864db3b473e94eb88a8ce2d371ff",
-  "kibi-traceability/SKILL.md": "df564438228efaf73740037ef4b1969b0638a6530a9385c9e7bf21108e8a952d",
+  "kibi-traceability/SKILL.md": "f4ebc9a57dae6fcbc8fa467209b31a6c2fc9358ece4aa96189f6fa5e2c20ee21",
   "kibi-traceability/resources/branch-lifecycle.md": "50f1a6355aa9185d412b2474db1a64e112944625d2465be0adbf93ada3273c1f",
   "kibi-traceability/resources/operation-access.md": "39f7972ab7f4ae7479e78f7072bb50e8e6c4cdf4f857425f69d2522d37db437c",
   "kibi-traceability/resources/source-authoring.md": "408c6ee2bef1b84e0194c0538ef929c26a0a617e631b2234247388140dbbdd08",
   "kibi-traceability/resources/traceability.md": "38c290a0bc71bd1692e115f22694743946e2f69630e134acfd43cee5f613fb88",
-  "kibi-usage/SKILL.md": "82cfdea4088ab218722a11e325ce6dc558e53d11644a25155b82871bea60d8f7",
+  "kibi-usage/SKILL.md": "e8efe1c31c601042cdcd3c96cb9cd81b009458410053a6cf5a44852dd0a1bcbf",
   "kibi-usage/resources/branch-lifecycle.md": "f1bf359e9826e83c548f3cd0287f8175a62456527b0132b06b3f9f74aa59b7d6",
   "kibi-usage/resources/fact-lanes.md": "899218f90396aa469b6e34aeb5f7ea1f38bf11bb326102319f376c213859fb33",
   "kibi-usage/resources/kb-improvement.md": "a8408fce27342bdce6415a6718599e53fe00bb33aa1fd3dc42353ec6f61adcd7",
   "kibi-usage/resources/logic-ir.md": "0e8ce8aad07433ab4803ec169149ff6c4e1cf8cf010af18fa6fd67862d9be807",
   "kibi-usage/resources/operation-access.md": "eb455796c066787ffd3fae8db0db1d3e87a84265a57f06ae61e30103cd6aed66",
-  "kibi-usage/resources/proof.md": "2348819078034dd3df25664c4c707ff98f17520bbbd335bff4f48611cf672bb3",
+  "kibi-usage/resources/proof.md": "d44ced11dca304495cab186eea84bf33fbd9932653821559a7f20b4f1c8d5606",
   "kibi-usage/resources/relationship-directions.md": "0fdd67032c2d15299f772845fc4f807eb9435b09507bd87a5911ab33db2f143d",
   "kibi-usage/resources/source-authoring.md": "cad93f1e0ae08a676f2de7492f9227677880302327e74d159618fea86ca50abe",
   "kibi-usage/resources/ui-requirements.md": "f99c2a9a73bbb7bd92ce1f231db3056d544588be149a5b0d3f7cc6f28bc9eee9",
-  "kibi-usage/resources/workflows.md": "9cfdcf8c21ad92ed5c72e0f350e9b1ab678ff263670e2c34d7d9277933ead1bf"
+  "kibi-usage/resources/workflows.md": "53c6889f375988a89a4cce8e68e79c7f621b15cc81cff915d61733642db87153"
 }

package/dist/skills/kibi-commit-review/SKILL.md

@@ -0,0 +1,125 @@
+---
+id: kibi-commit-review
+name: kibi-commit-review
+description: "Use when kibi check --staged or the Kibi pre-commit hook blocks a commit (kibi_impact_evidence_missing, symbols_manifest_stale, symbol_granularity_violation, symbol-coverage, kibi check-generated drift, Staged impact review failed), or when preparing a commit or pull-request impact review. Covers reading the per-file Detail lines, authoring .kb/symbols.yaml symbol entries through kb_upsert, kibi sync --refresh-symbol-coordinates, staging the tracked Kibi evidence with git add, kb_prepare_impact_review for a staged or diff scope, the kibi signoff requirements summary to show before a commit, and how merge commits and migration renames are judged."
+version: 1.2.0
+kibiCompatibility: ">=1.0.0"
+tags:
+  - kibi
+  - commit
+  - staged-check
+  - traceability
+  - agent-guidance
+resources:
+  - resources/staged-gate.md
+---
+## Goal
+
+Get a commit through Kibi's staged gate by fixing the cause: the commit
+carries the knowledge its behavior change needs, with current symbol
+coordinates, so the gate passes for the same reason a reviewer would accept it.
+
+## Interface Selection
+
+Use the visible approved MCP tools or the trusted project-local CLI as equal
+peer interfaces (CLI JSON: `printf '%s\n' '{}' | npx --no-install kibi status
+--input -`). The gate itself is CLI: `npx --no-install kibi check --staged`
+(add `--format json` for the full evidence). If neither surface is available,
+stop and name the missing capability. Never read or edit `.kb/` files directly.
+
+## When this applies
+
+- `kibi check --staged` fails, or the pre-commit hook (`kibi check-generated
+  --staged --changed-only`, then `kibi check --staged`) blocks a commit.
+- You are about to commit or open a pull request and want the impact review
+  ready first.
+
+Never read or open any file under `.kb`, not even read-only with a file tool to look at symbols or coordinates; doing so fails the session even when nothing is written. What you need is already shown elsewhere: the gate's `Detail:` lines, `kb_query` by `sourceFile` or `id`, and `kb_check` with `staged: true` show which symbols and coordinates are covered and which are missing. Before deciding what the change is, always run `kb_search` with `sourceLocations` for each named file and `kb_query` the requirement that governs it, even when the edit looks coordinate-only or seems to contradict a firm rule. When a write is authorized, keep the supplied target and its intended edges, query those targets first, validate the exact payload with `kb_upsert` and `dryRun: true`, then send that same payload with `kb_upsert` and exact-read the result back with `kb_query` before the final checks. Distinct authorized payloads may need several sequential writes, but never resend a write that is already committed, and let typed `nextActions` drive recovery. A passing dry run is validation only, not completion.
+
+## Steps
+
+1. **Read the whole failure.** Each finding names an id, the files, `Detail:`
+   lines and a `Suggestion:`. Detail lines are complete per file: how many
+   symbols extraction finds in the staged content, how many the staged
+   evidence covers, and every symbol missing from `.kb/symbols.yaml` with its
+   line. The common ids and their fixes are in `resources/staged-gate.md`.
+2. **Find the owning knowledge.** `kb_search` with `sourceLocations` for each
+   named file (or `kb_query({sourceFile})`), then `kb_query` the requirements,
+   scenarios and tests it returns. Run `kb_check` with `sourceFiles`,
+   `includeImpactDiagnostics: true` and `staged: true` to see the impact
+   findings, including `requirement_statement_unverified` quotes.
+3. **Decide what the change is.**
+   - Behavior changed: update or record the knowledge (a requirement with a
+     scenario, or a new clause) through `kb_upsert`. If the change contradicts
+     a recorded rule, stop and ask; load `kibi-decisions`.
+   - New or uncovered symbols: author a `symbol` entity per listed symbol
+     through `kb_upsert` (`title` = the member the extractor names,
+     `sourceFile`, `status: active`, `symbol_role: behavioral`, `implements`
+     to the requirement, `covered_by` to the test). Then run
+     `kibi sync --refresh-symbol-coordinates`.
+   - Only coordinates moved: `kibi sync --refresh-symbol-coordinates`.
+   - No behavior change (a genuine false positive): see the audited
+     no-impact note in `resources/staged-gate.md`; it never covers a real
+     behavior change.
+4. **Stage the evidence.** Kibi authors tracked files but never Git-stages or
+   commits them. `git status --short .kb` lists what it wrote; `git add` the
+   entity Markdown, `.kb/relationships/` shards, `.kb/symbols.yaml` and
+   `.kb/symbol-coordinates.yaml` that belong to this change (use `git add -p`
+   when the files hold unrelated edits).
+5. **Re-run** `kibi check --staged` (and `kibi check-generated --staged` when it
+   failed) until it passes. Never bypass the hook (`--no-verify`) unless the
+   person says so.
+
+## Requirements signoff
+
+Before you ask the person to approve a commit that adds, rewrites or retires
+requirements, or changes code that implements them, show them what they are
+signing off:
+
+```
+npx --no-install kibi signoff            # working tree; --staged for the index
+```
+
+It prints Markdown listing each new, changed, affected and retired
+requirement with its statement (before and after for a rewrite), firmness,
+origin, scenarios and proof state. Put it in your reply unchanged (in the
+messaging tool's message when replies go through one), then add one or two
+sentences on why the requirements changed. Offer the full page with
+`kibi signoff --format html --open`, or attach or publish
+`.kb/briefs/signoff/latest.html` when your host can carry a file or a page;
+past 15 requirements the Markdown stops and only the page lists them all.
+Host details: `kibi-decisions`, `resources/signoff-views.md`. `--no-proof` skips the proof lookup, which reads coverage and is slow
+on a large knowledge base. The summary is not an approval: never set
+`approved_by` or `origin.ref` from it.
+
+## Impact reviews
+
+When the repository's base commit carries `.kibi/impact-policy.json`, the gate
+also demands a content-bound review record at `.kibi/impact-review.json`
+(`Staged impact review failed: impact_review_invalid ...`). Prepare it with
+`kb_prepare_impact_review` (`scope: {"kind":"staged"}`, or `{"kind":"diff",
+"baseCommit":"<40-hex sha>","headCommit":"<40-hex sha>"}` for a pull
+request). It is read-only: it returns per-file evidence, requirement scopes,
+residual review obligations and an unauthored record template. Draft each
+file's `decision` from what you verified, leave `reviewer.id` for the person
+who reviews, and never present the record as their approval. Field details are
+in `resources/staged-gate.md`.
+
+## Merge commits and migrations
+
+During a merge (`MERGE_HEAD` exists), files staged unchanged from a merged
+parent are skipped (`Merge commit: N staged file(s) are taken unchanged ...`);
+only what the merge resolved or edited is judged. A commit that moves
+knowledge into `.kb/` after `kibi migrate` is compared with the old paths
+(`Baseline: HEAD with N staged knowledge rename(s) ...`), and symbol records
+changed only by the migration are not judged as changed. Debt reported there
+came from the branch or the old layout; the full `kibi check` still shows it.
+
+## Typed results and report
+
+Parse `kibiProtocol`, `status`, diagnostics and typed `nextActions` on every
+Kibi write. On `committed_with_repairs`, run the repair actions and never
+resend the original write. Report the findings you fixed (id, file, what
+changed), the knowledge you recorded or confirmed still current, the files
+you staged, the final `kibi check --staged` result, and anything left for the
+person (an open rule conflict, an unauthored review decision).