Unnamed Skill
ldclabs/KIP🧬 KIP is a Knowledge-memory Interaction Protocol designed for LLMs, aiming to build a sustainable learning and self-evolving memory system for AI Agents.
55 stars
3 forks
Python
7 views
SKILL.md
name: kip-cognitive-nexus
description: Persistent graph-based memory for AI agents via KIP (Knowledge Interaction Protocol). Provides retrieval-first memory operations (KQL), durable writes (KML), schema discovery (META), and memory hygiene patterns. Use whenever the agent needs to consult or update persistent memory, especially for: remembering user preferences/identity/relationships, storing conversation events, answering questions that depend on past sessions, and any task involving execute_kip.
KIP Cognitive Nexus
You have a Cognitive Nexus (external persistent memory) accessible via KIP commands.
Operating Principle
You are not stateless—you have persistent memory. Your job:
- Retrieve first: Before answering non-trivial questions, check memory
- Store selectively: Capture stable facts, preferences, relationships
- Use silently: Do not expose KIP syntax to users
Script Interface
# Single command
python scripts/execute_kip.py --command 'DESCRIBE PRIMER'
# With parameters (safe substitution)
python scripts/execute_kip.py \
--command 'FIND(?p) WHERE { ?p {type: :type} } LIMIT :limit' \
--params '{"type": "Person", "limit": 5}'
# Batch commands
python scripts/execute_kip.py \
--commands '["DESCRIBE PRIMER", "FIND(?t.name) WHERE { ?t {type: \"$ConceptType\"} }"]'
# Dry run (validation only, use before DELETE)
python scripts/execute_kip.py --command 'DELETE CONCEPT ?n DETACH WHERE {...}' --dry-run
Environment: KIP_SERVER_URL (default: http://127.0.0.1:8080/kip), KIP_API_KEY (optional)
Core Operations
1. Schema Discovery (Start Here)
DESCRIBE PRIMER -- Global summary + domain map
DESCRIBE CONCEPT TYPE "Person" -- Type schema
SEARCH CONCEPT "alice" LIMIT 5 -- Fuzzy entity search
2. Query (KQL)
FIND(?p, ?p.attributes.role) WHERE { ?p {type: "Person"} } LIMIT 10
FIND(?e) WHERE { ?e {type: "Event"} (?e, "belongs_to_domain", {type: "Domain", name: "Projects"}) }
3. Store (KML)
UPSERT {
CONCEPT ?e {
{type: "Event", name: "conv:2025-01-09:topic"}
SET ATTRIBUTES { event_class: "Conversation", content_summary: "..." }
SET PROPOSITIONS { ("belongs_to_domain", {type: "Domain", name: "Projects"}) }
}
}
WITH METADATA { source: "conversation", author: "$self", confidence: 0.9 }
4. Delete (Carefully)
DELETE CONCEPT ?n DETACH WHERE { ?n {type: "Event", name: "old_event"} }
-- Always use --dry-run first; DETACH is mandatory
What to Store
| Store ✓ | Do NOT Store ✗ |
|---|---|
| Stable preferences, goals | Secrets, credentials |
| Identities, relationships | Raw transcripts (use raw_content_ref) |
| Decisions, commitments | Low-signal chit-chat |
| Corrected facts | Highly sensitive data |
Memory Types
| Layer | Type | Lifespan | Example |
|---|---|---|---|
| Episodic | Event |
Short → consolidate | "User asked about X on 2025-01-09" |
| Semantic | Person, custom |
Long-term | "User prefers dark mode" |
Consolidation: After storing an Event, ask "Does this reveal something stable?" If yes, extract to durable concept.
References
- Agent workflow patterns and KIP syntax: references/INSTRUCTIONS.md