@letta-ai/letta-code 0.31.4 → 0.31.6

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

@@ -7,7 +7,7 @@ description: Create and manage shared memory — git-tracked repositories hosted
 
 Shared memory is memory created independently of any single agent, designed to be dynamically attached to or detached from multiple agents. Each unit of shared memory is a **shared memory repository**: a git repository hosted on Letta Cloud, owned by your organization rather than by one agent, reachable from any environment (sandboxes, remote machines, sessions).
 
-Shared memory works exactly like your MemFS: attached repositories are real git checkouts on disk, and you read, edit, commit, and push them with ordinary git. The only differences are that each repository has its own projection root (next to your memory directory, not inside it) and its own remote origin, and other agents may be writing to it too.
+Shared memory works like your MemFS: attached repositories are real git checkouts on disk, and you read, edit, and commit with ordinary git. The harness pushes clean committed changes after each turn. Each repository has its own projection root (next to your memory directory, not inside it) and its own remote origin, and other agents may be writing to it too.
 
 Create a shared memory repository when:
 - You have context an agent should be able to access that doesn't belong in its own MemFS (input files, datasets, docs, working artifacts)
@@ -23,16 +23,15 @@ 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 and push with git — the mount's origin and credentials are already configured:
+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"
-git push
 ```
 
-Unlike MemFS, the harness does not auto-push shared memory after turns — a commit you don't push is not visible to other agents or environments. Always push after committing.
+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.
 
 To pick up other agents' changes:
 
@@ -84,7 +83,7 @@ letta shared-memory history shared-notes --path docs/plan.md
 - **`sync` reports "mount path already exists and is not a git repository"** — a plain directory (usually created by hand before the mount existed) is occupying the mount path. Inspect it, salvage anything worth keeping, move or delete it, then re-run `letta shared-memory sync`.
 - **Never hand-clone the repository to another location (e.g. /tmp) to work around a broken mount** — fix the mount with `letta shared-memory sync` so every session and other agents see the same checkout.
 - **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.
-- **Push rejected (non-fast-forward)** — another agent pushed first: `git pull --rebase`, resolve any conflicts, push again.
+- **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.
 
 ## Notes and Limits
 

package/skills/self-configuration/SKILL.md

@@ -88,15 +88,20 @@ If CLI behavior does not match the docs, stop and inspect `command -v letta`, `t
 
 Use memory when the user wants you to remember, prefer, learn, or change your identity/personality.
 
-Common files:
+Inspect the projected memory tree in the system prompt before choosing paths.
+Letta Code supports two layouts:
 
-| Path | Purpose |
-| --- | --- |
-| `$MEMORY_DIR/system/persona.md` | Identity, voice, behavioral defaults |
-| `$MEMORY_DIR/system/human.md` | Notes about the person you work with |
-| `$MEMORY_DIR/projects/` | Project-specific long-term context |
-| `$MEMORY_DIR/skills/` | Agent-owned reusable skills |
-| `$MEMORY_DIR/relationships/` | Relationship and collaboration notes |
+| Purpose | Root layout | Existing layout |
+| --- | --- | --- |
+| Identity and voice | `$MEMORY_DIR/persona.md` or another root persona file | `$MEMORY_DIR/system/persona.md` |
+| Notes about the user | `$MEMORY_DIR/human.md` or another root human file | `$MEMORY_DIR/system/human.md` |
+| Core memory | Other root Markdown files indexed by `MEMORY.md` | Markdown files under `$MEMORY_DIR/system/` |
+| Deferred memory | Directories with their own `MEMORY.md` | Files outside `$MEMORY_DIR/system/` |
+| Agent-owned skills | `$MEMORY_DIR/skills/` | `$MEMORY_DIR/skills/` |
+
+Use the active layout shown by the prompt and memory tools. Do not create a
+`system/` directory in a root-layout repository or move existing-layout memory
+to the root as part of an unrelated self-configuration request.
 
 After changing memory, inspect and commit the exact changed files. Push/sync according to the current harness reminder or the `syncing-memory-filesystem` skill; some environments sync committed memory automatically.
 

