Skip to main content
Glama
liza-studio

skillmem — long-term memory for Claude Code & Codex

by liza-studio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mem_learn

Record a skill learned from doing a task—trigger, steps, outcome, lessons—and save it as an unapproved skill record pending owner approval.

Instructions

Record a skill learned by doing: what triggered the task, the steps, the outcome (success / partial / failure) and the lessons. WRITES: one record of kind='skill' with Ebbinghaus strength, origin='agent', UNAPPROVED until the owner runs skillmem trust. slug must be new, conventionally 'skill-'; an existing slug with different text is refused (use mem_update), byte-identical text returns the existing skill with its approval intact, applying only the metadata you pass (tags, topics, project). A slug that already holds a note is refused. check_conflicts (default true) refuses a near-duplicate of any record it can see, a plain note included, and names it. Write bilingually (EN+RU) if you work in both — lexical search is per-language. Returns ok and slug. Use mem_write for a plain note or rule; use mem_reinforce afterwards to record whether the skill held up.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesUnique slug like 'skill-deploy-nginx'.
tagsNo
stepsYesSteps taken to complete the task.
titleYesShort skill title.
topicsNo
lessonsNoWhat to do differently next time.
outcomeYesResult: success/partial/failure.
projectNo
triggerYesWhat situation triggers this skill.
ttl_daysNo
visibilityNopublic
check_conflictsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.12.0
    • changedInput schema / properties / project / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / tags / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedInput schema / properties / topics / type
      Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
    • changedInput schema / properties / ttl_days / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
  2. First observedv0.10.5

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers: it discloses the record kind, origin, unapproved state pending `skillmem trust`, the dedup semantics (byte-identical returns existing skill with approval intact vs. differing text refused), conflict-checking against other records including plain notes, and the return value (ok and slug). This is unusually rich behavioral disclosure for a write tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the record's content is stated first, then write semantics, then routing to siblings. Nearly every sentence carries new information, though the run-on semicolon chains make it slightly heavier than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, no-annotation, no-output-schema write tool, the description covers the critical unknowns: side effects, approval state, dedup/conflict behavior, and return shape. It stops short of explaining ttl_days and visibility, and does not say what happens to a rejected write beyond refusal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, so the description must compensate, and it does for the highest-risk parameters: slug conventions and collision behavior, check_conflicts' default and effect, and the metadata-only application for tags/topics/project. It leaves ttl_days and visibility unaddressed, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Record a skill learned by doing') and enumerates the content the record carries (trigger, steps, outcome, lessons). It explicitly distinguishes itself from siblings by naming mem_write for a plain note/rule, so an agent can route without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternatives and the conditions that select them: use mem_update when the slug already exists with different text, mem_write for a plain note or rule, and mem_reinforce afterward to record whether the skill held up. The when-not (existing slug, existing note slug) is spelled out rather than inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools