publishing-ezra-memory

name	publishing-ezra-memory
description	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.

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:

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.

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.

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:

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. 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:

GIT_AUTHOR_NAME='Ezra' \
GIT_AUTHOR_EMAIL='[e-mail]' \
GIT_COMMITTER_NAME='Ezra' \
GIT_COMMITTER_EMAIL='[e-mail]' \
git commit -m '<message>'

Immediately verify all reachable public-repository commits being introduced:

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:

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.