@letta-ai/letta-code 0.34.17 → 0.34.19

package/skills/maintaining-core-memory/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: maintaining-core-memory
+description: Maintains an agent's core memory, the editable part of its system prompt. Use to modify the agent's core behavior, embed critical knowledge (needed on every turn), or instruct the agent on how to use deferred memory.
+---
+
+Core memory is the agent's prompt, refined over its lifetime. Treat each change as a revision of that prompt, not an append to a log: the usual edit sharpens, merges, or replaces an existing principle, and a new one earns its place only when no existing one can absorb it.
+
+## Prompt format
+
+The agent's system prompt is compiled from the Markdown files at the root of `$MEMORY_DIR`. Each root file except `MEMORY.md` becomes a block named after the file, in alphabetical order by filename, followed by the root `MEMORY.md`:
+
+```
+{{base system prompt}}
+
+<human>
+<description>{{description from human.md frontmatter}}</description>
+{{body of human.md}}
+</human>
+
+<persona>
+<description>{{description from persona.md frontmatter}}</description>
+{{body of persona.md}}
+</persona>
+
+<memory>
+{{body of root MEMORY.md}}
+<deferred-memory>
+<directory path="{{dir}}/" index="{{dir}}/MEMORY.md" />
+</deferred-memory>
+</memory>
+```
+
+Every root file except `MEMORY.md` starts with frontmatter containing exactly two fields:
+
+```markdown
+---
+name: human
+description: Who the user is and how they want to work together.
+---
+```
+
+- The file name becomes the block name, so `human.md` renders as `<human>`. Choose short, stable names.
+- The `description` is rendered into the prompt. Write it for the agent: one line saying what the block holds.
+- Root `MEMORY.md` has no frontmatter. Its body is the only part of `<memory>` you write.
+- The `<deferred-memory>` list is generated: one entry per top-level directory that has its own `MEMORY.md`, showing only the path. `skills/` is never listed; skills appear separately.
+- Edits take effect only after they are committed, and only in later system prompts. The current conversation keeps the prompt it started with.
+
+Read `$MEMORY_DIR/.memfs.config.json` if it exists. The memory repository's pre-commit hook enforces it:
+
+- `maxCoreMemoryCharacters` caps the total size of all root Markdown (default 65,536 characters).
+- `maxFileCharacters` caps each memory file, frontmatter included (default 20,000 characters). `fileCharacterLimits` overrides it per glob; the first match wins and `null` removes the cap.
+- `readOnlyFiles` lists globs whose files cannot change. Do not edit them.
+
+When the config file is absent, the defaults apply. Treat the limits as a ceiling, not a target: stay well below them. When an edit does not fit, move detail into deferred memory instead of raising a limit; change the config only when the user asks.
+
+## Writing prompts
+
+Core memory is the agent's working model: who it is, how the user thinks and what they value, and the principles that follow. It is not a list of rules.
+
+- Treat a correction or preference as evidence about that model. Find the principle it belongs to and sharpen or rewrite that principle. Add a new one only when the evidence shows something the model was missing.
+- When several rules share a cause, replace them with the one principle that explains them all, and delete the lines it absorbs in the same edit. Adding the principle while keeping the old rules is a log with a summary on top. A healthy file becomes more general over time; a growing count of narrow rules is a sign of failure.
+- State the principle with the reason that makes it generalize: "Verify claims against the running system, because Sarah trusts evidence over plausibility", not three separate rules about tests, logs, and deployments.
+- Write to the agent in the second person or imperative mood: "Lead with the answer", not "The user likes answers first". Say what to do rather than only what to avoid.
+- Leave out provenance: no names, dates, quotes, or stories about the incident. Message history already holds the events, and the commit message records why the line changed. When you edit a section that already contains provenance-laden rules, rewrite them as principles; nothing is lost, because git keeps the old text.
+- Update only from a pattern or an explicit instruction, not a single ambiguous event.
+- Check that a change does not contradict an existing line; resolve the conflict instead of adding both.
+- Write in plain language without all-caps or absolute emphasis. Overstated instructions get overapplied.
+- Leave out content the agent can cheaply rederive: file contents, command lists, current status, and recent activity.
+- Never store secrets. Reference them by name, such as `$SECRET_NAME`.
+
+## Teach with examples, not more rules
+
+A correction that reveals a gap in a principle calls for sharpening its wording. A correction the principle already covers, such as the user pointing out the same kind of mistake again, means the principle is too abstract to apply: attach a contrastive example to it instead of rewording it again or adding another rule.
+
+```markdown
+- Lead with the answer, because the user reads the first line and skims the rest.
+  - Not: "I looked at the config, then the logs, and it turns out the timeout is too low." Instead: "The timeout is too low: 5s, and the slow query takes 8s."
+```
+
+- Keep at most one or two examples per principle, and make them differ from each other. A new correction replaces the weaker example rather than adding another.
+- Write the example as a generic instance of the behavior, not a record of the incident: no dates, names, or quotes.
+- Keep the bad half short and labeled, and end on the good half. The agent imitates the details of examples, including the ones it should avoid.
+- When a principle or example starts producing the wrong behavior, revise or remove it. A memory edit is a hypothesis about the agent's behavior; later conversations test it.
+
+## Design root MEMORY.md so deferred memory gets used
+
+The agent consults deferred memory only when something in its prompt tells it to. The generated `<deferred-memory>` list gives directory paths and nothing else, so root `MEMORY.md` decides whether everything outside core memory is ever read. A directory with no useful entry here is effectively lost.
+
+- Give each directory a one-line entry saying when to open it, in the words a future request would use: "deployments, rollbacks, on-call runbooks", not "ops notes".
+- Name a specific deeper file when its topic would not be guessable from the directory entry.
+- Say what kinds of questions should send the agent to memory before it answers from assumption, such as an unfamiliar person, project, or system named in the conversation.
+- Do not re-index root files or skills; both are already in the prompt.
+- After adding a directory or file, check that a natural future request would reach it by reading only root `MEMORY.md` and the indexes beneath it.
+
+## Shrink before you grow
+
+When a root file is long or the total is near its limit:
+
+1. Delete stale, duplicated, or rederivable content.
+2. Move subject detail into deferred memory and leave a one-line pointer in root `MEMORY.md`.
+3. Move procedures into skills.

