/SKILL.md
Hybrid conversational memory management using SQLite and a vector database for retrieval-augmented user context. Use when building or updating assistants that need persistent user facts, lexical plus semantic retrieval, conflict arbitration, confidence scoring, temporal validity, and profile injection across turns.
npx skillsauth add lilily58/mem mem-skillInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Implement a memory loop with hybrid retrieval.
Use SQLite as source of truth and Chroma as vector index.
Use this stack by default:
mem.db) for facts and history.Do not require PostgreSQL or Redis in the baseline implementation.
Store atomic facts in SQLite.
Use this minimum schema:
{
"fact_id": "uuid",
"user_id": "string",
"key": "string",
"value_text": "string",
"value_json": "json|null",
"category": "identity|hard_preference|soft_preference|task_context|health|other",
"confidence": 0.0,
"event_time": "ISO-8601|null",
"valid_from": "ISO-8601",
"valid_to": "ISO-8601|null",
"status": "active|superseded|expired|pending_confirmation",
"source_turn_id": "string",
"source_excerpt": "string",
"embedding_id": "string|null",
"created_at": "ISO-8601",
"updated_at": "ISO-8601"
}
Create archive table for superseded or expired facts.
Create these tables:
facts for active and historical fact rows.fact_history for immutable audit records.facts_fts as FTS5 mirror on searchable text.Mirror facts_fts from facts with triggers or explicit sync jobs.
Index these columns in facts:
user_idkeystatusvalid_toupdated_atUse one Chroma collection for facts.
Store:
id = embedding_iddocument = value_textmetadata = {fact_id, user_id, key, category, status, valid_from, valid_to, confidence, updated_at}Update vector records whenever fact text changes.
Delete or mark vectors for facts no longer retrievable.
Queue each completed turn:
(user_input, assistant_response, turn_id, timestamp, user_id)
Run extraction, retrieval, arbitration, and persistence in background worker.
Keep reply loop independent from observer latency.
Extract entities and intent from current input.
Run lexical retrieval from SQLite FTS5:
user_id.status in (active, pending_confirmation).top_k_lex (default 20).Run vector retrieval from Chroma:
top_k_vec (default 20).Fuse results into one candidate list.
Use default weighted score:
HybridScore = 0.45*NormLexical + 0.45*VecSim + 0.10*RecencyBoost
Use recency boost from updated_at or last_mentioned_at.
Fallback to lexical-only retrieval when vector service fails.
Run an internal auditor prompt over retrieved candidates.
Use this prompt template:
You are a memory auditor.
Old facts:
{OLD_FACTS}
New user input:
{USER_INPUT}
Tasks:
1) Detect confirmations and repetitions.
2) Detect updates for same key.
3) Detect contradictions.
4) Decide temporary versus durable change.
5) Return JSON actions only.
Require output:
{
"actions": [
{
"type": "insert|update|supersede|expire|noop|mark_pending_confirmation",
"key": "string",
"new_value_text": "string|null",
"new_value_json": "object|null",
"target_fact_id": "uuid|null",
"valid_from": "ISO-8601|null",
"valid_to": "ISO-8601|null",
"confidence_delta": 0.0,
"reason": "string"
}
]
}
Reject non-JSON output and re-prompt.
Apply actions in one SQLite transaction.
Use these rules:
Write every destructive change to fact_history.
Use idempotency key:
(turn_id, key, action_hash)
After transaction commit, sync changed facts to Chroma.
Use this policy:
Keep sync asynchronous so writes are not blocked by embedding calls.
Build structured profile on schedule:
N turns (default 5).Project only active and valid facts:
{
"identity": {},
"hard_preferences": {},
"soft_preferences": {},
"current_tasks": [],
"recent_changes": [],
"sensitive_topics": []
}
Keep confidence and timestamp fields in projection output.
Inject only relevant profile slices for next prompt.
Use priority:
Drop stale and low-confidence fields first under tight token budget.
Use default confidence rules:
0.40.1.00.Ask clarification only for high-value conflicts.
Track these metrics:
Run release ablations:
Publish metric deltas for each mode.
Treat identity, health, and finance-like keys as high risk.
Use these guardrails:
0.90.user_id and key.Complete implementation only when all items pass:
development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
development
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
development
Run, watch, debug, and extend OpenClaw QA testing with qa-lab and qa-channel. Use when Codex needs to execute the repo-backed QA suite, inspect live QA artifacts, debug failing scenarios, add new QA scenarios, or explain the OpenClaw QA workflow. Prefer the live OpenAI lane with regular openai/gpt-5.4 in fast mode; do not use gpt-5.4-pro or gpt-5.4-mini unless the user explicitly overrides that policy.
development
End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests. Use when Codex needs to run, rerun, debug, or interpret VM-based install, onboarding, gateway smoke tests, latest-release-to-main upgrade checks, fresh snapshot retests, or optional Discord roundtrip verification under Parallels.