From lodis
Use when something worth remembering comes up in a session — a user preference, a correction, a decision, a durable fact about a person/project/organization, a lesson learned, or a progress event. Teaches you to choose between `memory_write` (durable facts) and `memory_write_snippet` (timestamped progress events), classify entities, resolve duplicates, and link memories into the graph. Trigger on "remember that…", "note that…", a user correction, or when you learn a non-obvious fact you'll want next session.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lodis:memory-captureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You have access to the Lodis MCP tools. This skill is the write discipline: **what** to store, **which tool** to use, and **how** to keep the store clean (typed, deduplicated, connected). Lodis never runs an LLM on the write path — entity typing, dedup resolution, and connections all come from you, the calling agent.
You have access to the Lodis MCP tools. This skill is the write discipline: what to store, which tool to use, and how to keep the store clean (typed, deduplicated, connected). Lodis never runs an LLM on the write path — entity typing, dedup resolution, and connections all come from you, the calling agent.
Write non-obvious things a future session would benefit from:
Do NOT write:
memory_search first if unsurePrefer pointers over copies. If the fact lives in a canonical source (a style guide, a config file, a spec), write a resource memory pointing to it (put the path/URL in structuredData) rather than duplicating the content. Lodis should be a graph of pointers, not a second copy of everything.
Keep this line sharp — it decides whether the memory shows up in default search:
memory_write → a durable fact / preference / decision / lesson / entity. Default-searchable.memory_write_snippet → "an event happened at time T" (shipped / advanced / started / stalled / blocked). Ephemeral, partitioned out of default search, queried via memory_query_progress / memory_progress_summary.memory_write lesson/fact for the durable part.memory_writeRequired: content, sourceAgentId, sourceAgentName, sourceType (stated | inferred | observed | cross-agent).
Strongly recommended: entityType (one of the 14 types) + entityName (canonical, e.g. "Sarah Chen", not "my manager") — these drive dedup and the graph. If you omit them the server stores the row and hints to classify later, but supplying them up front is better.
Optional: domain, detail, permanence (canonical | active | ephemeral), ttl ("24h", "7d", "30d" — implies ephemeral), structuredData, connections.
memory_write({
content: "Alex prefers async written updates over standup calls.",
entityType: "preference", entityName: "Alex Rivera",
domain: "work", sourceType: "stated",
sourceAgentId: "<your-id>", sourceAgentName: "<your-name>",
connections: [{ targetEntityName: "Alex Rivera", relationship: "about" }],
})
similar_found response)If a similar memory exists, memory_write returns status: "similar_found" with the existing memory and options instead of writing. Pick a resolution and call again with existingMemoryId:
valid_to), store new as currentChoose deliberately; don't reflexively keep_both (that's how duplicates accumulate).
memory_write_snippetRequired: snippet_type, life_domain (a registered slug), content, source_system, event_timestamp (ISO 8601), sourceAgentId, sourceAgentName.
The life_domain must already be registered (and not archived) via memory_register_domain, or the write is rejected — register it first if needed.
Always pass connections to link the event to the durable entities it concerns, so it isn't graph-isolated:
memory_write_snippet({
snippet_type: "shipped", life_domain: "engineering",
content: "Shipped the rate-limiter for the public API.",
source_system: "github", event_timestamp: "<ISO>",
sourceAgentId: "<your-id>", sourceAgentName: "<your-name>",
connections: [{ targetEntityName: "Public API", relationship: "about" }],
})
When you write a memory related to entities already in the graph, populate connections (up to 50): each is { targetEntityName | targetMemoryId, relationship }. Common relationships: about, involves, part_of, works_at, references, supports, contradicts, related. Prefer targetMemoryId when you have it; otherwise targetEntityName resolves case-insensitively.
Write one discrete fact per call — don't batch several facts into one content. If you're tempted to use "and", that's usually two memories (and possibly a compound that memory_split should break apart later).
npx claudepluginhub sunrise-labs-dot-ai/lodis --plugin lodisCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.