@letta-ai/letta-code 0.34.32 → 0.34.33

package/letta.js

@@ -6044,7 +6044,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "@letta-ai/letta-code",
-    version: "0.34.32",
+    version: "0.34.33",
     lettaStartupLogProtocol: 1,
     lettaConfigDirProtocol: 1,
     description: "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",
@@ -211630,7 +211630,7 @@ var init_mcp_client = __esm(() => {
   init_streamableHttp();
   DEFAULT_CLIENT_INFO = {
     name: "letta-code",
-    version: "0.34.32"
+    version: "0.34.33"
   };
 });
 
@@ -244586,7 +244586,7 @@ class CodexAppServerClient {
     await this.request("initialize", {
       clientInfo: {
         name: "letta-code",
-        version: "0.34.32"
+        version: "0.34.33"
       },
       capabilities: null
     });
@@ -454275,12 +454275,12 @@ function rowToolCalls(row, index, diagnostics2) {
   }
   return calls;
 }
-function contentText2(content) {
+function contentText3(content) {
   if (typeof content === "string") {
     if (content.startsWith(CONTENT_JSON_PREFIX)) {
       const encoded = content.slice(CONTENT_JSON_PREFIX.length);
       try {
-        return contentText2(JSON.parse(encoded));
+        return contentText3(JSON.parse(encoded));
       } catch {
         return encoded;
       }
@@ -454366,7 +454366,7 @@ var init_hermes = __esm(() => {
           });
         };
         if (row.role === "user") {
-          const content = contentText2(row.content);
+          const content = contentText3(row.content);
           if (content) {
             emit({
               type: "message",
@@ -454386,7 +454386,7 @@ var init_hermes = __esm(() => {
               ...timestamp ? { timestamp } : {}
             });
           }
-          const content = contentText2(row.content);
+          const content = contentText3(row.content);
           if (content) {
             emit({
               type: "message",
@@ -454409,7 +454409,7 @@ var init_hermes = __esm(() => {
         if (row.role === "tool") {
           emit({
             type: "tool_result",
-            content: contentText2(row.content),
+            content: contentText3(row.content),
             ...typeof row.tool_call_id === "string" && row.tool_call_id ? { callId: row.tool_call_id } : {},
             ...timestamp ? { timestamp } : {}
           });
@@ -539260,4 +539260,4 @@ function registerBunOAuthFlows() {
 registerBunOAuthFlows();
 await init_src5().then(() => exports_src2);
 
-//# debugId=856A9C1BADE9BA4D64756E2164756E21
+//# debugId=DC6442E21D1E98A964756E2164756E21

package/npm-shrinkwrap.json

@@ -1,6 +1,6 @@
 {
   "name": "@letta-ai/letta-code",
-  "version": "0.34.32",
+  "version": "0.34.33",
   "lockfileVersion": 3,
   "packages": {
     "node_modules/@alcalzone/ansi-tokenize": {
@@ -5633,7 +5633,7 @@
     },
     "": {
       "name": "@letta-ai/letta-code",
-      "version": "0.34.32",
+      "version": "0.34.33",
       "dependencies": {
         "@cursor/sdk": "1.1.0",
         "@earendil-works/pi-ai": "^0.99.1",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@letta-ai/letta-code",
-  "version": "0.34.32",
+  "version": "0.34.33",
   "lettaStartupLogProtocol": 1,
   "lettaConfigDirProtocol": 1,
   "description": "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",

package/skills/context-doctor/references/auditing-memory.md

@@ -64,9 +64,12 @@ Moving detail behind a link changes when it reaches the model. Keep essential
 instructions and cues for when to retrieve that detail in core memory; a link
 alone does not preserve their in-context effect.
 
-Review the diff and validate changed file structure and links. Follow the
-ordinary memory commit/sync workflow; doctor has no separate worktree or
-completion-time integration step. If there are no supported fixes, make no commit.
+Review the diff and validate changed file structure and links. Commit with the
+*Commit memory changes* format from `maintaining-core-memory` or
+`maintaining-deferred-memory`: one commit per repair, citing the conversations,
+message IDs, and files that support it under `Sources:`.
+Doctor has no separate worktree or completion-time integration step. If there
+are no supported fixes, make no commit.
 
 After a repair, recheck the original structural or content defect and any
 affected links or indexes.

package/skills/creating-skills/SKILL.md

@@ -332,7 +332,7 @@ Write instructions for using the skill and its bundled resources.
 
 ### Step 5: Packaging a Skill
 
-Package the skill only when it needs to be distributed as a file, for example when sharing it with a user. Skills maintained in place, such as those under an agent's memory `skills/` directory, are used directly and need no packaging.
+Package the skill only when it needs to be distributed as a file, for example when sharing it with a user. Skills maintained in place, such as those under an agent's memory `skills/` directory, are used directly and need no packaging. Commit them instead, following [Commit memory changes](#commit-memory-changes).
 
 To package a skill into a distributable .skill file, run the packaging script. The packaging process automatically validates the skill first to ensure it meets all requirements:
 
@@ -369,3 +369,24 @@ Improve a skill when real usage shows it falling short, whether through user fee
 2. Notice struggles or inefficiencies
 3. Identify how SKILL.md or bundled resources should be updated
 4. Implement changes and test again
+
+## Commit memory changes
+
+Every memory commit must let someone reading `git log` or `git blame` on a memory or skill line trace back to the events that justified it. Commit each learning separately; a learning may touch several files. When a turn produces several learnings, finish and commit one before editing for the next. From the repository root, stage only that learning's files and commit in one shell call:
+
+```bash
+git add <changed files> && git commit -m "memory(<origin>): <what was learned>
+
+<what happened: the events that led to this learning and why it should persist>
+
+Sources:
+- <conversation ID> (<message IDs>), <who>, <date>: <what happened there>"
+```
+
+- `<origin>` is `self` when you edit your own memory during a conversation, or `dream` when you are a reflection or dream subagent reviewing past transcripts.
+- Provenance belongs in the commit, not the memory file: who said or did it (name and ID), when, the quote, and the incident go in the body and `Sources:`. The memory line states only the resulting rule or fact. For example, the file says "Be concise" and the commit says "feedback 'talk more concisely' from Charles <id> on <date>". Git dates the commit, not the event, so write the event date.
+- The subject states the learning itself, such as `memory(self): Sarah wants one commit per learning`, not the file edit.
+- The body tells the story: what the user said or corrected, what failed or succeeded, or what pattern recurred, and why it generalizes beyond that moment. A reader should understand why the memory exists without opening the sources.
+- `Sources:` lists the evidence precisely enough to find again, with one line on what happened at each: a conversation ID with the message IDs where it happened, a transcript or session ID, a file path, a URL, PR, or issue, or a commit hash. When the user explicitly asked for the change, cite that request. Resolve values such as `$CONVERSATION_ID` before writing them; never commit a literal variable name.
+- Do not invent a source. If the origin cannot be identified, write `Sources: unknown` and say why in the body.
+- Never include secrets.

package/skills/initializing-memory/SKILL.md

@@ -47,7 +47,7 @@ Working with the maintainer of orchard, a CLI for build fleets.
 Repo conventions live in `AGENTS.md` and its nested guides; read them there.
 
 Where the rest of what I know lives:
-- [orchard](orchard/MEMORY.md) — architecture, gotchas, and correction history to consult when working there
+- [orchard](orchard/MEMORY.md) — architecture, gotchas, and recurring corrections to consult when working there
 ```
 
 An index pointing at nothing is worse than the content it displaced.
@@ -71,10 +71,10 @@ human.md                   # The person: role, motivations, how they work
 orchard/
 ├── MEMORY.md              # Index for the deferred orchard notes
 ├── architecture.md        # How the subsystems actually fit together
-├── gotchas.md             # Footguns, with the evidence behind each
+├── gotchas.md             # Footguns and why each one bites
 └── history/
     ├── MEMORY.md          # Required — every directory level needs its own index
-    └── corrections.md     # Correction loops with session ids and quotes
+    └── corrections.md     # Recurring corrections as rules; quotes and session ids go in the commits
 ```
 
 `orchard/history/` needs its own `MEMORY.md` purely because it is a directory level. An agent with no child directories at all would be equally correct.
@@ -169,9 +169,9 @@ It reports sessions analyzed, unread, excluded, export errors, and any dropped f
 
 **Provenance gates promotion here too**, not only in the subagent — a worker's authorship flag must survive curation, because flagged excerpts still read like preferences. Before promoting any claim about what the human wants, check who wrote the quoted words; agent-authored dispatch prompts describe how an *agent* was instructed to work. If it is ambiguous, corroborate from a session you know the human drove, or store it as an observed pattern with the uncertainty stated. Repetition does not establish authorship: a template reused across fifty sessions repeats fifty times.
 
-**Combine, then deduplicate.** Cohorts report the same topic at different specificity. Keep the unique details from each — quotes, paths, correction counts — and sum correction counts across cohorts, since a correction seen in five cohorts is a chronic failure. Keep the specific form alongside the general: "Use factory methods, such as `create_token_counter()`, not direct instantiation" beats "prefers factory methods". Then keep each fact exactly once, and push what you don't need every turn into deferred memory with a discovery link from the core tier.
+**Combine, then deduplicate.** Cohorts report the same topic at different specificity. Keep the unique details from each — paths, correction counts — and sum correction counts across cohorts, since a correction seen in five cohorts is a chronic failure. Keep the specific form alongside the general: "Use factory methods, such as `create_token_counter()`, not direct instantiation" beats "prefers factory methods". Then keep each fact exactly once, and push what you don't need every turn into deferred memory with a discovery link from the core tier.
 
-**Promote into canonical memory.** Write the survivors into the files their topics belong in, with supporting evidence deferred. Cover all three of identity and personality, hard rules and preferences with the quotes behind them, and project context; skip generic repo facts unless they change how you execute. If the output reads generically, the analysis failed for that area — re-read those transcripts or that code yourself. Keep stable `sessionId`s beside significant findings; `/tmp` results and journals are scratch, not retrievable evidence.
+**Promote into canonical memory.** Write the survivors into the files their topics belong in, as rules and facts. Cover all three of identity and personality, hard rules and preferences, and project context; skip generic repo facts unless they change how you execute. If the output reads generically, the analysis failed for that area — re-read those transcripts or that code yourself. Put the quotes and stable `sessionId`s behind each finding in its commit, not the memory file; `/tmp` results and journals are scratch, not retrievable evidence.
 
 **Consider skills.** If the history surfaces genuinely repeatable multi-step procedures, create them now (load `creating-skills`) or note the candidates in memory. Don't force it.
 
@@ -187,15 +187,10 @@ It reports sessions analyzed, unread, excluded, export errors, and any dropped f
 ### 10. Commit, then report
 **Uncommitted memory is not part of your future system prompt.** If a commit is blocked, report initialization as incomplete rather than describing working-tree files as live memory.
 
-```bash
-cd $MEMORY_DIR
-git status                # Review what changed before staging
-git add <specific files>  # Stage targeted paths — avoid blind `git add -A`
-author_name="${AGENT_NAME:-$AGENT_ID}"
-git commit --author="$author_name <$AGENT_ID@letta.com>" -m "feat(init): <summary> ✨
-
-<what was initialized and key decisions made>"
+Review `git status`, then commit with [Commit memory changes](#commit-memory-changes), adding `--author="${AGENT_NAME:-$AGENT_ID} <$AGENT_ID@letta.com>"`. Commit each topic you wrote (identity, preferences, a project) separately, and list the repositories, files, and `sessionId`s its findings came from under `Sources:`. Then confirm the result:
 
+```bash
+cd "$MEMORY_DIR"
 git status                        # Your memory changes should no longer be listed
 git ls-tree -r --name-only HEAD   # What your future self will actually load
 ```
@@ -204,6 +199,27 @@ Do **not** run `git push`. The harness pushes clean committed memory automatical
 
 Only once the commit is verified, tell the user what you built and whether coverage was complete, then ask whether they want refinement — which means another commit, so repeat this step.
 
+## Commit memory changes
+
+Every memory commit must let someone reading `git log` or `git blame` on a memory or skill line trace back to the events that justified it. Commit each learning separately; a learning may touch several files. When a turn produces several learnings, finish and commit one before editing for the next. From the repository root, stage only that learning's files and commit in one shell call:
+
+```bash
+git add <changed files> && git commit -m "memory(<origin>): <what was learned>
+
+<what happened: the events that led to this learning and why it should persist>
+
+Sources:
+- <conversation ID> (<message IDs>), <who>, <date>: <what happened there>"
+```
+
+- `<origin>` is `self` when you edit your own memory during a conversation, or `dream` when you are a reflection or dream subagent reviewing past transcripts.
+- Provenance belongs in the commit, not the memory file: who said or did it (name and ID), when, the quote, and the incident go in the body and `Sources:`. The memory line states only the resulting rule or fact. For example, the file says "Be concise" and the commit says "feedback 'talk more concisely' from Charles <id> on <date>". Git dates the commit, not the event, so write the event date.
+- The subject states the learning itself, such as `memory(self): Sarah wants one commit per learning`, not the file edit.
+- The body tells the story: what the user said or corrected, what failed or succeeded, or what pattern recurred, and why it generalizes beyond that moment. A reader should understand why the memory exists without opening the sources.
+- `Sources:` lists the evidence precisely enough to find again, with one line on what happened at each: a conversation ID with the message IDs where it happened, a transcript or session ID, a file path, a URL, PR, or issue, or a commit hash. When the user explicitly asked for the change, cite that request. Resolve values such as `$CONVERSATION_ID` before writing them; never commit a literal variable name.
+- Do not invent a source. If the origin cannot be identified, write `Sources: unknown` and say why in the body.
+- Never include secrets.
+
 ## Critical
 - **Use parallel tool calls wherever possible** — read many files in one turn, write many memory files in one turn.
 - **Write findings to memory as you go**; don't hold everything until the end.

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

@@ -61,7 +61,7 @@ Core memory is the agent's working model: who it is, how the user thinks and wha
 - 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.
+- 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 and where the learning came from. 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.
@@ -99,3 +99,24 @@ 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.
+
+## Commit memory changes
+
+Every memory commit must let someone reading `git log` or `git blame` on a memory or skill line trace back to the events that justified it. Commit each learning separately; a learning may touch several files. When a turn produces several learnings, finish and commit one before editing for the next. From the repository root, stage only that learning's files and commit in one shell call:
+
+```bash
+git add <changed files> && git commit -m "memory(<origin>): <what was learned>
+
+<what happened: the events that led to this learning and why it should persist>
+
+Sources:
+- <conversation ID> (<message IDs>), <who>, <date>: <what happened there>"
+```
+
+- `<origin>` is `self` when you edit your own memory during a conversation, or `dream` when you are a reflection or dream subagent reviewing past transcripts.
+- Provenance belongs in the commit, not the memory file: who said or did it (name and ID), when, the quote, and the incident go in the body and `Sources:`. The memory line states only the resulting rule or fact. For example, the file says "Be concise" and the commit says "feedback 'talk more concisely' from Charles <id> on <date>". Git dates the commit, not the event, so write the event date.
+- The subject states the learning itself, such as `memory(self): Sarah wants one commit per learning`, not the file edit.
+- The body tells the story: what the user said or corrected, what failed or succeeded, or what pattern recurred, and why it generalizes beyond that moment. A reader should understand why the memory exists without opening the sources.
+- `Sources:` lists the evidence precisely enough to find again, with one line on what happened at each: a conversation ID with the message IDs where it happened, a transcript or session ID, a file path, a URL, PR, or issue, or a commit hash. When the user explicitly asked for the change, cite that request. Resolve values such as `$CONVERSATION_ID` before writing them; never commit a literal variable name.
+- Do not invent a source. If the origin cannot be identified, write `Sources: unknown` and say why in the body.
+- Never include secrets.

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

@@ -7,7 +7,7 @@ Deferred memory contains the agent's knowledge. Use deferred memory for understa
 
 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.
+- Justifications, reasons, or sources for updating memory. These belong in the commit message; see [Commit memory changes](#commit-memory-changes).
 
 ## Check the limits first
 
@@ -77,10 +77,30 @@ Recall already returns what happened. A deferred memory file is worth keeping on
 
 - 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.
+- 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; the commit carries the event.
 - 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`.
 
+## Commit memory changes
+
+Every memory commit must let someone reading `git log` or `git blame` on a memory or skill line trace back to the events that justified it. Commit each learning separately; a learning may touch several files. When a turn produces several learnings, finish and commit one before editing for the next. From the repository root, stage only that learning's files and commit in one shell call:
+
+```bash
+git add <changed files> && git commit -m "memory(<origin>): <what was learned>
+
+<what happened: the events that led to this learning and why it should persist>
+
+Sources:
+- <conversation ID> (<message IDs>), <who>, <date>: <what happened there>"
+```
+
+- `<origin>` is `self` when you edit your own memory during a conversation, or `dream` when you are a reflection or dream subagent reviewing past transcripts.
+- Provenance belongs in the commit, not the memory file: who said or did it (name and ID), when, the quote, and the incident go in the body and `Sources:`. The memory line states only the resulting rule or fact. For example, the file says "Be concise" and the commit says "feedback 'talk more concisely' from Charles <id> on <date>". Git dates the commit, not the event, so write the event date.
+- The subject states the learning itself, such as `memory(self): Sarah wants one commit per learning`, not the file edit.
+- The body tells the story: what the user said or corrected, what failed or succeeded, or what pattern recurred, and why it generalizes beyond that moment. A reader should understand why the memory exists without opening the sources.
+- `Sources:` lists the evidence precisely enough to find again, with one line on what happened at each: a conversation ID with the message IDs where it happened, a transcript or session ID, a file path, a URL, PR, or issue, or a commit hash. When the user explicitly asked for the change, cite that request. Resolve values such as `$CONVERSATION_ID` before writing them; never commit a literal variable name.
+- Do not invent a source. If the origin cannot be identified, write `Sources: unknown` and say why in the body.
+- Never include secrets.

package/skills/managing-shared-memory/SKILL.md

@@ -23,13 +23,7 @@ ls "$MEMORY_DIR/../"                      # attached repositories appear here by
 cat "$MEMORY_DIR/../<repo-name>/<path>"   # read like any file
 ```
 
-Edit files with your normal file tools, then commit with git. The mount's origin and credentials are already configured:
-
-```bash
-cd "$MEMORY_DIR/../<repo-name>"
-git add <files>
-git commit -m "describe the change"
-```
+Edit files with your normal file tools, then commit from the mount (`cd "$MEMORY_DIR/../<repo-name>"`) using [Commit memory changes](#commit-memory-changes). The mount's origin and credentials are already configured. Other agents read this history, so the sources matter as much as in your own memory.
 
 The harness pushes clean commits from read/write attached repositories after the turn. If a push collides with another agent's work, it pulls with rebase and retries once. Dirty files and conflicts are not changed automatically; the harness adds a reminder to the next turn instead.
 
@@ -85,6 +79,27 @@ letta shared-memory history shared-notes --path docs/plan.md
 - **Permission denied under another agent's directory** — shared repositories mount per-agent. Only your own mount (under your agent directory) is accessible; another agent's mount of the same repository is walled off by the cross-agent guard. Run `letta shared-memory sync` to get your own mount.
 - **Shared-memory conflict reminder** — resolve the conflict in the named repository, finish the rebase or commit, and leave the repository clean. The harness retries the push after a future turn.
 
+## Commit memory changes
+
+Every memory commit must let someone reading `git log` or `git blame` on a memory or skill line trace back to the events that justified it. Commit each learning separately; a learning may touch several files. When a turn produces several learnings, finish and commit one before editing for the next. From the repository root, stage only that learning's files and commit in one shell call:
+
+```bash
+git add <changed files> && git commit -m "memory(<origin>): <what was learned>
+
+<what happened: the events that led to this learning and why it should persist>
+
+Sources:
+- <conversation ID> (<message IDs>), <who>, <date>: <what happened there>"
+```
+
+- `<origin>` is `self` when you edit your own memory during a conversation, or `dream` when you are a reflection or dream subagent reviewing past transcripts.
+- Provenance belongs in the commit, not the memory file: who said or did it (name and ID), when, the quote, and the incident go in the body and `Sources:`. The memory line states only the resulting rule or fact. For example, the file says "Be concise" and the commit says "feedback 'talk more concisely' from Charles <id> on <date>". Git dates the commit, not the event, so write the event date.
+- The subject states the learning itself, such as `memory(self): Sarah wants one commit per learning`, not the file edit.
+- The body tells the story: what the user said or corrected, what failed or succeeded, or what pattern recurred, and why it generalizes beyond that moment. A reader should understand why the memory exists without opening the sources.
+- `Sources:` lists the evidence precisely enough to find again, with one line on what happened at each: a conversation ID with the message IDs where it happened, a transcript or session ID, a file path, a URL, PR, or issue, or a commit hash. When the user explicitly asked for the change, cite that request. Resolve values such as `$CONVERSATION_ID` before writing them; never commit a literal variable name.
+- Do not invent a source. If the origin cannot be identified, write `Sources: unknown` and say why in the body.
+- Never include secrets.
+
 ## Notes and Limits
 
 - Shared memory is not part of your system prompt. Writing to it does not change your in-context memory — for that, edit your memory blocks or MemFS files.

package/skills/syncing-memory-filesystem/SKILL.md

@@ -5,7 +5,7 @@ description: Diagnose and repair MemFS repository setup, remote sync, authentica
 
 # MemFS Repository Repair
 
-Use this skill when the Git repository behind an agent's memory is not setting up or syncing correctly. Before editing memory, load the relevant skills: `maintaining-core-memory` for root/core files, `maintaining-deferred-memory` for deferred files, and `creating-skills` for skills. Then make the edit directly with ordinary file tools so the agent with the context applies the memory guidance. Stage only changed files by explicit path and commit in the same shell call. Verify the repair before reporting success. While the harness reports a repair in progress, leave memory files and Git state to that repair worker, which edits `$MEMORY_DIR` in place.
+Use this skill when the Git repository behind an agent's memory is not setting up or syncing correctly. Before editing memory, load the relevant skills: `maintaining-core-memory` for root/core files, `maintaining-deferred-memory` for deferred files, and `creating-skills` for skills. Then make the edit directly with ordinary file tools so the agent with the context applies the memory guidance. Stage only changed files by explicit path and commit in the same shell call, using the commit format in their *Commit memory changes* section. Verify the repair before reporting success. While the harness reports a repair in progress, leave memory files and Git state to that repair worker, which edits `$MEMORY_DIR` in place.
 
 ## Current Model