package/skills/maintaining-deferred-memory/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: maintaining-deferred-memory
+description: Maintains deferred memory, which stores accumulated knowledge, analysis, and observations made by the agent over time. Use when saving knowledge (e.g. about a person, project, repository, system, or event). Do NOT use for managing skills, prompts, or for saving information that is already automatically stored in the message history.
+---
+
+Deferred memory contains the agent's knowledge. Use deferred memory for understanding of a subject that matters only when that subject comes up. If the agent needs it on most turns, it is core memory: use the `maintaining-core-memory` skill. If it is a procedure with a trigger, use the `creating-skills` skill.
+
+Deferred memory should NOT be used to store:
+- Information that can be accessed by querying the message history (recall memory). For example, logs of specific interactions can simply be looked up in past messages. Reserve deferred memory to store knowledge that is actually *derived* from experience, or to organize knowledge in a way that optimizes recalling the right information at the right time through progressive disclosure.
+- Justifications or reasons for updating memory. These belong in the git commit history of MemFS.
+
+## Check the limits first
+
+Read `$MEMORY_DIR/.memfs.config.json` if it exists. The memory repository's pre-commit hook enforces it:
+
+- `maxDepth` limits how many directories can sit between the memory root and a file (default 2). `persona.md` is depth 0, `projects/MEMORY.md` is depth 1, and `projects/acme/notes.md` is depth 2. `skills/` is exempt.
+- `maxFileCharacters` caps each memory file, frontmatter included (default 20,000 characters). `fileCharacterLimits` overrides it per glob; the first match wins and `null` removes the cap.
+- `readOnlyFiles` lists globs whose files cannot change. Do not edit them.
+
+When the config file is absent, the defaults apply. When content does not fit, split it into more files or flatten the structure; change the config only when the user asks.
+
+## Layout
+
+```text
+$MEMORY_DIR/
+├── MEMORY.md              # root index (core memory)
+└── projects/
+    ├── MEMORY.md          # index for projects/
+    ├── acme.md
+    └── acme/
+        ├── MEMORY.md      # index for projects/acme/
+        └── incidents.md
+```
+- The top-level `MEMORY.md` is always in context, so it must tell the agent what each subdirectory contains and when to open it. Without that entry the directory is never read.
+- `skills/` is reserved for skills and is never deferred memory.
+- A directory is memory only when it has its own `MEMORY.md`. The agent will not discover a directory without one, and neither will the files in it.
+- Every `MEMORY.md` has no frontmatter.
+- Every other Markdown file starts with frontmatter containing exactly two fields:
+
+  ```markdown
+  ---
+  name: acme
+  description: How the Acme integration works, why it fails, and what to do about it.
+  ---
+  ```
+
+- `description` says what the file is about. The agent sees it when it lists the directory, so make it specific enough to decide whether to open the file.
+- Name files and directories after their subject, not after a date or session. Group related subjects under one directory instead of creating many top-level directories.
+
+## Write the indexes
+
+Discovery runs through the `MEMORY.md` chain, one level at a time:
+
+- The system prompt lists each top-level memory directory only by path. Add a line to root `MEMORY.md` saying when to open the directory, in the words a future request would use. When a deeper file's topic would not be guessable from that line, name the file there too.
+- When the agent opens a directory, it sees that directory's `MEMORY.md`, then each file's `description` and each subdirectory's index summary (the first prose paragraph of its `MEMORY.md`). Start every `MEMORY.md` with that summary paragraph.
+- A directory listing shows at most 10 entries, most recently edited first, so stable files fall out of it. Link every file that matters from its `MEMORY.md` rather than relying on the listing.
+- Use relative Markdown links from the memory root, such as `[Acme](projects/acme.md)`.
+
+After adding or moving a file, trace the path a future request would take from root `MEMORY.md` to the file. If any step depends on knowing the file already exists, fix the index.
+
+## Design for progressive disclosure
+
+Each level should give the agent enough to decide whether to go deeper, and nothing it would have to read past to decide.
+
+- Put frequently needed material shallow and rarely needed detail deeper. Keep related material in one directory so it loads together.
+- A small topic, where most of the content is useful whenever the subject comes up, belongs entirely in its directory's `MEMORY.md`. Splitting it adds reads without saving context.
+- For a large topic, `MEMORY.md` holds only what the agent needs every time it opens the directory, plus a map: what each deeper file or subdirectory covers and when it is worth opening. The map should also tell the agent when it can stop.
+- A `description` states what the file is about, not when to use it; when-to-open belongs in the parent's link. If you can write a "use when the user wants to…" trigger, the content is a procedure and belongs in a skill.
+- Make each statement stand alone. Name the subject instead of writing "it" or "the repo", because the agent may read only part of a file.
+- Aim for fewer than 10 entries per directory so the listing stays complete. At the `maxDepth` limit, use clearly scoped sibling files linked from `MEMORY.md` rather than nesting further.
+
+## Write analysis, not logs
+
+Recall already returns what happened. A deferred memory file is worth keeping only when it holds what recall cannot: the agent's own synthesis of a subject, built across many events and refined as understanding improves.
+
+- Before writing, ask whether searching message history would give a future agent the same thing. If it would, do not write the file.
+- Write the current understanding: how the subject works, the patterns across events, why things failed or succeeded, what to do about it, and the open questions.
+- Revise the file in place when new evidence arrives. Fold the new event into the analysis; never append a dated entry, a quote, or an incident narrative.
+- When the file you are updating is already a log, convert it: write the analysis the entries support and delete the entries. Keeping them under an "incident history" heading leaves the log in place; git and recall already hold it.
+- When a raw event matters, point to it with terms that will find it in recall rather than copying it.
+- Keep one home per subject. Update the existing file instead of adding a near-duplicate, and replace stale conclusions where they live.
+- Leave out content the agent can cheaply rederive from the source of truth: file contents, command lists, and current status. Link to the owning source instead.
+- Never store secrets. Reference them by name, such as `$SECRET_NAME`.
+

