Ontology Knowledge Graph

Problem

In multi-step agent work, memory, tasks, dependencies, and shared state often end up scattered across chat history and temporary files. When skills need to read the same state, an unstable structure can cause missing fields, accidental overwrites, and hard-to-track dependencies.

How It Works

The skill models knowledge as a typed graph: each object is an entity with type, properties, and relations, and every mutation is validated before commit.
- Storage: defaults to memory/ontology/graph.jsonl; complex graphs can move to SQLite.
- Mutation: supports create, query, relate, and validate; existing data should be appended or merged rather than overwritten.
- Constraints: type, enum, forbidden properties, relation type, cardinality, acyclic: true checks, and Event end >= start rules can be declared in memory/ontology/schema.yaml.
- Planning: multi-step plans can be expressed as graph transformations, validating each step before execution.

Boundaries

It operates mainly on workspace files and a local CLI, not as a full graph database or enterprise permission system. Some higher-level constraints may remain documentation-only unless implemented. Cross-skill use should declare shared ontology objects to avoid implicit overwrites.