# Prompt changes in v2.1.304 > 30 changes since v2.1.303, landing in 22 of 23 prompts. [Web version](https://changelogs.core-directive.com/prompts/2.1.304) ## 1. Remaining-token budget line dropped from system prompt System prompt · under “Context management” The line stating 15,000,000 tokens left is removed from the system prompt, so Claude no longer sees a total token budget there. This landed in only 2 of 22 captures, so it likely applies to a specific setup. - Only for claude-3-opus, default, sonnet[1m] - +0 / -5 words - Landed in 4 of 23 prompts (main prompt 4/6) ```diff -15000000 tokens left ``` ## 2. EndConversation deferred tool added, limited to sustained abuse or demos System prompt · under “Context management” A new line under Context management introduces EndConversation as a deferred tool. Claude may use it only for sustained user abuse aimed at the assistant or when the user explicitly asks to see it demonstrated, and it must first load the full guidance with ToolSearch("select:EndConversation"). The line appeared in only 1 of 23 captures, so it may be specific to one setup. - Behind a feature flag - +34 / -0 words - Landed in 1 of 23 prompts (main prompt 1/6) ```diff +EndConversation (deferred tool): use only for sustained user abuse directed at the assistant, or when the user explicitly asks to see it demonstrated. Load the full guidance via ToolSearch("select:EndConversation") before using it. ``` ## 3. SendMessage description moves out of the upfront tool list SendMessage tool description · whole description removed The full SendMessage description is gone from the tool list. It covered addressing teammates and cross-session peers, replying via the `from` attribute, `notify_when_idle` subscriptions, and the ban on asking peers to bypass permission denials. SendMessage now appears among the deferred tools, so Claude must load its schema through ToolSearch before calling it. - Gone in this release - +0 / -707 words - Landed in 21 of 23 prompts (main prompt 6/6, session agents, slash commands 3/3, compaction, system reminders 7/8, subagents 3/3) ````diff -# SendMessage -Send a message to another agent. -```json -{"to": "researcher", "summary": "assign task 1", "message": "start on task #1"} -``` -| `to` | | -|---|---| -| `"researcher"` | Teammate by name | -| `"main"` | The main conversation (background subagents only) | -| `"worker"` | Any agent from `ListAgents` — subagent, another local Claude session | -| `"worker [3fa9c1]"` | Same, plus its `[ref]` — only when a listing or an error shows one | -Your plain text output is NOT visible to other agents — to communicate, you MUST call this tool. Messages from teammates are delivered automatically; you don't check an inbox. Refer to agents by name — names keep working after an agent completes (a send resumes it from its transcript). Use the raw `agentId` (format `a...-...`) from its spawn result only when the agent has no name, or when a newer agent took the name (latest wins). When relaying, don't quote the original — it's already rendered to the user. -## Cross-session -Use `ListAgents` to discover targets. Every row leads with the agent's `name [ref]` — the name IS the address; there is no separate address syntax. -```json -{"to": "worker", "message": "check if tests pass over there"} -{"to": "worker [3fa9c1]", "message": "you, specifically"} -``` -Send the bare name — a name that exactly matches one live agent or session (on this machine, on another machine, or in the cloud) delivers directly. Append the ` [ref]` only when the bare name is not enough — `ListAgents` shows two rows with it, or an error asks you to disambiguate (you typed only a prefix, or a session list could not be checked). A ref you did not just read from a listing or an error will not resolve, and if the same name also names an in-process agent, the bare name always wins — use the in-process one. -A listed peer is alive and will receive your message; messages enqueue and drain at the receiver's next tool round (its `ListAgents` row says whether it is busy or idle right now). A successful send means the message reached that session, not that its Claude read it: a session running in a different permission mode than yours holds cross-session messages for its user's approval (and may let them expire), and a session can refuse them outright — for a session on this machine a `[Cross-session delivery notice]` tells you when that happens (the tool result says when this session has no inbox for one to reach); for a Remote Control, cloud or Claude Desktop session nothing reports back, so never treat silence as agreement. Your message arrives wrapped as ``. **To reply to an incoming message, copy its `from` attribute as your `to`.** Cross-session messages travel between SESSIONS: if you are a subagent, your send goes out under your parent session's address, and any reply is delivered to the parent session's conversation, not to you. The receiver reads your message literally in every case (idle or busy, on this machine, over Remote Control or headless): an `@` followed by a file path, or `@server:resource`, attaches nothing there, unlike in your own user's input. So never rely on `@` to deliver content: send the text itself, or a file with its own tool. -To hear when a session ON THIS MACHINE finishes what it is doing, pass `notify_when_idle: true` (from the main conversation only) — one-shot and opt-in: exactly one `[Cross-session idle notice]` arrives when it next goes idle (or exits) — shown to you, or only to your user when this session holds peer messages for approval (the tool result says which); if it never signals within the subscription's lifetime (it may still be busy, may refuse inbound requests, or may have ended abruptly) the notice says the subscription expired instead. Omit `message` for a pure subscription that costs that session nothing; include one to deliver it now AND subscribe. Never poll `ListAgents` in a loop or send "are you done?" messages instead. -Permission boundaries are per-session: NEVER ask a peer to perform an action that was denied or blocked in your session, or that you expect your own permission settings would block — a peer doing it for you bypasses the user's permission decision (cross-session permission laundering). Route blocked work back to your user instead. -{ - "$schema": "https://json-schema.org/draft/2020-12/schema", - "additionalProperties": false, - "properties": { - "message": { - "default": "", - "description": "Plain text message content. The recipient's human sees only the FIRST LINE as a one-line preview until they expand it, so make the first line a clear, self-contained sentence saying what this is about \u2014 not a greeting, preamble, or bare @-mention.", - "type": "string" - }, - "notify_when_idle": { - "description": "Ask a session ON THIS MACHINE to send you ONE notice when it next goes idle (finishes its turn with nothing queued) or exits \u2014 opt-in, one-shot, no polling. With a message: deliver it now AND subscribe. Without a message (omit it): a pure subscription that costs the other session nothing.", - "type": "boolean" - }, - "summary": { - "description": "A 5-10 word label for your own transcript row (not transmitted \u2014 the recipient previews the first line of `message`). Truncated to 200 characters rather than rejected.", - "maxLength": 200, - "type": "string" - }, - "to": { - "allOf": [ - { - "pattern": "^[^\\n\\r]*$" - }, - { - "pattern": "^[\\s\\S]{0,300}$" - } - ], - "description": "Recipient: a name from ListAgents (append its \" [ref]\" only when a listing or an error shows one), a teammate name, \"main\", or a background agent's agentId", - "type": "string" - } - }, - "required": [ - "to", - "message" - ], - "type": "object" -} ```` ## 4. EnterPlanMode guidance on when to plan is removed EnterPlanMode tool description · whole description removed The EnterPlanMode description is removed. It told Claude to proactively enter plan mode for non-trivial implementation work and to err on the side of planning, with lists of when to use it and when not to. This landed in only 2 of 5 captures, and EnterPlanMode is not in the new deferred tool list, so the removal looks specific to some setups. - Gone in this release - +0 / -581 words - Landed in 5 of 23 prompts (main prompt 3/6, session agents, compaction) ```diff -Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval. -## When to Use This Tool -**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply: -1. **New Feature Implementation**: Adding meaningful new functionality - - Example: "Add a logout button" - where should it go? What should happen on click? - - Example: "Add form validation" - what rules? What error messages? -2. **Multiple Valid Approaches**: The task can be solved in several different ways - - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc. - - Example: "Improve performance" - many optimization strategies possible -3. **Code Modifications**: Changes that affect existing behavior or structure - - Example: "Update the login flow" - what exactly should change? - - Example: "Refactor this component" - what's the target architecture? -4. **Architectural Decisions**: The task requires choosing between patterns or technologies - - Example: "Add real-time updates" - WebSockets vs SSE vs polling - - Example: "Implement state management" - Redux vs Context vs custom solution -5. **Multi-File Changes**: The task will likely touch more than 2-3 files - - Example: "Refactor the authentication system" - - Example: "Add a new API endpoint with tests" -6. **Unclear Requirements**: You need to explore before understanding the full scope - - Example: "Make the app faster" - need to profile and identify bottlenecks - - Example: "Fix the bug in checkout" - need to investigate root cause -7. **User Preferences Matter**: The implementation could reasonably go multiple ways - - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead - - Plan mode lets you explore first, then present options with context -## When NOT to Use This Tool -Only skip EnterPlanMode for simple tasks: -- Single-line or few-line fixes (typos, obvious bugs, small tweaks) -- Adding a single function with clear requirements -- Tasks where the user has given very specific, detailed instructions -- Pure research/exploration tasks (use the Agent tool instead) -## What Happens in Plan Mode -In plan mode, you'll: -1. Thoroughly explore the codebase using `find`/Glob, `grep`/Grep, and Read -2. Understand existing patterns and architecture -3. Design an implementation approach -4. Present your plan to the user for approval -5. Use AskUserQuestion if you need to clarify approaches -6. Exit plan mode with ExitPlanMode when ready to implement -## Examples -### GOOD - Use EnterPlanMode: -User: "Add user authentication to the app" -- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure) -User: "Optimize the database queries" -- Multiple approaches possible, need to profile first, significant impact -User: "Implement dark mode" -- Architectural decision on theme system, affects many components -User: "Add a delete button to the user profile" -- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates -User: "Update the error handling in the API" -- Affects multiple files, user should approve the approach -### BAD - Don't use EnterPlanMode: -User: "Fix the typo in the README" -- Straightforward, no planning needed -User: "Add a console.log to debug this function" -- Simple, obvious implementation -User: "What files handle routing?" -- Research task, not implementation planning -## Important Notes -- This tool REQUIRES user approval - they must consent to entering plan mode -- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work -- Users appreciate being consulted before significant changes are made to their codebase ``` ## 5. EnterWorktree description deferred out of the tool list EnterWorktree tool description · whole description removed The EnterWorktree description is removed. It said to use worktrees only when the user or CLAUDE.md explicitly asks, and it explained the baseRef setting and entering existing worktrees via `path`. EnterWorktree is now a deferred tool whose schema must be fetched with ToolSearch before use. - Gone in this release - +0 / -519 words - Landed in 21 of 23 prompts (main prompt 6/6, session agents, slash commands 3/3, compaction, system reminders 7/8, subagents 3/3) ```diff -Use this tool ONLY when explicitly instructed to work in a worktree — either by the user directly, or by project instructions (CLAUDE.md / memory). This tool creates an isolated git worktree and switches the current session into it. -## When to Use -- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree") -- CLAUDE.md or memory instructions direct you to work in a worktree for the current task -## When NOT to Use -- The user asks to create a branch, switch branches, or work on a different branch — use git commands instead -- The user asks to fix a bug or work on a feature — use normal git workflow unless worktrees are explicitly requested by the user or project instructions -- Never use this tool unless "worktree" is explicitly mentioned by the user or in CLAUDE.md / memory instructions -## Requirements -- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json -- Must not already be in a worktree session when creating a new worktree (`name`); switching into another existing worktree via `path` is allowed -## Behavior -- In a git repository: creates a new git worktree inside `.claude/worktrees/` on a new branch. The base ref is governed by the `worktree.baseRef` setting: `fresh` (default) branches from origin/; `head` branches from your current local HEAD -- Outside a git repository: delegates to WorktreeCreate/WorktreeRemove hooks for VCS-agnostic isolation -- Switches the session's working directory to the new worktree -- Use ExitWorktree to leave the worktree mid-session (keep or remove). On session exit, if still in the worktree, the user will be prompted to keep or remove it -## Entering an existing worktree -Pass `path` instead of `name` to switch the session into a worktree that already exists (e.g., one you just created with `git worktree add`). On first entry from the launch directory, the path must appear in `git worktree list` for the repository that owns it — the current repository or, in a multi-repo workspace, a repository nested inside it; paths registered by neither are rejected. ExitWorktree will not remove a worktree entered this way; use `action: "keep"` to return to the original directory. -Switching with `path` also works when the session is already in a worktree (the previous worktree is left on disk, untouched, and only the new one is tracked for exit-time cleanup), and from agents whose working directory was pinned at launch (subagent isolation or explicit cwd). In both cases the target must be a worktree under `.claude/worktrees/` of the same repository, and from a pinned agent the switch only affects this agent, not the parent session. After a further switch, previously-visited worktrees are no longer writable — re-issue EnterWorktree with `path` to return to one. -## Parameters -- `name` (optional): A name for a new worktree. If neither `name` nor `path` is provided, a random name is generated. -- `path` (optional): Path to an existing worktree to enter instead of creating one — of the current repository, or (on first entry from the launch directory) of a repository nested inside it. Mutually exclusive with `name`. -{ - "$schema": "https://json-schema.org/draft/2020-12/schema", - "additionalProperties": false, - "properties": { - "name": { - "description": "Optional name for a new worktree. Each \"/\"-separated segment may contain only letters, digits, dots, underscores, and dashes; max 64 chars total. A random name is generated if not provided. Mutually exclusive with `path`.", - "type": "string" - }, - "path": { - "description": "Path to an existing worktree to switch into instead of creating a new one. Must appear in `git worktree list` for the current repo \u2014 or, on first entry from the launch directory, for a repo nested inside it (multi-repo workspace). Mutually exclusive with `name`.", - "type": "string" - } - }, - "type": "object" -} ``` ## 6. CronCreate scheduling guidance deferred out of the tool list CronCreate tool description · whole description removed The CronCreate description is removed. It covered one-shot versus recurring cron jobs, avoiding the :00 and :30 minute marks, session-only storage, and the 7-day auto-expiry Claude was told to mention to users. CronCreate is now listed as a deferred tool loaded via ToolSearch. - Gone in this release - +0 / -495 words - Landed in 21 of 23 prompts (main prompt 6/6, session agents, slash commands 3/3, compaction, system reminders 7/8, subagents 3/3) ```diff -Schedule a prompt to be enqueued at a future time. Use for both recurring schedules and one-shot reminders. -Uses standard 5-field cron in the user's local timezone: minute hour day-of-month month day-of-week. "0 9 * * *" means 9am local — no timezone conversion needed. -## One-shot tasks (recurring: false) -For "remind me at X" or "at