# Publishing Ezra Memory

> Creates and updates the public ezra-memory repository from Ezra's live MemFS using a strict allowlist, synthetic examples, privacy scans, fresh-history safeguards, and approval-gated publishing. Use when asked to sanitize, redact, review, package, or publish an Ezra memory snapshot.

- Skill: `letta-ai/publishing-ezra-memory` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add letta-ai/publishing-ezra-memory`
- Raw SKILL.md: https://api.skillmd.com/api/skills/letta-ai/publishing-ezra-memory/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: letta-ai (https://skillmd.com/u/letta-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/letta-ai/publishing-ezra-memory

---

# Publishing Ezra Memory

Publish a **curated derivative**, never a redacted clone of the live repository.

## Hard boundaries

- Never copy the live `.git` directory or push the live MemFS remote.
- Never publish real files from `users/`, incident/support-report archives, corrections, attachments, private skills, or operational infrastructure notes.
- Never rely on deletion alone: old Git objects can retain removed data.
- Never expose user handles, names, accessibility details, projects, message links, IDs, run IDs, credentials, machine paths, private routes, or team-operational data.
- Use synthetic examples clearly labeled fictional.
- Do not push until the requester explicitly approves the reviewed snapshot or update.

## Fixed locations

Resolve the source from `$MEMORY_DIR`. Use a separate staging checkout, conventionally:

```bash
PUBLIC_REPO_URL=https://github.com/letta-ai/ezra-memory.git
PUBLIC_CHECKOUT="$HOME/ezra-memory-public"
```

Do not configure the live MemFS repository with the public GitHub URL as an additional remote.

## Workflow

### 1. Inspect before editing

Check the live MemFS status and inventory categories. Do not print private file bodies unless needed for the curation decision.

```bash
git -C "$MEMORY_DIR" status --short
find "$MEMORY_DIR" -path '*/.git' -prune -o -type f -print
```

Build an allowlist of durable, educational concepts. Rewrite content into public-safe files rather than bulk-copying source directories.

Good public categories:

- Agent role and general operating principles
- Pinned-versus-on-demand memory organization
- Memory-maintenance rules
- Generic support and diagnostic methodology
- Conceptual conversation, context, recall, and MemFS architecture
- Explicitly fictional schemas and project examples

### 2. Work in an isolated checkout

Clone the public repository into a dedicated directory. If updating an existing checkout, fetch/pull and verify it is clean first. Never use the live MemFS checkout.

```bash
rm -rf "$PUBLIC_CHECKOUT"
git clone "$PUBLIC_REPO_URL" "$PUBLIC_CHECKOUT"
git -C "$PUBLIC_CHECKOUT" status --short --branch
```

For the initial publication, create a new repository history. For later updates, preserve only the public repository's history.

### 3. Curate with an allowlist

Edit only deliberately selected public files. Keep the public tree small. A rejected category stays rejected unless the requester explicitly revises the privacy boundary.

Do not perform broad operations such as:

```text
cp -R "$MEMORY_DIR" ...
rsync "$MEMORY_DIR/" ...
git remote add public ...   # inside live MemFS
```

### 4. Run privacy and integrity checks

Run every check in [the privacy checklist](references/privacy-checklist.md). Treat any match as a review finding, not an automatic false positive.

At minimum verify:

- No live `.git` data entered a new snapshot
- No symlinks, binaries, attachments, or unexpected files
- No secret/token patterns, absolute home paths, emails, private URLs, UUIDs, snowflakes, or agent/run/message identifiers
- No names/handles from live `users/*.md` occur in public content
- All Markdown has valid frontmatter where required
- All internal links resolve
- The staged Git diff contains only intended files
- Commit author and committer use a public-safe identity

Use an independent read-only reviewer on the final small tree when available. Incorporate findings, then rerun all scans.

### 5. Present review artifact or diff

Before the first publication, package the history-free staged tree for requester review. For later updates, show a concise staged diff/stat and summarize exclusions and scan results.

Do not claim “safe” solely because regex scans passed. State exactly what was checked and what still requires human judgment.

### 6. Commit safely

Follow the repository's normal commit protocol. Explicitly set author and committer for the command without changing Git config:

```bash
GIT_AUTHOR_NAME='Ezra' \
GIT_AUTHOR_EMAIL='noreply@letta.com' \
GIT_COMMITTER_NAME='Ezra' \
GIT_COMMITTER_EMAIL='noreply@letta.com' \
git commit -m '<message>'
```

Immediately verify all reachable public-repository commits being introduced:

```bash
git log --format='%H %an <%ae> %cn <%ce>' <upstream>..HEAD
git fsck --full
git status --short --branch
```

If an unpushed initial root commit accidentally contains a private machine identity, discard the isolated empty-repository checkout and recreate the root commit. Do not amend unless explicitly requested. Never rewrite already-published history without separate authorization.

### 7. Approval-gated push

Push only after explicit requester approval of the snapshot/update:

```bash
git push origin main
git status --short --branch
git ls-remote --heads origin main
```

Report the repository URL, commit hash, scan summary, and any deliberately omitted categories.

## Updating later

For infrequent refreshes:

1. Read this skill and the existing public repository first.
2. Compare durable architectural changes, not every live-memory change.
3. Rewrite only genuinely useful public concepts.
4. Preserve the established privacy boundary by default.
5. Run the complete checklist and obtain approval before pushing.