automem

AutoMem Legacy Skill

This mode uses direct HTTP calls with curl.

API usage

Base URL: $AUTOMEM_API_URL

Store memory:

curl -s -X POST "$AUTOMEM_API_URL/memory" \
  -H "Content-Type: application/json" \
  ${AUTOMEM_API_KEY:+-H "Authorization: Bearer $AUTOMEM_API_KEY"} \
  -d '{
    "content": "Brief title. Context and details. Impact/outcome.",
    "tags": ["project-slug", "decision"],
    "importance": 0.7
  }'

Recall memory:

curl -s \
  ${AUTOMEM_API_KEY:+-H "Authorization: Bearer $AUTOMEM_API_KEY"} \
  "$AUTOMEM_API_URL/recall?query=QUERY&limit=20&format=detailed"

Update memory:

curl -s -X PATCH "$AUTOMEM_API_URL/memory/MEMORY_ID" \
  -H "Content-Type: application/json" \
  ${AUTOMEM_API_KEY:+-H "Authorization: Bearer $AUTOMEM_API_KEY"} \
  -d '{"content":"Updated context."}'

Delete memory:

curl -s -X DELETE "$AUTOMEM_API_URL/memory/MEMORY_ID" \
  ${AUTOMEM_API_KEY:+-H "Authorization: Bearer $AUTOMEM_API_KEY"}

Rules

• Recall preferences first with tags=preference, then task context with one semantic query built from the user's actual nouns.
• For debugging, recall with the error symptom as the semantic query and no tags= parameters — bugfix/solution tagging is incomplete, and a tag gate hides cross-corpus fixes.
• Tags are a hard gate. Use bare tags only, and avoid platform tags like openclaw.
• Store durable outcomes only.
• Default project tags belong on stores, not on every recall.
• If delete targets are ambiguous, recall likely matches first and ask for confirmation before deleting.
• Use memory-core and local memory files alongside AutoMem when file-backed notes are useful.
• Only call /health when AutoMem requests are failing and you need to debug the connection.