---
name: living-ip-kb-interop
description: Use when giving Hermes, OpenClaw, Claude-style, Pentagon, or other external agents safe read/write access patterns for the Living IP knowledge base.
---

# Living IP KB Interop

Use this skill when an outside agent needs to read from the Living IP knowledge base or propose a write back into it. The default is propose-first, proof-backed, and no-secret.

## Goal

Any Hermes, OpenClaw, Claude-style, or Pentagon agent should be able to:

1. search the knowledge base;
2. read a cited file or record;
3. propose a source, claim, entity, or correction;
4. route the proposal to the right evaluator agents;
5. leave a proof artifact that shows inputs, tools, and no denied actions.

## Read Path

Prefer deterministic local surfaces before asking an LLM:

- repository files under the knowledge base checkout;
- generated claim indexes from `lib/claim_index.py`;
- search helpers in `lib/search.py`;
- copied SQLite state through `teleo-db-operator`;
- retained proof JSON at a caller-specified generated-output path.

Read outputs must include file paths, source paths, claim/entity IDs when available, and the exact query used.

## Write Path

All writes are proposals until the normal review/evaluation pipeline accepts them.

Allowed proposal targets:

- source file proposal;
- claim file proposal;
- entity file proposal;
- correction proposal;
- route/evaluator proof artifact.

Required fields:

- source or rationale;
- target domain;
- proposed author/agent;
- route evidence;
- confidence or uncertainty tag;
- citations to existing KB context;
- proof output path.

Do not write directly to main. Do not mutate production `pipeline.db`. Use `teleo-db-operator` for any SQLite write, and only after explicit authorization, backup, transaction, and readback.

## Minimal Tool Contract

Adapters should expose this shape even if their runtime uses different names:

- `kb.search(query, domain?, limit?)`
- `kb.get(path_or_id)`
- `kb.propose_source(markdown, metadata)`
- `kb.propose_claim(markdown, metadata)`
- `kb.propose_entity(markdown, metadata)`
- `kb.route(diff_or_metadata)`
- `kb.proof(path, payload)`

If a runtime cannot implement one of these, record the missing tool as a blocker instead of silently skipping it.

## Denied Actions

- raw Bitwarden export;
- card, token, or password reads;
- production DB writes;
- direct pushes to main;
- public comments or messages;
- hidden Slack, Linear, Telegram, or GitHub sends;
- uncited knowledge writes;
- model-driven edits without route evidence.

## Expected Artifact

Write `<proof-output>/kb-interop-proof.json` containing:

- runtime name;
- model/provider if known;
- tools invoked;
- denied tools not invoked;
- query or input fixture;
- cited reads;
- proposed writes;
- route evidence;
- verifier result.