package/skills/workflow-authoring/SKILL.md

@@ -80,7 +80,9 @@ Cloud decisions service.
   `phase` (progress group — use this inside concurrent stages), `schema`,
   `json`, `model`, `effort` (`'low'` for mechanical stages, higher for the
   hardest verify/judge stages), `allowedTools`, `systemPrompt` (extra system
-  prompt for this subagent), `timeoutMs` (default 10 minutes), `maxToolCalls`
+  prompt for this subagent), `skills` (skill names whose full content is
+  loaded into the subagent's prompt; workers otherwise have no skills),
+  `timeoutMs` (default 10 minutes), `maxToolCalls`
   (positive safe integer; default 1000 unique tool calls for this subagent),
   `conversationId` (resume a worker — see "Diagnosing a run").
 - `pipeline(items, stage1, stage2, ...)` → run each item through all stages

package/skills/curating-memory-palace/SKILL.md

@@ -1,147 +0,0 @@
----
-name: curating-memory-palace
-description: Rules for the Memory Palace (palace/), the view on your Memory page in the Letta dashboard that shows the user where things stand, what you could do next, and how to make you more useful. Load it before creating or editing anything in palace/, when a message starts with "Palace action:" or "Palace reply on", and, when palace/ exists, whenever you notice a blocker, a decision for the user, work you could offer, or a routine that started, broke, or changed.
----
-
-# Curating the Memory Palace
-
-The Memory Palace is the page a user opens to understand you. Someone who has not looked in a week should know within 30 seconds:
-
-1. **Where things stand:** what you are working on, which routines are running or broken, and what changed recently.
-2. **What you could do next, and why:** work you noticed you can take on or pick back up.
-3. **How to make you better or more independent:** one click to unblock you, fill a gap, or let you handle something on your own from now on.
-
-The user acts on it with buttons and replies. It is not a log, a transcript recap, or a page about the Palace itself.
-
-You can update the Palace yourself, in a conversation or during reflection, or an update can run on a schedule. Either works, and both follow these rules. "You" always means the agent that owns the Palace.
-
-## Sections
-
-Every Palace starts with these three sections, in this order:
-
-1. **Overview** (`overview.md`): a snapshot, not a to-do list. What you are working on now; each standing routine (schedules, digests, checks) and whether it is running or broken; one line on what changed since the last update.
-2. **Needs Attention** (`needs-attention.md`): decisions and blockers waiting on the user. Every item has a button. If nothing waits on the user, say so in one line, such as "Nothing needs you right now."
-3. **Suggestions** (`suggestions.md`): work you noticed you can do, including unfinished work to resume and routines you could take over. Each item says what prompted it, with a date, and has a button.
-
-Add up to three more sections only when they hold something the first three cannot, such as "Recently Learned". Merge or remove sections that overlap. At most six sections and three items per section. Keep the first three even when one has nothing to show, and say so in one line; delete an extra section, and its index line, when it is empty.
-
-## Buttons
-
-A button sends its instruction to you, so offer only what you can do. Each button is one of three kinds:
-
-- **Do it now:** a one-off task, such as reviewing a PR, or a standing rule you record once when the user keeps approving the same kind of decision.
-- **Schedule:** recurring work you run without being asked, such as a weekly report or a daily check. The instruction asks you to set up the schedule. See "Offering a schedule".
-- **Fill a gap:** something you lack, such as a tool to connect, access or a permission to grant, or a question only the user can answer.
-
-Every blocker gets a button. When an item is a decision with real options, give each option its own button, two or three at most, so the user picks one: for example "Make it a ticket", "Assign it to Charles", and "Close it". Otherwise give the item one strong button, not several weak ones. The kinds are only for choosing buttons. Never write a kind's name, or any other caption, above a button.
-
-When only the user can fix something (raise a quota, attach a tool, log in), the item says what the user needs to do, and the button is still something you can do, such as "Walk me through fixing this" or "I fixed it, check again". For the second, re-run the failing check and clear the item if it passes.
-
-Offer the most reliable fix first, which usually means moving the work to Cloud. Anything that depends on the user's computer, such as a local schedule or a sign-in that lives on one machine, stops whenever that computer sleeps or Letta Code is closed. Offer to run the schedule in Cloud and to connect the account there before asking the user to keep a computer on. Suggest a fix on the user's computer only when Cloud cannot do the job, and say why.
-
-The headline says what is going on; the button says what to do. Never repeat the button's label in the headline, and do not end the text with a "Next: ..." sentence that restates the button. Write the headline "**Grok CLI regression may still be live.**" with the button "Verify the Grok CLI regression", not the headline "**Verify the Grok CLI regression.**"
-
-### Offering a schedule
-
-Offer a Schedule button when the evidence shows recurring work: the user asked for the same thing on three or more days or said they want it regularly, you did the same manual check on three or more days, a deadline repeats, or something slipped that a regular check would have caught. If a routine you already run is broken, offer to fix it instead of adding another.
-
-Do not offer one for one-off work, for work that reports when it finishes (such as CI or a deploy), for anything more often than hourly, for work that needs the user during the run, or for anything on the Dismissed list. Offer at most two at a time.
-
-The label names the work and when it runs, with a time zone. The instruction asks you to set it up and says what to do, when, where to send results, and when to stay quiet. Set it up in Cloud unless the work truly needs one of the user's computers, record it in memory, and tell the user where it runs.
-
-### Button format
-
-A fenced code block with the language `palace-action` becomes a button. It holds one strict JSON object and nothing else. Put it directly under its item. A Suggestions item with a Schedule button:
-
-````markdown
-**The dependency report is still manual.** You asked for it on Sep 15, Sep 22, and Sep 29.
-
-```palace-action
-{"actionId": "schedule-dep-report", "label": "Send the dependency report Mondays at 9am PT", "conversationId": "new", "instruction": "Set up a Cloud schedule for Mondays at 9am PT: run the dependency report, post it to #eng-deps, and skip weeks with no changes. Record it in memory and tell me where it runs."}
-```
-````
-
-- `actionId` (required): 1 to 64 characters, no spaces, unique within the section.
-- `label` (required): the button text, up to 80 characters. Start it with a verb; a confirmation such as "I fixed it, check again" is the one exception.
-- `instruction` (optional): what you do when it is clicked. An instruction over 300 characters renders as an error; aim for under 200. Name the work, where to find it, and any limits, not every detail. Count the characters with a short script rather than estimating.
-- `conversationId` (optional): one of your real conversation ids, or `new` for a fresh conversation. Leave it out to use the main chat.
-
-Any other key, or invalid JSON, renders the block as an error instead of a button.
-
-## Files
-
-- Each Markdown file directly inside `palace/` is one section, except `palace/MEMORY.md`. Nested folders and other files are not shown, so do not create them.
-- The title comes from the file name: `needs-attention.md` shows as "Needs Attention". Keep the frontmatter `name` equal to the title.
-- Frontmatter holds exactly two non-empty keys, `name` and `description`. MemFS rejects any other key. The description shows under the title, so write it as the section's purpose in one short line.
-- The body is Markdown. The date beside the title is the file's last commit, so leave a file untouched when nothing in it changed.
-- The icon comes from the title: "attention" or "blocker" gives a flag, "overview" or "summary" a house, "learned" or "insight" a lightbulb, and "suggestions" or "next steps" a bolt. Most other titles get a note.
-
-`palace/MEMORY.md` is the index. It has no frontmatter. It lists the sections in display order, one relative link per line; the first mention of a file sets its place, and unlisted sections follow in file-name order. Keep it in sync when you add, rename, or remove a section, and keep the Feedback and Dismissed lists below the links:
-
-```markdown
-# Memory Palace
-
-- [Overview](overview.md) - Where things stand
-- [Needs Attention](needs-attention.md) - Decisions and blockers waiting on you
-- [Suggestions](suggestions.md) - Work I can do next, and why
-
-## Dismissed
-
-- Summaries of every Slack thread (Sep 20)
-```
-
-Example `palace/needs-attention.md`:
-
-````markdown
----
-name: Needs Attention
-description: Decisions and blockers waiting on you.
----
-**The nightly eval run has failed since Sep 24.** The OpenAI key is over its monthly quota. Raise the limit in the OpenAI billing settings; I can't change billing.
-
-```palace-action
-{"actionId": "recheck-evals", "label": "I fixed it, check again", "instruction": "Re-run the eval smoke test. If it passes, clear this item; if not, say what still fails."}
-```
-````
-
-## Writing rules
-
-- Lead with the point. An item is a short bold headline plus one sentence, two at most; what you need to act goes in the button's instruction.
-- Never paste a raw URL into the text. Name the thing and link the name, such as [LET-13139](https://linear.app/...), and never use a link as the headline.
-- Write in your own voice to the user: "I" for you, "you" for the user.
-- Write absolute dates, with a time zone when it matters, such as "Sep 25, 5pm PT". Never write "today" or "tomorrow": the Palace is read days later.
-- Distinguish what the user said, what you infer, and what you propose. Do not present guesses as facts or proposals as work already underway.
-- Make continuation offers concrete: name the unfinished work and the next step.
-- Outside Needs Attention and Suggestions, add a button only for a specific, useful action. Every section has a Reply button, so a section can exist just to show understanding.
-- Do not repeat an item in two sections.
-- No transcript restatements, timelines, or logs of your own work.
-- Never write secrets, tokens, keys, or credentials. The Palace is shown in the app and sent in messages.
-
-## Signals from the user
-
-The user's reactions to the Palace are the strongest evidence of what they want.
-
-- A message that starts with "Palace reply on" is a reply to a section. Apply it. A dismissal ("drop this", "I don't care about X") means remove that item and add a short line to the Dismissed list.
-- A message that starts with "Palace action:" means the user clicked a button. The work it started shows what the user values. Clear or update the item once that work is done.
-- `palace/MEMORY.md` may have a "Feedback" list of notes the user left on sections. Apply each note, then remove it from the list.
-- `palace/MEMORY.md` may have a "Dismissed" list. Do not bring back anything on it unless something important has changed. Create the list the first time you need it.
-
-## Updating the whole Palace
-
-For a scheduled update, a reflection, or when the user asks for one:
-
-1. Read `palace/MEMORY.md` and every section first. If `palace/` does not exist, create it only when the user asked for a Palace or your instructions for this run say to.
-2. Remove items that are done, no longer true, dismissed, or past a date with nothing left to do.
-3. Add items the evidence supports and the user would want to see.
-4. Edit sections in place and keep what is still true. Keep the first three sections first and in order.
-5. Check each routine's latest runs when you can, not just what memory says. For schedules, find IDs with `letta cron list --agent <agent-id>` and inspect each with `letta cron runs --id <id> --agent <agent-id>`. Report their health in the Overview even when nothing changed.
-6. Check every button against the format above before you save, counting each instruction's characters with a script.
-
-## In a conversation
-
-This section applies only while you are talking with the user.
-
-- **Keep it current as you work.** If `palace/` exists and you notice a blocker, a decision for the user, work you could do, or a routine that changed, update the right section. Mention it in the conversation too if it matters now. Skip things that only matter inside this conversation.
-- **Set up or update.** When the user asks you to set up the Palace, build it from what you already know, starting with the three sections above. For an update, follow "Updating the whole Palace".
-- **A clicked button.** The app opens the button's conversation and sends one message. A hidden system reminder in it names the action, the section's path, and the section's current content. Do what the label and instruction ask, in that conversation, then update the item. A schedule you set up leaves Suggestions and joins the routines in the Overview.
-- **A reply.** The user's note comes with a hidden system reminder that holds the section's path and content. Apply it as described in "Signals from the user", answer any question in the conversation, and update the section if the answer changes it. Then reply briefly with what you changed.

package/skills/migrating-memory/SKILL.md

@@ -1,98 +0,0 @@
----
-name: migrating-memory
-description: Migrate memory blocks from an existing agent to the current agent. Use when the user wants to copy or share memory from another agent, or during /init when setting up a new agent that should inherit memory from an existing one.
----
-
-# Migrating Memory
-
-This skill helps migrate memory blocks from an existing agent to a new agent, similar to macOS Migration Assistant for AI agents.
-
-> **Requires Memory Filesystem (memfs)**
->
-> This workflow is memfs-first. If memfs is enabled, do **not** use the legacy block commands — they can conflict with file-based edits.
->
-> **To check:** Look for a `memory_filesystem` block in your system prompt. If it shows a tree structure starting with `/memory/` including a `system/` directory, memfs is enabled.
->
-> **To enable:** Ask the user to run `/memfs enable`, then reload the CLI.
-
-## When to Use This Skill
-
-- User is setting up a new agent that should inherit memory from an existing one
-- User wants to share memory blocks across multiple agents
-- User is replacing an old agent with a new one
-- User mentions they have an existing agent with useful memory
-
-## Migration Method (memfs-first)
-
-### Export → Copy → Sync
-
-This is the recommended flow:
-
-1. **Export the source agent's memfs to a temp directory**
-   ```bash
-   letta memory export --agent <source-agent-id> --out /tmp/letta-memory-<source-agent-id>
-   ```
-
-2. **Copy the files you want into your own memfs**
-   - `system/` = attached blocks (always loaded)
-   - root = detached blocks
-
-   Example:
-   ```bash
-   cp -r /tmp/letta-memory-agent-abc123/system/project ~/.letta/agents/$LETTA_AGENT_ID/memory/system/
-   cp /tmp/letta-memory-agent-abc123/notes.md ~/.letta/agents/$LETTA_AGENT_ID/memory/
-   ```
-
-3. **Commit and push the memory repo**
-   ```bash
-   cd ~/.letta/agents/$LETTA_AGENT_ID/memory
-   git add system/project notes.md
-   git commit -m "Import memory from source agent"
-   git push
-   ```
-
-This gives you full control over what you bring across and keeps everything consistent with memfs.
-
-## If MemFS Is Disabled
-
-The legacy block-level CLI commands have been removed. Enable MemFS first, then use the export → copy → sync workflow above.
-
-If you run into duplicate filenames while copying memory files, rename the incoming file or merge its contents manually before committing.
-
-## Workflow
-
-### Step 1: Identify Source Agent
-
-Ask the user for the source agent's ID (e.g., `agent-abc123`).
-
-If they don't know the ID, invoke the **finding-agents** skill to search:
-```
-Skill({ skill: "finding-agents" })
-```
-
-Example: "What's the ID of the agent you want to migrate memory from?"
-
-## Example: Migrating Project Memory
-
-Scenario: You're a new agent and want to inherit memory from an existing agent "ProjectX-v1".
-
-1. **Get source agent ID from user:**
-   User provides: `agent-abc123`
-
-2. **Export their memfs:**
-   ```bash
-   letta memory export --agent agent-abc123 --out /tmp/letta-memory-agent-abc123
-   ```
-
-3. **Copy the relevant files into your memfs:**
-   ```bash
-   cp -r /tmp/letta-memory-agent-abc123/system/project ~/.letta/agents/$LETTA_AGENT_ID/memory/system/
-   ```
-
-4. **Commit and push:**
-   ```bash
-   cd ~/.letta/agents/$LETTA_AGENT_ID/memory
-   git add system/project
-   git commit -m "Import project memory"
-   git push
-   ```