---
name: zo-memory
description: >
  Rob's persistent long-term memory system — a structured markdown directory at memory/ that accumulates
  distilled knowledge about Rob across conversations. Covers the directory layout, update mechanism,
  schema principles, and the fire-and-forget _update.py pipeline. Reference this skill whenever
  interacting with or reasoning about Rob's memory.
compatibility: Created for Zo Computer
metadata:
  author: rob.zo.computer
---

## Overview

Rob's memory lives at `memory/` in the workspace. It is a structured set of markdown files that Zo
maintains across conversations — capturing who Rob is, what he cares about, what he's building, and
what he's learned. The system is designed to grow and reorganize organically.

## Directory Structure (dynamic)

The layout evolves. As of Feb 2026:

```
memory/
├── SCHEMA.md           # Ontology description and principles
├── _update.py          # Fire-and-forget updater (not memory content)
├── _whoami.py          # Regenerates WHOAMI.md via child Zo invocation
├── WHOAMI.md           # Auto-generated rollup profile (output of _whoami.py)
├── identity/
│   ├── about.md        # Background, bio, key facts
│   ├── preferences.md  # Communication style, values, tools
│   ├── personality.md  # Temperament, energy, intellectual style
│   └── work-style.md   # Pace, schedule, working patterns
├── goals/
│   └── active.md       # Current goals and aspirations
├── projects/           # Significant projects and endeavors
├── interests/
│   ├── topics.md       # Intellectual curiosities, research threads
│   └── activities.md   # Hobbies, sports, recurring activities
├── people/
│   └── known.md        # People mentioned across conversations
└── knowledge/
    └── insights.md     # Conclusions, meta-patterns, things learned
```

**This structure is not fixed.** New categories, files, merges, and splits are expected as memory
grows. Always read `memory/SCHEMA.md` for the current layout before making changes.

## How Memory Gets Updated

A **conditional rule** on Rob's Zo triggers after each semantic deliverable (finished task, answered
question, research conclusion). The rule fires:

```bash
nohup python /home/workspace/memory/_update.py '<summary>' > /dev/null 2>&1 &
```

### What `_update.py` does

1. Takes a self-contained summary string as its only argument
2. Sends the summary to a child Zo invocation via the `/zo/ask` API
3. The child Zo reads `SCHEMA.md`, explores the current file tree, reads relevant files, then
   integrates the new information — updating existing files, creating new ones, or restructuring
   as needed
4. Updates `SCHEMA.md` if the directory structure changed

### Summary Quality

The child invocation has **zero context** from the parent conversation. The summary must be:
- Self-contained and specific
- Not "helped with a project" but "Rob built a webhook handler for Stripe checkout events..."
- Rich enough that a future Zo reading memory files could reconstruct useful context

### When to trigger

- After a semantic deliverable is complete (task finished, question answered, research concluded)
- NOT during multi-step work-in-progress
- NOT for purely mechanical tasks that reveal nothing new

### What to capture

- Facts about Rob (background, circumstances, relationships)
- Preferences and opinions
- Personality patterns
- Goals and aspirations (explicit and inferred)
- Project context (architecture, decisions, status)
- Intellectual interests and research threads
- People and relationships
- Knowledge, insights, mental models
- Recurring workflows and tool preferences

### What NOT to store

- Verbatim transcripts or tool outputs
- Ephemeral task details (commands, debug steps)
- Info already captured in workspace files
- Trivially mechanical tasks

## Schema Principles

From `SCHEMA.md`:

- **Evolve the structure** — don't force info into ill-fitting categories
- **Distill, don't log** — store synthesized knowledge, not transcripts
- **Be specific** — "plays tennis regularly, prefers singles, follows ATP" > "likes tennis"
- **Date when useful** — tag with approximate dates like `(Feb 2026)`
- **Cross-reference** — link between files when connections exist
- **Prefer depth over breadth** — few well-maintained files > many thin stubs

## Reading Memory

To understand Rob's current memory state:

```bash
cat memory/SCHEMA.md                    # current ontology
find memory/ -name "*.md" -not -name "_*" | sort  # all memory files
```

Then read specific files as needed. The memory is small enough to read in full when useful context
is unclear.

## WHOAMI Rollup

`memory/WHOAMI.md` is a single synthesized document — a complete, cohesive profile of Rob generated
from all memory files. It's produced by `_whoami.py`, which works like `_update.py`: fires a child
Zo invocation via `/zo/ask` that reads every memory file and writes a fresh rollup from scratch.

### Usage

```bash
python /home/workspace/memory/_whoami.py
```

### What it produces

A dense, readable, third-person profile covering: background, what he's building (Zo), how he
thinks and works, what he cares about, intellectual interests, systems he's built, key people,
and meta-patterns. Written to be read in 3–5 minutes by a Zo instance with zero prior context.

### When to run

- After significant memory changes (new projects, major life events, goal shifts)
- When Rob asks for a regenerated profile
- Not automatically — this is on-demand, unlike `_update.py` which fires after every deliverable