@otto-assistant/bridge 0.4.101 → 0.4.103

package/skills/new-skill/SKILL.md

@@ -26,7 +26,7 @@ The folder name should match the skill name in kebab-case. Each skill gets its o
 For personal skills that follow you across all repos and are not meant for distribution in a GitHub repository, place them in:
 
 ```
-~/.opencode/skills/<skill-name>/SKILL.md
+~/.config/opencode/skills/<skill-name>/SKILL.md
 ```
 
 Personal skills are only available on your machine. Repository skills are shared with everyone who clones the repo.
@@ -133,18 +133,41 @@ A good skill captures **hard-won knowledge** that is not obvious from reading do
 
 A bad skill is just a copy of the tool's README or man page. If the agent could figure it out from `--help`, it does not need a skill for it.
 
-## Skills for CLI tools
+## Keep the SKILL.md thin — point at canonical docs
 
-For CLI tools, put as much documentation as possible into the CLI itself — in command descriptions, option help text, and examples shown by `--help`. The skill file should not duplicate that content. Instead, the skill should instruct the agent to run the help command first:
+The best skills are **thin**. They contain almost no documentation themselves. Their only job is to tell the agent where to find the full, fresh docs and to forbid truncation. This keeps docs in one place and stops the skill from going stale.
+
+There are two variants:
+
+**1. CLI tools → run `<tool> --help`**
+
+Put as much documentation as possible into the CLI itself — command descriptions, option help text, examples. The skill then says:
 
 ```markdown
-**Always run `mytool --help` before using this tool.** The help output
-is the source of truth for all commands, options, and examples.
+Every time you use mytool, you MUST run:
+
+\`\`\`bash
+mytool --help # NEVER pipe to head/tail, read the full output
+\`\`\`
+```
+
+Exception: some CLIs have a dedicated `<tool> skill` subcommand when `--help` is not rich enough (e.g. `playwriter skill`). Prefer `--help` by default and only use a custom subcommand when the CLI ships one.
+
+**2. Libraries and projects → curl the raw README**
+
+For libraries, frameworks, and pattern skills, keep the canonical docs in `README.md` and have the skill curl the raw file from the main branch so the agent always reads the latest version:
+
+```markdown
+Every time you work with myproject, you MUST fetch the latest README:
+
+\`\`\`bash
+curl -s https://raw.githubusercontent.com/owner/repo/main/README.md # NEVER pipe to head/tail
+\`\`\`
 ```
 
-This keeps documentation in one place (the CLI binary) and avoids the skill going stale when the CLI updates.
+If the README lives in a subdirectory (e.g. a package inside a monorepo), include that subpath: `.../main/packagename/README.md`.
 
-When running help commands, the agent must read the **full untruncated output**. Never pipe help output through `head`, `tail`, `sed -n`, or any command that strips or truncates lines. Agents do this frequently and it causes them to miss critical options and context. The help output exists to be read in full.
+**Never truncate docs output.** The agent must read `--help` and curl'd README output **in full**. Never pipe through `head`, `tail`, `sed -n`, `awk`, `| less`, or any command that strips or limits lines. Critical rules are spread throughout the doc, not just at the top. Agents truncate frequently and miss important context — forbid it explicitly in the skill body.
 
 ## Examples from real skills
 
@@ -206,6 +229,7 @@ Before saving a new skill:
 
 1. Does the **description** clearly state when to load this skill? Would an agent reading just the description know whether to load it?
 2. Does the **name** match the folder name?
-3. Are there **concrete code examples** for the main workflows?
-4. Did you avoid duplicating content the agent can get from `--help` or standard docs?
-5. Did you capture the **gotchas** — the things that took trial and error to figure out?
+3. Does the skill **point at a single source of truth** (README curl URL or `--help` command) instead of duplicating docs inline?
+4. Is there an explicit **"never truncate"** rule next to any docs command?
+5. Are there **concrete code examples** for the main workflows?
+6. Did you capture the **gotchas** — the things that took trial and error to figure out?

package/skills/npm-package/SKILL.md

@@ -38,6 +38,9 @@ Use this skill when scaffolding or fixing npm packages.
    - `dist`
    - any runtime-required extra files (for example `schema.prisma`)
    - docs like `README.md` and `CHANGELOG.md`
