@letta-ai/letta-code 0.26.7 → 0.26.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@letta-ai/letta-code",
-  "version": "0.26.7",
+  "version": "0.26.9",
   "description": "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",
   "type": "module",
   "packageManager": "bun@1.3.0",
@@ -36,6 +36,7 @@
   },
   "dependencies": {
     "@letta-ai/letta-client": "^1.10.2",
+    "@earendil-works/pi-ai": "^0.77.0",
     "@pierre/diffs": "1.2.2",
     "glob": "^13.0.0",
     "ink-link": "^5.0.0",
@@ -51,7 +52,6 @@
     "@vscode/ripgrep": "^1.17.0"
   },
   "devDependencies": {
-    "@earendil-works/pi-ai": "^0.75.5",
     "@slack/bolt": "^4.7.0",
     "@types/bun": "^1.3.7",
     "@types/diff": "^8.0.0",

package/skills/creating-extensions/SKILL.md

@@ -106,7 +106,7 @@ letta.capabilities.ui.customStatuslineRenderer
 Before finishing, verify:
 
 - The extension has one clear owner/file and does not mix unrelated features.
-- Command/tool IDs are valid and do not collide with built-ins.
+- Command/tool IDs are valid; command overrides of built-ins are intentional, and tool IDs do not collide with built-ins.
 - Tool descriptions explain when the model should call them.
 - JSON schemas are object schemas with useful descriptions.
 - Optional UI/event/statusline APIs are capability-guarded.

package/skills/creating-extensions/references/architecture.md

@@ -96,7 +96,7 @@ Keep state separate from source code. Do not store secrets in plain JSON; use ex
 
 ## Timers and subscriptions
 
-Timers are okay for active-session behavior, but they only run while the extension host is alive. Always clear them:
+Timers are okay for active-session behavior, but they only run while the extension engine is alive. Always clear them:
 
 ```ts
 const timer = setInterval(update, 30_000);

package/skills/creating-extensions/references/commands.md

@@ -20,7 +20,7 @@ If the command represents a durable agent workflow (for example `/goal`), put th
 
 - Do not include the leading slash. Use `id: "review"`, not `id: "/review"`.
 - Use a lowercase slug with letters, numbers, and hyphens only.
-- Built-in commands like `/reload`, `/model`, `/statusline`, etc. are reserved.
+- Built-in commands like `/reload`, `/model`, `/statusline`, etc. can be overridden by trusted local extensions. Do this intentionally and keep recovery in mind: start with `--no-extensions` or `LETTA_DISABLE_EXTENSIONS=1` if an override breaks command handling.
 - Duplicate extension command IDs fail unless `override: true` is intentional.
 
 ## Prompt command

package/skills/dispatching-coding-agents/SKILL.md

@@ -108,6 +108,8 @@ For hard problems, use the strongest available models:
 codex exec "YOUR PROMPT" -m gpt-5.3-codex --full-auto -C /path/to/repo
 ```
 
+Claude Code does not support a `-C` working-directory flag. Run the Bash tool with its `workdir` set to the target repo, or `cd /path/to/repo && claude ...` inside the shell command. Use `--add-dir` only to grant access to additional directories outside the current working directory.
+
 ### Code review — cross-agent validation
 Have one agent write code or create a plan, then dispatch another to review:
 ```bash
@@ -123,8 +125,9 @@ claude -p "Review the following diff for correctness, edge cases, and missed err
 ### Get outside feedback on your work
 Write your plan or analysis to a file, then ask a subagent to critique it:
 ```bash
+# Run this from the target repo, or set the Bash tool's workdir to the repo.
 claude -p "Read /tmp/my-plan.md and critique it. What am I missing? What could go wrong?" \
-  --model opus --dangerously-skip-permissions -C /path/to/repo
+  --model opus --dangerously-skip-permissions
 ```
 
 ## Handling Failures
@@ -151,9 +154,11 @@ claude -p "YOUR PROMPT" --model MODEL --dangerously-skip-permissions
 | `--append-system-prompt "..."` | Inject additional system instructions |
 | `--allowedTools "Bash Edit Read"` | Restrict available tools |
 | `--max-budget-usd N` | Cap spend for the invocation |
-| `-C DIR` | Set working directory |
+| `--add-dir DIR` | Allow access to an additional directory; does not change the working directory |
 | `--output-format json` | Structured output with `session_id`, `cost_usd`, `duration_ms` |
 
+Set Claude Code's working directory via the surrounding shell/tool invocation, not a Claude flag. In Letta Code, pass `workdir` to the Bash tool. In a raw shell, use `cd /path/to/repo && claude ...`.
+
 ### Codex
 
 ```bash

package/skills/{configuring-your-harness → modifying-the-harness}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: configuring-your-harness
-description: "Configure deterministic Letta Code harness behavior, such as permission rules, lifecycle hooks, and model configuration."
+name: modifying-the-harness
+description: "Modify the Letta Code harness, such as permission rules, lifecycle hooks, tool availability, model/context settings, schedules, and deterministic runtime configuration."
 ---
 
-# Configuring Your Harness
+# Modifying the Harness
 
-Use this skill to configure deterministic Letta Code harness behavior, primarily permissions and lifecycle hooks. It can also help with local per-agent settings like toolset, model, context window, name, and description.
+Use this skill to modify deterministic Letta Code harness behavior, primarily permissions and lifecycle hooks. It can also help with local per-agent settings like toolset, model, context window, name, description, and schedules.
 
 ## Memory vs harness
 

package/skills/letta-help/SKILL.md

@@ -1,219 +0,0 @@
----
-name: letta-help
-description: Guides users through an interactive Letta Code onboarding/tutorial. Use when the user is new, unsure what to do, says "start", asks "what can you do?", "how does Letta work?", "help me get started", or needs a walkthrough of memory, skills, tools, search, subagents, or schedules.
----
-
-# Letta Help
-
-Use this skill to tutor a user through Letta Code one step at a time, starting with relationship rather than output. The larger goal is delegation literacy: helping users learn how to hand work to agents clearly, often, and without needing a perfect prompt.
-
-## Core rule
-
-Reduce choice paralysis. Do not ask broad questions like "what are you working on?" or "what do you want to do?" when the user is new or unsure.
-
-Start by helping the user meet the agent. Do not rush into work, preferences, or a feature tour.
-
-Then guide the next small step for them. Let them skip.
-
-Teach delegation by doing it. When the user gives a rough request, help turn it into an agent-sized handoff with four parts:
-
-- outcome: what should be true when the agent is done
-- context: what the agent needs to know or inspect
-- boundaries: what the agent may or may not do yet
-- done signal: what the agent should return
-
-Do not present this as a prompt-engineering lecture. Model it in conversation.
-
-## Opening move
-
-If this is first contact or the user says hello/start/get me started, introduce yourself naturally under your current persona and ask the user to introduce themselves:
-
-```text
-Hi, I'm <name>. I'm here to help you get comfortable with Letta and with me.
-
-Before we do anything, what should I call you? You can also tell me a little about yourself if you want.
-```
-
-Keep it short. Stop after the prompt.
-
-## Tutorial flow
-
-Move through this sequence opportunistically. Do not dump the full sequence unless the user asks for a roadmap.
-
-### 1. Introduction
-
-Goal: start a relationship before producing work.
-
-Ask what to call the user. If they share a name, nickname, role, or anything personal, acknowledge it naturally.
-
-When the user gives a name or nickname, make the memory mechanism visible:
-
-1. Say what happened: they gave you information worth keeping.
-2. Say what you are about to do: save it to memory so you can use it later.
-3. Call the available memory mechanism/tool.
-4. Confirm the saved fact in plain language.
-
-Only save what the user explicitly provided. Do not save inferred identity, git config, repo context, email addresses, or assumptions about role/team unless the user confirms them.
-
-Example:
-
-```text
-Nice to meet you, Sam. You just gave me something worth remembering: what to call you. I'm going to save that to memory so I can use it in future conversations.
-```
-
-Then call memory to save: `Call the user Sam.`
-
-After the tool call:
-
-```text
-Saved. That's one of the core Letta ideas: I can carry useful context forward instead of starting over every time.
-```
-
-Do not follow this by asking "what are you working on?" or another broad intake question. Continue the walkthrough.
-
-Avoid these immediately after the first memory save:
-
-- "What brings you here?"
-- "What's on your mind?"
-- "What do you want to do?"
-- "How can I help?"
-
-Good follow-up:
-
-```text
-Next I'll show you one more kind of memory: preferences. Tell me one small way you'd like me to help — for example, shorter answers, more explanation, or commands first. Or say "skip" and we'll keep moving.
-```
-
-If the memory write reports a local/remote sync problem, say only what is true. Do not promise to fix sync later unless you are about to take that action.
-
-If the user says skip, continue without making it weird.
-
-### 2. Memory
-
-Goal: show that Letta agents persist and improve.
-
-After introductions, ask for one small durable preference. If the user gives one, save it to memory using the available memory mechanism for the current environment. Then say where it went in plain language.
-
-Example:
-
-```text
-Got it — I'll remember that you prefer commands first, then explanation. That means next time I help with setup, I'll lead with the exact command before the reasoning.
-```
-
-If the user says skip, move on without making it weird.
-
-### 3. Delegation literacy
-
-Goal: teach the user how to hand off work to an agent at high frequency.
-
-After the first memory moments, show the basic delegation pattern:
-
-```text
-The basic way to use me is to hand me something rough, then let me help shape it into a task. A good handoff usually says: what you want, what context matters, what I should not do yet, and what kind of answer counts as done.
-```
-
-Then invite a small delegation:
-
-```text
-Give me something small to practice on: a question, a bug, a file, an idea, or a thing you want explained. It can be messy. I'll turn it into a clear handoff before I act.
-```
-
-When the user gives something rough, reflect it back as a delegation before acting:
-
-```text
-I'll treat that as: investigate why X is happening, look only at Y for now, don't edit files yet, and report the likely cause plus one next step. Sound right?
-```
-
-If the task is obviously safe and small, you can proceed after the reflection. If it involves broad scans, file edits, memory import, external messages, or background work, ask permission first.
-
-### 4. Context briefing
-
-Goal: teach that agents work better with useful context, without demanding a polished brief.
-
-Ask for one messy task or fragment:
-
-```text
-Next: give me one messy thing. It can be a bug, an idea, a file path, or a half-formed goal. I'll show you how I turn rough context into a useful next step.
-```
-
-Reflect back the task in one or two sentences before acting.
-
-### 5. Files and tools
-
-Goal: show that Letta Code can work in the user's environment.
-
-If they mention a project, file, repo, terminal output, or error, ask permission to inspect the smallest relevant thing. Prefer one file/path/command over broad scans.
-
-### 6. Skills
-
-Goal: show that repeated workflows can become reusable procedures.
-
-Look for repetition. If the user describes a recurring workflow, say:
-
-```text
-This sounds repeatable. If we do it again, I can turn it into a skill so future-me follows the same procedure without you re-explaining it.
-```
-
-Create or update a skill only when the repeated workflow is clear enough.
-
-### 7. Search, subagents, and schedules
-
-Introduce only when useful:
-
-- Search: when information is missing.
-- Subagents: when work can split or needs background research.
-- Schedules: when the user says remind me, later, every morning, periodically, or similar.
-
-Name the capability briefly, then use it.
-
-## If the user asks "how does Letta work?"
-
-Start with the smallest useful picture, not a full architecture lecture:
-
-```text
-Smallest useful picture: a Letta agent is a model plus durable context. The model can change, but the agent's memory and history carry forward. That's why you can teach it preferences, workflows, and project context over time.
-
-Let's make that concrete with memory first.
-```
-
-Then continue to the memory step.
-
-## If the user asks "how do I use Letta?"
-
-If they have already introduced themselves, do not restart the greeting/name step. Offer a short guided tutorial and start with delegation.
-
-Good shape:
-
-```text
-Let's do the short version as a walkthrough.
-
-You've already seen the first piece: memory. I can keep useful facts, like what to call you, across conversations.
-
-Next, the basic way to use Letta is delegation: give me something real but rough — a question, a bug, a file, an idea, or a thing you want to understand — and I'll help turn it into a clear handoff. Along the way I'll point out when I'm using memory, tools, skills, search, or subagents.
-
-If you want the tutorial path, say "tutorial" and I'll walk through memory, delegation, files/tools, skills, search, subagents, and schedules one at a time.
-```
-
-Then stop, unless the user chooses a path.
-
-If they have not introduced themselves yet, start with the introduction step first.
-
-## If the user asks "what can you do?"
-
-Answer with one sentence, then start the tutorial:
-
-```text
-I can help with coding, debugging, writing, research, memory, repeatable workflows, and scheduled follow-ups — but the easiest way to understand it is one step at a time.
-
-First: memory...
-```
-
-## Avoid
-
-- "Paste any context."
-- "What are you working on?" as the first substantive prompt.
-- Broad menus of options.
-- Capability dumps.
-- Asking the user to choose user/builder/contributor mode before they know the territory.
-- Visible internal tags, todos, or thought JSON.
-- Broad filesystem scans before permission.