knowl_store
Save one concise structured knowledge atom per finding, retire outdated items with supersedes, and keep project memory current without raw transcripts.
Instructions
Store one concise structured knowledge atom directly, not raw chat transcripts. Use immediately after discovering durable project knowledge or completing each subtask, not only at the end. This is deterministic and does not require Knowl AI configuration. When this atom corrects or replaces knowledge a query already returned, pass that item id as supersedes in this same call so the outdated item is retired in one write; never leave two active items asserting different values for the same thing. The result reports any item left active beside this one and the exact call to retire it.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Do this as another repo in this workspace, named as the manifest names it. Use when you are finishing THAT repo's work from here: the call applies to its store exactly as if you had run it there, including retiring its knowledge, and what you write is stamped as its own. Omit it -- the normal case -- and everything applies here. Not for a drive-by correction of something you noticed in passing while working on this repo. | |
| tags | No | Optional tags. | |
| local | No | Never publish this atom to a cloud workspace. Pass true for knowledge that is only true of THIS machine -- an absolute path, an environment quirk, a fix that depends on local tooling. In a connected repo new knowledge is staged for the team automatically, so an atom that should not travel has to say so at write time; there is no other moment when you know. Reversed by naming its id to `knowl cloud stage`. | |
| steps | No | Ordered steps when category is skill. | |
| title | Yes | Concise title for the knowledge item. | |
| source | No | Optional source label. | |
| content | Yes | The knowledge itself, and why it matters. One finding per atom: aim for about 2,000 characters, and split rather than trim. Bodies dense with file paths, backslashes or fenced code are the ones that fail before reaching the server -- prefer forward slashes, and use `knowl_ingest_atoms` for several findings at once. Content past 8,000 characters is stored but never embedded, so search will not find it. | |
| category | Yes | Knowledge category. | |
| namespace | No | Write target; project is default. Non-project namespaces must be configured. | |
| reasoning | No | Optional reasoning or justification. | |
| confidence | No | Optional confidence from 0.0 to 1.0. Values outside that range are refused. | |
| provenance | No | How this came to be believed: observed (execution or direct inspection), user_stated (the human said so), or inferred (concluded without direct evidence). Claiming observed or user_stated ranks an item above one that claims nothing, and leaving this unset scores exactly the same as an honest inferred -- silence buys no rank, so say which it was. | |
| supersedes | No | Id of an active item this write replaces; it is marked superseded (retired but still queryable), not deleted. Pass it whenever you are correcting knowledge a query returned. Independently of this field, any category whose title names the same subject as an existing item supersedes it automatically, and content is never silently dropped. | |
| conflictKey | No | Optional normalized semantic identity key. | |
| alternatives | No | Optional alternatives considered for decisions. | |
| sourceCommit | No | Optional git commit where this knowledge was last reviewed. | |
| affectedPaths | No | Repository-relative file paths this knowledge depends on. Every query that returns this item returns them with it, and because content comes back truncated they are how the next reader reaches the source instead of searching for it. An item without them is a fact whose evidence only you can find. | |
| conflictScope | No | Optional scope for the conflict key. | |
| conflictExclusive | No | Whether only one active value may exist for this key/scope. |