ai-memory-durable-pages

ai-memory durable pages

Use this skill only for deliberate durable wiki mutations. Routine session capture is automatic, and permanent notes require an explicit user request.

Tools in this cluster

• memory_resolve_write_target validates and canonicalizes an exact existing writable destination without creating or changing it. Bulk importers use it before their first write.
• memory_write_page writes or replaces a durable wiki page for permanent project knowledge.
• memory_write_pages_batch writes a bounded set of complete page versions atomically for a bulk importer. Every entry must be conditional; do not use it for routine notes.
• memory_patch_page atomically changes named Markdown sections in an existing page without re-emitting its frontmatter or unrelated body.
• memory_delete_page removes a durable wiki page by exact path.
• memory_restore_page lists a page's checkpoints (no rev) or writes an earlier version back (with rev), including a deleted page. It is admin only on a multi-user server and does not reach scope: "profile" pages.

Writing durable memory

Write a page only when the user explicitly asks to remember something permanently, save a note, add an annotation, or record project knowledge. Do not use durable pages for transient progress, normal status updates, or next-session context.

Put the page title as a # H1 on the first line of the body and omit the separate title argument. ai-memory derives the title from that H1. Keep the content concise and fact-like, with enough context that a future agent can apply it without rereading the whole session.

Optional top-level metadata: kind (64 characters), entities (10 names, 64 characters each, normalized and deduplicated), abstract (1,024 characters), and relations (an object mapping causes, fixes, or contradicts to page target arrays, 32 targets total, 1,024 characters each). Relation targets use path, project:path, or workspace/project:path; extensionless page paths resolve with .md, and scope components must already be trimmed. A page that describes repository files can name them in source_files: up to 16 {path, commit} entries, each a repository-relative /-separated path and the 7-64 hex commit (git rev-parse HEAD) the page was checked against. The server never reads those files; when one changed since its commit, a client records memory_feedback with signal: "stale", and rewriting the page with the new commit clears the flag. Limits apply to raw values before trimming, normalization or deduplication. Arbitrary frontmatter and author fields are not editable. Every memory_write_page call replaces the whole page and its metadata; omitted fields are cleared. Read the current page first when preserving existing content matters, and pass its returned page_id as expected_page_id so a concurrent change fails without writing. Use create_only: true when the page must not already exist; do not combine the two preconditions.