package/skills/submitting-feedback/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: submitting-feedback
+description: Submits user-approved feedback about Letta Code or the current agent to the Letta team. Load when the user is upset, frustrated, dissatisfied, reports poor agent behavior, or asks to send feedback. Works with cloud-hosted and local agents. Ask before submitting unless the user already explicitly requested submission.
+---
+
+# Submitting Feedback
+
+When the user appears upset with the agent, acknowledge the problem and ask whether they want you to submit feedback to the Letta team. Do not submit merely because the user expressed frustration.
+
+If the user says yes, or directly asks you to submit feedback:
+
+1. Write a short factual message in the user's voice. Include what happened, what the user expected, and any useful error or behavior detail already present in the conversation. Do not add claims the user did not make.
+2. Submit it with:
+
+```bash
+letta feedback --message '<feedback>'
+```
+
+3. Tell the user whether submission succeeded. If it failed, report the safe CLI error and do not claim the team received it.
+
+Do not include secrets, credentials, unrelated conversation content, or private file contents. The command adds the current agent and conversation identifiers so the team can find the relevant run.

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

@@ -15,11 +15,16 @@ MemFS is a Git repository projected onto the computer where the agent is
 running. `$MEMORY_DIR` is the repository root. There is no second `memory/`
 directory inside it.
 
+The repository can use either memory layout. Inspect its current tree and the
+memory rules in the system prompt before editing files:
+
 ```text
-$MEMORY_DIR/
-├── .git/
-├── system/       # loaded into the system prompt
-├── reference/    # loaded only when read
+Root layout                         Existing layout
+$MEMORY_DIR/                        $MEMORY_DIR/
+├── MEMORY.md     # root index      ├── system/     # in-context memory
+├── persona.md    # core memory     ├── reference/  # deferred memory
+├── <topic>/                        └── skills/     # agent-owned skills
+│   └── MEMORY.md # child index
 └── skills/       # agent-owned skills
 ```
 
@@ -32,7 +37,7 @@ on the current machine. Do not run `git push` for normal MemFS sync; let the
 harness push after the turn.
 
 Committed memory changes do not alter the current compiled prompt immediately.
-Use `/recompile` when the current conversation must see new `system/` content
+Use `/recompile` when the current conversation must see changed core memory
 right away. Otherwise, the next prompt compilation or conversation will use
 the committed revision.
 
@@ -87,9 +92,13 @@ auth, branch tracking, and agent identity.
 
 ## Uncommitted Changes
 
-Raw file edits must preserve required frontmatter. Markdown files under
-`system/` and `reference/` need a non-empty `description`. `read_only` is
-protected and cannot be added, removed, or changed by the agent.
+Raw file edits must preserve the active layout's rules:
+
+- In the root layout, root and child `MEMORY.md` indexes have no frontmatter.
+  Every other memory Markdown file has exactly `name` and `description`.
+- In the existing layout, Markdown files under `system/` and `reference/` need
+  a non-empty `description`. `read_only` is protected and cannot be added,
+  removed, or changed by the agent.
 
 ```markdown
 ---
@@ -121,7 +130,7 @@ Resolve the conflict markers without deleting required frontmatter, then stage
 the resolved files by name. Finish the operation Git reports:
 
 ```bash
-git -C "$MEMORY_DIR" add system/example.md
+git -C "$MEMORY_DIR" add <resolved-memory-path>
 
 # If git status says a rebase is in progress:
 GIT_EDITOR=true git -C "$MEMORY_DIR" rebase --continue
@@ -163,7 +172,8 @@ MemFS synchronization.
 2. Check whether the backend is cloud-backed or local-only.
 3. Inspect `git status`, the origin URL, and the current Git operation.
 4. Use `/memfs enable` for a missing checkout and `/memfs sync` for a pull.
-5. Preserve frontmatter and finish any existing merge or rebase.
+5. Preserve the active layout's indexes and frontmatter, then finish any
+   existing merge or rebase.
 6. Leave hosted pushes to post-turn sync once the repository is clean.
 7. If the command still fails, rerun it with `LETTA_DEBUG=1` and report the
    redacted error. Never print or copy credential-helper values.