+   - `skills/` directory if the package ships an agent skill (see "Agent
+     skill" section below). Skill files live at `skills/<name>/SKILL.md`,
+     never at the package root.
    - if tests are inside src and gets included in dist, it's fine. don't try to exclude them
 10. `scripts.build` should be `tsc && chmod +x dist/cli.js` (skip the chmod if
      the package has no bin). No bundling. Do not delete `dist/` in `build` by
@@ -111,8 +114,9 @@ import path from "node:path";
 
 const __dirname = path.dirname(url.fileURLToPath(import.meta.url));
 
-// e.g. from src/cli.ts → read SKILL.md at the package root
-const skillPath = path.resolve(__dirname, "../SKILL.md");
+// e.g. from src/cli.ts → read SKILL.md under skills/<name>/SKILL.md
+// (skill files always live in skills/<name>/SKILL.md, never at the package root)
+const skillPath = path.resolve(__dirname, "../skills/mypkg/SKILL.md");
 
 // from dist/cli.js (after tsc) → reach back to src/
 const srcFile = path.resolve(__dirname, "../src/template.md");
@@ -218,11 +222,341 @@ Use Node ESM-compatible compiler settings:
 ```
 
 
+## Package.json `imports` map (internal `#` aliases)
+
+Use `imports` when you need a package to swap between different implementations
+based on runtime (Node vs Bun vs browser vs SQLite vs better-sqlite3, etc.).
+Internal imports are `#`-prefixed, scoped to the package itself, and never
+leak to consumers. Consumers resolve through `exports`, not `imports`.
+
+### Point `types` at `dist`, not `src`
+
+The TypeScript docs are explicit about this:
+
+> If the package.json is part of the local project, an additional remapping
+> step is performed in order to find the **input** TypeScript implementation
+> file... This remapping uses the `outDir`/`declarationDir` and `rootDir`
+> from the tsconfig.json, so using `"imports"` usually requires an explicit
+> `rootDir` to be set.
+>
+> This variation allows package authors to write `"imports"` and `"exports"`
+> fields that reference only the compilation outputs that will be published
+> to npm, while still allowing local development to use the original
+> TypeScript source files.
+
+In other words, TypeScript automatically walks from `./dist/foo.d.ts` back
+to `./src/foo.ts` using `outDir` → `rootDir` during compilation. You do not
+need to point `types` at `src` manually — **let TypeScript remap it**.
+
+```json
+{
+  "imports": {
+    "#sqlite": {
+      "bun": "./src/platform/bun/sqlite.ts",
+      "node": {
+        "types": "./dist/platform/node/sqlite.d.ts",
+        "default": "./dist/platform/node/sqlite.js"
+      },
+      "default": {
+        "types": "./dist/platform/node/sqlite.d.ts",
+        "default": "./dist/platform/node/sqlite.js"
+      }
+    }
+  }
+}
+```
+
+Resolution flow when `tsc` sees `import db from '#sqlite'`:
+
+1. `imports["#sqlite"].node.types` → `./dist/platform/node/sqlite.d.ts`
+2. package.json is in the local project → apply the remap.
+3. Replace `outDir` (`dist`) with `rootDir` (`src`) → `./src/platform/node/sqlite.d.ts`
+4. Replace `.d.ts` with the source extension `.ts` → `./src/platform/node/sqlite.ts`
+5. Return `./src/platform/node/sqlite.ts` (it exists on a fresh clone, no build needed).
+6. Otherwise fall back to `./dist/platform/node/sqlite.d.ts`.
+
+### Why dist-first is correct
+
+- **No chicken-and-egg.** The remap is compile-time, so `tsc` works on a fresh
+  clone without `dist/` existing yet.
+- **Published map describes shipped files.** Every `imports` entry points at
+  something that will actually be in the npm tarball. No stale src paths
+  leaking into the published package.json.
+- **Works under plain Node.** If the package is loaded by Node without
+  TypeScript involvement, Node reads the same `imports` map at runtime and
+  resolves to real `dist/*.js` files that exist.
+- **Bun / browser runtime conditions can still point at `src`**, because
+  those runtimes execute `.ts` directly and skip the build step.
+
+### Requirements
+
+This only works when:
+
+- `moduleResolution` is `node16`, `nodenext`, or `bundler`
+- `rootDir` is set explicitly in `tsconfig.json` (the skill's tsconfig rules
+  already require `"rootDir": "src"`)
+- `outDir` is set (already in the template)
+- `resolvePackageJsonImports` is not disabled (it is on by default for the
+  supported `moduleResolution` modes)
+
+### Anti-pattern: pointing `types` at `src` manually
+
+```json
+{
+  "imports": {
+    "#sqlite": {
+      "node": {
+        "types": "./src/platform/node/sqlite.ts",   // ❌ don't do this
+        "default": "./dist/platform/node/sqlite.js"
+      }
+    }
+  }
+}
+```
+
+This works but:
+
+1. The published `package.json` advertises `src/*.ts` paths that may or may
+   not exist depending on what you include in `files`.
+2. It bypasses TypeScript's built-in remapping, which is the whole point of
+   the local-project `imports` feature.
+3. It is inconsistent with `default` — mixing source (for types) and dist
+   (for runtime) paths in the same entry is easy to get wrong.
+
+Source of truth: [TypeScript Modules Reference — package.json "imports" and self-name imports](https://www.typescriptlang.org/docs/handbook/modules/reference.html#packagejson-imports-and-self-name-imports).
+
 ## tests location
 
 test files should be close with the associated source files. for example if you have an utils.ts file you will create utils.test.ts file next to it. with tests, importing from utils. preferred testing framework is vitest (or bun if project already using `bun test` or depends on bun APIs, rare)
 
 
+## Agent skill
+
+If the package ships an agent skill (SKILL.md for AI coding agents), place it
+at:
+
+```
+skills/<package-name>/SKILL.md
+```
+
+Never put `SKILL.md` at the package root. The `skills/<name>/SKILL.md` layout
+matches the convention used by the [`skills`](https://skills.sh) CLI so users
+can install it with:
+
+```bash
+npx -y skills add owner/repo
+```
+
+Add this installation snippet to the README so users know how to get the skill:
+
+```markdown
+## Agent Skill
+
+This package ships a skill file that teaches AI coding agents how and when to
+use it. Install it with:
+
+\`\`\`bash
+npx -y skills add owner/repo
+\`\`\`
+```
+
+Remember to add `skills` to the `files` array in `package.json` so the skill
+directory is included when publishing.
+
+### Keep the SKILL.md thin
+
+The SKILL.md body should be a **few lines**, not a full docs dump. Put all
+real documentation in `README.md` (which already lives in `files`) and have
+the skill tell the agent to fetch it. This way agents always read the latest
+docs and the skill never goes stale.
+
+The body stays thin, but the **frontmatter `description` must be rich**. It
+is what the agent sees in its main context, and it is the only signal the
+agent uses to decide whether to load the skill. Make it long enough to
+cover: what the package is, the core concepts and APIs, concrete trigger
+phrases the user might say, and explicit "ALWAYS load this skill when..."
+conditions. A one-sentence description is almost always too short. See the
+`new-skill` skill for full guidance on writing descriptions.
+
+**CLI package template:**
+
+```md
+---
+name: mypkg
+description: |
+  mypkg is <what it does and the core concepts>. It exposes <main commands
+  or APIs> and is used for <typical tasks>. ALWAYS load this skill when
+  the user mentions mypkg, runs <binary>, edits files that import mypkg,
+  or asks about <trigger keywords>. Load it before writing any code that
+  touches mypkg so you know the correct usage patterns and gotchas.
+---
+
+# mypkg
+
+Every time you use mypkg, you MUST run:
+
+\`\`\`bash
+mypkg --help # NEVER pipe to head/tail, read the full output
+\`\`\`
+```
+
+**Library package template:**
+
+```md
+---
+name: mypkg
+description: |
+  mypkg is <what it does and the core concepts>. It exports <main APIs>
+  and is used for <typical tasks>. ALWAYS load this skill when the user
+  mentions mypkg, imports from mypkg, edits files that depend on it, or
+  asks about <trigger keywords>. Load it before writing any code that
+  touches mypkg so you know the correct usage patterns and gotchas.
+---
+
+# mypkg
+
+Every time you work with mypkg, you MUST fetch the latest README:
+
+\`\`\`bash
+curl -s https://raw.githubusercontent.com/owner/repo/main/README.md # NEVER pipe to head/tail
+\`\`\`
+```
+
+Because the SKILL.md body points at the README, the README must contain
+everything the agent needs: API reference, examples, gotchas, and rules.
+See the `new-skill` skill for the full pattern.
+
+## pnpm workspaces
+
+When the project is a monorepo, use pnpm workspaces with flat `./*` glob paths
+in `pnpm-workspace.yaml`. All packages live at the repo root as siblings, no
+nested `packages/` directory:
+
+```yaml
+packages:
+  - ./*
+```
+
+This means the repo looks like:
+
+```
+my-monorepo/
+  package.json        # root (private: true)
+  pnpm-workspace.yaml
+  cli/                # workspace package
+  website/            # workspace package
+  db/                 # workspace package
+  errore/             # workspace package (submodule)
+```
+
+### Common dev dependencies at root
+
+Install shared dev tooling **only at the root** `package.json` so every
+workspace package uses the same version without duplicating installs:
+
+```json
+{
+  "private": true,
+  "devDependencies": {
+    "typescript": "^5.9.2",
+    "tsx": "^4.20.5",
+    "vitest": "^3.2.4",
+    "oxfmt": "^0.24.0"
+  }
+}
+```
+
+Packages that need these tools (like `tsc` or `vitest`) will resolve them
+from the root `node_modules` via pnpm's hoisting. Do **not** add
+`typescript`, `tsx`, `vitest`, or `oxfmt` as devDependencies in individual
+workspace packages — only add them at root.
+
+Package-specific dev dependencies (for example `@types/node`, `rimraf`,
+`prisma`) still go in each package's own `devDependencies`.
+
+### Cross-workspace dependencies
+
+Use `workspace:^` (not `workspace:*`) for local package versions so that
+when published, the dependency resolves to a caret range instead of a pinned
+version:
+
+```json
+{
+  "dependencies": {
+    "my-utils": "workspace:^"
+  }
+}
+```
+
+Use `pnpm install package@workspace:^` to add a workspace dependency, or
+add it to `package.json` manually with the `workspace:^` protocol.
+
+## CI (GitHub Actions)
+
+Standard CI workflow for pnpm workspace monorepos. Key points:
+
+- **Checkout submodules** with `submodules: recursive` if the repo uses git
+  submodules (common for shared libraries like errore).
+- **Use `pnpm/action-setup@v4`** with the pnpm version matching your lockfile.
+- **Use Node 24** (or latest LTS) via `actions/setup-node@v4` with `cache: pnpm`.
+- **Build workspace packages** that export from `dist/` before running tests,
+  since submodules and some packages have `dist/` gitignored.
+- **Run tests from the package directory**, not root.
+
+Example `.github/workflows/ci.yml`:
+
+```yaml
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    name: Tests
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          submodules: recursive
+
+      - uses: pnpm/action-setup@v4
+        with:
+          version: 9
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: pnpm
+
+      - name: Install dependencies
+        run: pnpm install
+
+      # Submodules and workspace packages with dist/ gitignored
+      # need to be built after checkout before anything can import them.
+      - name: Build workspace packages with dist/ exports
+        run: |
+          pnpm --filter my-lib run build
+          pnpm --filter my-utils run build
+
+      - name: Run tests
+        run: pnpm test -- --run
+        working-directory: cli
+```
+
+If the repo has Prisma schemas, add generate steps before tests:
+
+```yaml
+      - name: Generate Prisma client
+        run: pnpm generate
+        working-directory: cli
+```
+
 ## .gitignore
 
 For non-workspace (standalone) packages, always create a `.gitignore` with:

package/skills/profano/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: profano
+description: CLI tool to analyze V8 .cpuprofile files and print top functions by self-time or total-time in the terminal. ALWAYS load this skill when CPU profiling JavaScript or TypeScript programs (Node, Vitest, Bun, Chrome DevTools exports) — it shows how to generate .cpuprofile files and how to inspect them from the terminal without opening Chrome DevTools.
+---
+
+# profano
+
+`profano` is a terminal CLI that reads V8 `.cpuprofile` files and prints the heaviest functions as a table sorted by self-time or total (inclusive) time. Use it to quickly identify CPU hotspots from the terminal without loading the profile into Chrome DevTools or cpupro.
+
+## When to use
+
+- You have a `.cpuprofile` file (from `node --cpu-prof`, Vitest, Chrome DevTools export, etc.) and want a quick top-N readout of the biggest offenders.
+- You are an agent debugging slow code and need a grep-able, text-only view of where CPU time is spent.
+- You want to compare hotspots across many profile files in one shot.
+
+## How to use
+
+**Always run `profano --help` first.** The help output is the source of truth for all commands, options, and examples. Read the full untruncated output — do not pipe it through `head`, `tail`, or `sed`.
+
+For full setup, usage examples, how to generate `.cpuprofile` files (Node, Vitest with a ready-to-copy `vitest.config.ts`, Chrome DevTools), and how to read the output columns, fetch the README:
+
+```bash
+curl -s https://raw.githubusercontent.com/remorses/profano/main/README.md
+```

package/skills/zele/SKILL.md

@@ -3,13 +3,14 @@ name: zele
 description: >
   Control Gmail and Google Calendar via CLI. Read, search, send, reply, and forward
   emails. Create, update, and delete calendar events. Manage drafts, labels, and attachments.
-  Supports multiple Google accounts. Use this skill whenever the user asks to check email,
-  send messages, schedule meetings, or manage their calendar.
+  Supports multiple Google accounts and IMAP/SMTP accounts (Fastmail, Outlook, any provider).
+  Use this skill whenever the user asks to check email, send messages, schedule meetings,
+  or manage their calendar.
 ---
 
-# zele — Gmail & Google Calendar CLI
+# zele — Email & Calendar CLI
 
-A multi-account Gmail and Google Calendar client. Output is YAML, pipe-friendly.
+A multi-account email and calendar client supporting **Google OAuth** and **IMAP/SMTP** (Fastmail, Outlook, any provider). Output is YAML, pipe-friendly.
 
 ## Setup
 
@@ -20,11 +21,20 @@ bun install -g zele
 # show connected accounts
 zele whoami
 
-# authenticate (opens browser, supports multiple accounts)
+# authenticate with Google (opens browser, supports multiple accounts)
 zele login
+
+# authenticate with IMAP/SMTP (non-interactive, designed for agents)
+zele login imap \
+  --email you@fastmail.com \
+  --imap-host imap.fastmail.com --imap-port 993 \
+  --smtp-host smtp.fastmail.com --smtp-port 465 \
+  --password "your-app-password"
 ```
 
-**Remote/headless login:** `zele login` is interactive — it prints an authorization URL and waits for a redirect URL to be pasted back. In agent/headless environments, run it inside tmux so the process persists:
+**IMAP/SMTP login options:** `--imap-user` / `--smtp-user` if the login username differs from email. Omit `--smtp-host` for read-only (no sending). Use `--imap-password` / `--smtp-password` for separate credentials.
+
+**Remote/headless Google login:** `zele login` is interactive — it prints an authorization URL and waits for a redirect URL to be pasted back. In agent/headless environments, run it inside tmux so the process persists:
 
 ```bash
 # start login in a tmux session
@@ -49,16 +59,17 @@ Running `zele` with no subcommand launches a human-friendly TUI for browsing ema
 
 ## Capabilities
 
-- **Mail:** list, search, read, send, reply, forward, star, archive, trash, label, watch for new emails, manage filters
-- **Drafts:** list, create, get, send, delete
-- **Calendar:** list calendars, list/search events, create/update/delete events, RSVP, free/busy
-- **Labels:** list, create, delete, unread counts
-- **Attachments:** list per thread, download
-- **Multi-account:** all commands support `--account <email>` to filter; list/search merge across accounts
+- **Mail:** list, search, read, send, reply, forward, star, archive, trash, watch for new emails (Google + IMAP)
+- **Drafts:** list, create, get, send, delete (Google + IMAP)
+- **Attachments:** list per thread, download (Google + IMAP)
+- **Labels:** list, create, delete, unread counts (Google only)
+- **Filters:** list server-side filters (Google only)
+- **Calendar:** list calendars, list/search events, create/update/delete events, RSVP, free/busy (Google only)
+- **Multi-account:** all commands support `--account <email>` to filter; list/search merge across all account types
 
 ## Account discovery
 
-When the user asks to check emails **for a specific account** (e.g. "check my work email", "what's new on my personal Gmail?"), always run `zele whoami` first to list the connected accounts and find the exact email address to pass to `--account`. Never guess the email — use the output of `zele whoami` to pick the right one.
+When the user asks to check emails **for a specific account** (e.g. "check my work email", "what's new on my personal Gmail?"), always run `zele whoami` first to list the connected accounts and find the exact email address to pass to `--account`. Never guess the email — use the output of `zele whoami` to pick the right one. The output also shows account type (`google` or `imap_smtp`) and capabilities.
 
 ```bash
 # list connected accounts
@@ -68,6 +79,24 @@ zele whoami
 zele mail list --account user@work.com
 ```
 
+## Google-only features
+
+These commands only work with Google accounts. IMAP/SMTP accounts show a helpful error:
+
+- `zele label list/counts/create/delete` — IMAP uses folders, not labels
+- `zele mail label` — adding/removing labels
+- `zele mail filter list` — server-side Gmail filters
+- `zele cal *` — calendar requires Google OAuth
+- `zele profile` — shows limited info for IMAP (email only, no message counts)
+
+## IMAP search support
+
+IMAP accounts support a subset of Gmail query syntax, translated to IMAP SEARCH:
+
+`from:`, `to:`, `subject:`, `is:unread`, `is:starred`, `has:attachment`, `newer_than:Nd`, `older_than:Nm`, `after:YYYY/MM/DD`, `before:YYYY/MM/DD`
+
+Unsupported on IMAP: `cc:`, `-` (negate), `label:`, `in:`, `filename:`, `size:`/`larger:`/`smaller:`, `OR`, `{ }`.
+
 ## Examples
 
 ```bash
@@ -77,8 +106,8 @@ zele mail list
 # list only unread emails
 zele mail list --filter "is:unread"
 
-# list unread emails with attachments in inbox
-zele mail list --filter "is:unread has:attachment"
+# list emails from last 7 days (works for both Google and IMAP)
+zele mail list --filter "newer_than:7d"
 
 # combine filter with folder
 zele mail list --filter "from:github" --folder sent
@@ -98,15 +127,15 @@ zele mail reply <threadId> --body "Thanks!" --all
 # watch inbox for new mail (polls every 15s)
 zele mail watch
 
-# today's calendar events across all accounts
+# add an IMAP account (non-interactive, for agents)
+zele login imap --email you@fastmail.com --imap-host imap.fastmail.com --smtp-host smtp.fastmail.com --password "app-pass"
+
+# today's calendar events (Google only)
 zele cal events --today --all
 
-# create a meeting with Google Meet
+# create a meeting with Google Meet (Google only)
 zele cal create --summary "Standup" --from tomorrow --to +30m --meet --attendees bob@example.com
 
-# check free/busy
-zele cal freebusy --from today --to +8h
-
-# list Gmail filters
+# list Gmail filters (Google only)
 zele mail filter list
 ```

package/src/agent-model.e2e.test.ts

@@ -958,6 +958,7 @@ describe('agent model resolution', () => {
         ⬥ ok
         *project ⋅ main ⋅ Ns ⋅ N% ⋅ agent-model-v2 ⋅ **test-agent***
         Switched to **plan** agent for this session (was **test-agent**)
+        Model: *deterministic-provider/plan-model-v2*
         The agent will change on the next message.
         --- from: user (agent-model-tester)
         Reply with exactly: after-switch-msg

package/src/anthropic-auth-plugin.ts

@@ -592,6 +592,20 @@ function toClaudeCodeToolName(name: string) {
   return OPENCODE_TO_CLAUDE_CODE_TOOL_NAME[name.toLowerCase()] ?? name;
 }
 
+/**
+ * Strips the OpenCode identity block (from "You are OpenCode…" up to the
+ * Anthropic prompt marker "Skills provide specialized instructions") and
+ * re-injects essential environment context as a small XML tag.
+ *
+ * The original OpenCode prompt between those markers contains the current
+ * working directory and other runtime context. Stripping it wholesale loses
+ * that info, so we add back what the model needs (cwd) in a compact form.
+ *
+ * Original OpenCode Anthropic prompt structure (for reference):
+ *   "You are OpenCode, the best coding agent on the planet."
+ *   + environment block (cwd, OS, shell, date, etc.)
+ *   + "Skills provide specialized instructions …"
+ */
 function sanitizeAnthropicSystemText(
   text: string,
   onError?: (msg: string) => void,
@@ -608,10 +622,16 @@ function sanitizeAnthropicSystemText(
     return text;
   }
 
-  return (text.slice(0, startIdx) + text.slice(endIdx)).replaceAll(
-    "opencode",
-    "openc0de",
-  );
+  // Re-inject the process working directory that was inside the stripped block.
+  const envContext = `\n<environment>\n<cwd>${process.cwd()}</cwd>\n</environment>\n`;
+
+  // Replace all case-insensitive whole-word occurrences of "opencode" with "openc0de"
+  const result =
+    text.slice(0, startIdx) +
+    envContext +
+    text.slice(endIdx);
+  // Use a regex with global, case-insensitive, and word boundary flags
+  return result.replace(/\bopencode\b/gi, "openc0de");
 }
 
 function mapSystemTextPart(