agi-is-going-to-arrive/memory-palace-openclaw/memory-palace

Memory Palace

Use this skill whenever a task involves the Memory Palace memory system itself.

Preparation before choosing tools

• Read docs/skills/memory-palace/references/mcp-workflow.md before choosing tools.
• If the user is asking about Memory Palace behavior, workflow, or trigger rules, consult the repo-local references before answering from memory.
• If the request is ambiguous, map it to the smallest safe workflow instead of chaining tools blindly.

First memory tool call

• Before the first real Memory Palace operation in a session, start with read_memory("system://boot").
• If the task is recall-oriented and the URI is still unknown after boot, continue with search_memory(..., include_session=true).
• Use include_expired=true only when the user explicitly asks for historical,

future-validity, or superseded memories.

Fresh-context rule

• Do not assume a subagent, clean CLI session, or retry inherits the full parent conversation.
• When context matters, reload Memory Palace state explicitly with system://boot, search_memory(...), or targeted read_memory(...).
• Parallelize only independent reads, searches, or mirror checks. Serialize conflicting writes and overlapping edits.

Non-negotiable rules

• Start with read_memory("system://boot") before the first real memory operation in a session.
• If the URI is unknown, use search_memory(..., include_session=true) before read_memory.
• Read before every mutation: create_memory, update_memory, delete_memory, add_alias.
• Prefer update_memory over duplicate create_memory when guard signals point to an existing memory.
• Treat guard_action=NOOP|UPDATE|DELETE|IGNORE as a stop signal that requires inspection, not as a warning to ignore.
• If guard_action is NOOP, stop the write, inspect guard_target_uri / guard_target_id, and read the suggested target before deciding whether anything should change.
• If guard_action is IGNORE, do not force-write unless the user explicitly re-confirms that the content should become durable memory.
• Treat guard_target_uri and guard_target_id as the canonical hints for choosing the real mutation target.
• Do not invent provenance, temporal fields, or memory links when they are absent.
• Do not expose raw compact-context metadata such as session_id, source_hash, gist_method, or flushed_at to users.
• Use compact_context(force=false) only for long or noisy sessions that should be distilled.
• Use index_status() before rebuild_index(wait=true) unless the user explicitly asks for immediate rebuild.
• For destructive or structural changes, mention the review or rollback path before finishing.

Default workflow

1. Boot the memory context.
2. Recall candidates.
3. Read the exact target.
4. Mutate only after inspection.
5. Compact or rebuild only when symptoms justify it.
6. End with a short summary of what changed and which URIs were touched.

Tool surface that this skill governs

Core tools (use these for everyday memory work)

• read_memory - Read a memory by URI (start with system://boot)
• search_memory - Find memories by query
• create_memory - Store a new memory
• update_memory - Update an existing memory
• delete_memory - Remove a memory

Maintenance tools (use only when symptoms justify it)

• add_alias - Add a URI alias for an existing memory
• compact_context - Distill a long/noisy session into a compact summary
• compact_context_reflection - Compact and commit into the reflection lane (usually auto-called by plugin; client-facing internal errors are sanitized)
• rebuild_index - Rebuild the search index (check index_status first)
• index_status - Check index health before rebuilding
• ensure_visual_namespace_chain - Ensure visual memory URI hierarchy exists

When to open the reference

Open docs/skills/memory-palace/references/mcp-workflow.md when you need:

• exact tool selection rules
• write-guard handling
• compact vs rebuild decisions
• review, snapshot, or maintenance expectations
• a reminder of all 11 MCP tools and their safest usage order

Open docs/skills/memory-palace/references/trigger-samples.md when you want concrete should-trigger / should-not-trigger prompts for manual review or trigger regression checks.

Prefer these repo-visible canonical paths over hidden mirror-relative paths such as .gemini/skills/... or .codex/skills/..., because some CLIs can load the skill but still block direct reads from hidden skill directories.

The canonical repo-visible path of the trigger sample set is:

• docs/skills/memory-palace/references/trigger-samples.md

Examples

• Should trigger: "帮我把这条长期偏好记到 Memory Palace。"
• Should trigger: "查一下之前记过没有，再决定 create 还是 update。"
• Should trigger: "为什么 guard_action=NOOP，下一步该怎么做？"
• Should not trigger: "把 README 第一段改得更顺一点。"
• Should not trigger: "解释一下 Python 的内存管理。"

Troubleshooting

• If a write is blocked by guard_action=NOOP, stop, inspect guard_target_uri / guard_target_id, and read the suggested target before doing anything else.
• If the user asks for old or superseded facts, rerun recall with include_expired=true; otherwise keep inactive records out of recall.
• If a clean session, subagent, or retry loses context, reload with read_memory("system://boot"), then search_memory(..., include_session=true) if the URI is still unknown.
• If a CLI can load the skill but cannot reliably read hidden skill directories, answer from the repo-visible canonical paths under docs/skills/....