# Core: a tighter default system prompt, a reply-language rule, and a shared tooling directory

The built-in Agent template is re-read by the model on every turn, and had grown wordy in exactly the sections that repeat most. It loses about a tenth of its words (1087 → 969) with no rule going with them, and two behaviours the prompt never stated are now in it.

## What the trim changed

Personality pins the reply language to the user's own — the tool schema already demanded that of every call description, so the two agreed in practice while only one of them said so. It scopes to prose: code, identifiers and commit messages keep their own conventions. The process/port constraint collapses from two sentences into one, with the same guarantees: don't kill what you didn't start (PenguinHarness's own services included) unless asked, don't take a service port, pick another free port when the one you want is busy.

API auth handling stops being split across two sections. Constraints carried "retry at most once" and Stop rules carried a fourth rule for what to do afterwards; it is now stated once, as the special case of the existing "an error you cannot resolve" rule — retry at most once, then stop calling tools and ask the user to update the key in the Agent's vault or the model settings outside the chat. The facts that made the old wording long are intact: the secret is never pasted into the conversation, and a new key only takes effect in the next conversation, so further retries cannot succeed.

System markers lose about half their words while keeping all four markers and their instructions. File system goes from eight bullets to seven and 262 words to 243: two merges — the workspace-relative-path convention into the `CWD` bullet, another agent's state into the description of your own — against one bullet gained for shared tooling. Suggested workflows already recommended dispatching independent subtasks in parallel; it now says out loud that this is the fast way through a large task. Its Playwright/curl line folds into the Tool use bullet, which keeps both halves the two lines used to carry separately: prefer Playwright when it is installed, otherwise `curl`.

## Tooling installs once

File system gains a convention, and the Skills section loses the "There is no skill tool" filler that explained an absence. It sits in File system rather than Skills because it governs any task that installs a tool, not only a skill run, and it is written as the choice the model actually faces: install into the project's own environment when it has one; otherwise keep the reusable ones — Python virtualenvs, model and package caches — under `<app_data_dir>/agents/<agent_id>/shared_env/<name>/` and reuse them across Sessions.

Node is called out separately, with pnpm preferred **in the project itself** — both halves matter. Its shared store keeps repeated installs from duplicating on disk, and the location is what keeps the install resolvable: `node_modules` resolves from the project upward, so a package placed under the agent directory would be invisible to code running in `CWD`.

`shared_env/` is a prompt-level convention, not a path the code creates: `paths.ts` is untouched, and Agent State snapshots still package `agent_state/` alone, so a virtualenv can never bloat an export. The data-layout tree in the Sessions & Traces documentation lists the directory with that caveat spelled out, and the per-Agent layout in `01-PRINCIPLES.md` records it too.

## The App Data Dir bullet stops contradicting itself

The same section's App Data Dir bullet said the directory "is NOT the task's directory" and that deliverables must never be left there. A temporary Workspace is `<app_data_dir>/agents/<agent_id>/workspaces/tmp-<8hex>` — inside that very tree, and `CWD` for any task that is given one — so the rule broke exactly where it was needed. It now carries the input rule alone (the App Data Dir's contents were not supplied by the user and are never task input) and says plainly that `CWD` may sit inside the tree, that one folder being the task's and the rest not. Where deliverables go was already stated positively by the scratchpad bullet below it, which holds wherever `CWD` points.

## Existing Agents

Nothing migrates and nothing is rewritten. An Agent always runs with its on-disk `agent_state/system_config.yaml` verbatim, so this reaches **newly created** Agents only. An existing Agent adopts it through the settings page's *Restore default configuration* action, which overwrites the whole configuration — custom system prompt, tool list, model and compaction settings, MCP Servers — keeping only `name`, `description` and `version`.
