@iaforged/context-code 1.3.5 → 1.3.6

package/dist/src/utils/messages.js

@@ -317,8 +317,8 @@ export function createSyntheticUserCaveatMessage() {
  * Formats the command-input breadcrumb the model sees when a slash command runs.
  */
 export function formatCommandInputTags(commandName, args) {
-    return `<${COMMAND_NAME_TAG}>/${commandName}</${COMMAND_NAME_TAG}>
-            <${COMMAND_MESSAGE_TAG}>${commandName}</${COMMAND_MESSAGE_TAG}>
+    return `<${COMMAND_NAME_TAG}>/${commandName}</${COMMAND_NAME_TAG}>
+            <${COMMAND_MESSAGE_TAG}>${commandName}</${COMMAND_MESSAGE_TAG}>
             <${COMMAND_ARGS_TAG}>${args}</${COMMAND_ARGS_TAG}>`;
 }
 /**
@@ -2365,35 +2365,35 @@ function getPlanModeInstructions(attachment) {
 // Plan file structure experiment arms.
 // Each arm returns the full Phase 4 section so the surrounding template
 // stays a flat string interpolation with no conditionals inline.
-export const PLAN_PHASE4_CONTROL = `### Phase 4: Final Plan
-Goal: Write your final plan to the plan file (the only file you can edit).
-- Begin with a **Context** section: explain why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome
-- Include only your recommended approach, not all alternatives
-- Ensure that the plan file is concise enough to scan quickly, but detailed enough to execute effectively
-- Include the paths of critical files to be modified
-- Reference existing functions and utilities you found that should be reused, with their file paths
+export const PLAN_PHASE4_CONTROL = `### Phase 4: Final Plan
+Goal: Write your final plan to the plan file (the only file you can edit).
+- Begin with a **Context** section: explain why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome
+- Include only your recommended approach, not all alternatives
+- Ensure that the plan file is concise enough to scan quickly, but detailed enough to execute effectively
+- Include the paths of critical files to be modified
+- Reference existing functions and utilities you found that should be reused, with their file paths
 - Include a verification section describing how to test the changes end-to-end (run the code, use MCP tools, run tests)`;
-const PLAN_PHASE4_TRIM = `### Phase 4: Final Plan
-Goal: Write your final plan to the plan file (the only file you can edit).
-- One-line **Context**: what is being changed and why
-- Include only your recommended approach, not all alternatives
-- List the paths of files to be modified
-- Reference existing functions and utilities to reuse, with their file paths
+const PLAN_PHASE4_TRIM = `### Phase 4: Final Plan
+Goal: Write your final plan to the plan file (the only file you can edit).
+- One-line **Context**: what is being changed and why
+- Include only your recommended approach, not all alternatives
+- List the paths of files to be modified
+- Reference existing functions and utilities to reuse, with their file paths
 - End with **Verification**: the single command to run to confirm the change works (no numbered test procedures)`;
-const PLAN_PHASE4_CUT = `### Phase 4: Final Plan
-Goal: Write your final plan to the plan file (the only file you can edit).
-- Do NOT write a Context or Background section. The user just told you what they want.
-- List the paths of files to be modified and what changes in each (one line per file)
-- Reference existing functions and utilities to reuse, with their file paths
-- End with **Verification**: the single command that confirms the change works
+const PLAN_PHASE4_CUT = `### Phase 4: Final Plan
+Goal: Write your final plan to the plan file (the only file you can edit).
+- Do NOT write a Context or Background section. The user just told you what they want.
+- List the paths of files to be modified and what changes in each (one line per file)
+- Reference existing functions and utilities to reuse, with their file paths
+- End with **Verification**: the single command that confirms the change works
 - Most good plans are under 40 lines. Prose is a sign you are padding.`;
-const PLAN_PHASE4_CAP = `### Phase 4: Final Plan
-Goal: Write your final plan to the plan file (the only file you can edit).
-- Do NOT write a Context, Background, or Overview section. The user just told you what they want.
-- Do NOT restate the user's request. Do NOT write prose paragraphs.
-- List the paths of files to be modified and what changes in each (one bullet per file)
-- Reference existing functions to reuse, with file:line
-- End with the single verification command
+const PLAN_PHASE4_CAP = `### Phase 4: Final Plan
+Goal: Write your final plan to the plan file (the only file you can edit).
+- Do NOT write a Context, Background, or Overview section. The user just told you what they want.
+- Do NOT restate the user's request. Do NOT write prose paragraphs.
+- List the paths of files to be modified and what changes in each (one bullet per file)
+- Reference existing functions to reuse, with file:line
+- End with the single verification command
 - **Hard limit: 40 lines.** If the plan is longer, delete prose — not file paths.`;
 function getPlanPhase4Section() {
     const variant = getPewterLedgerVariant();
@@ -2424,69 +2424,69 @@ function getPlanModeV2Instructions(attachment) {
     const planFileInfo = attachment.planExists
         ? `A plan file already exists at ${attachment.planFilePath}. You can read it and make incremental edits using the ${FileEditTool.name} tool.`
         : `No plan file exists yet. You should create your plan at ${attachment.planFilePath} using the ${FileWriteTool.name} tool.`;
-    const content = `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.
-
-## Plan File Info:
-${planFileInfo}
-You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
-
-## Plan Workflow
-
-### Phase 1: Initial Understanding
-Goal: Gain a comprehensive understanding of the user's request by reading through code and asking them questions. Critical: In this phase you should only use the ${EXPLORE_AGENT.agentType} subagent type.
-
-1. Focus on understanding the user's request and the code associated with their request. Actively search for existing functions, utilities, and patterns that can be reused — avoid proposing new code when suitable implementations already exist.
-
-2. **Launch up to ${exploreAgentCount} ${EXPLORE_AGENT.agentType} agents IN PARALLEL** (single message, multiple tool calls) to efficiently explore the codebase.
-   - Use 1 agent when the task is isolated to known files, the user provided specific file paths, or you're making a small targeted change.
-   - Use multiple agents when: the scope is uncertain, multiple areas of the codebase are involved, or you need to understand existing patterns before planning.
-   - Quality over quantity - ${exploreAgentCount} agents maximum, but you should try to use the minimum number of agents necessary (usually just 1)
-   - If using multiple agents: Provide each agent with a specific search focus or area to explore. Example: One agent searches for existing implementations, another explores related components, a third investigating testing patterns
-
-### Phase 2: Design
-Goal: Design an implementation approach.
-
-Launch ${PLAN_AGENT.agentType} agent(s) to design the implementation based on the user's intent and your exploration results from Phase 1.
-
-You can launch up to ${agentCount} agent(s) in parallel.
-
-**Guidelines:**
-- **Default**: Launch at least 1 Plan agent for most tasks - it helps validate your understanding and consider alternatives
-- **Skip agents**: Only for truly trivial tasks (typo fixes, single-line changes, simple renames)
+    const content = `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.
+
+## Plan File Info:
+${planFileInfo}
+You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
+
+## Plan Workflow
+
+### Phase 1: Initial Understanding
+Goal: Gain a comprehensive understanding of the user's request by reading through code and asking them questions. Critical: In this phase you should only use the ${EXPLORE_AGENT.agentType} subagent type.
+
+1. Focus on understanding the user's request and the code associated with their request. Actively search for existing functions, utilities, and patterns that can be reused — avoid proposing new code when suitable implementations already exist.
+
+2. **Launch up to ${exploreAgentCount} ${EXPLORE_AGENT.agentType} agents IN PARALLEL** (single message, multiple tool calls) to efficiently explore the codebase.
+   - Use 1 agent when the task is isolated to known files, the user provided specific file paths, or you're making a small targeted change.
+   - Use multiple agents when: the scope is uncertain, multiple areas of the codebase are involved, or you need to understand existing patterns before planning.
+   - Quality over quantity - ${exploreAgentCount} agents maximum, but you should try to use the minimum number of agents necessary (usually just 1)
+   - If using multiple agents: Provide each agent with a specific search focus or area to explore. Example: One agent searches for existing implementations, another explores related components, a third investigating testing patterns
+
+### Phase 2: Design
+Goal: Design an implementation approach.
+
+Launch ${PLAN_AGENT.agentType} agent(s) to design the implementation based on the user's intent and your exploration results from Phase 1.
+
+You can launch up to ${agentCount} agent(s) in parallel.
+
+**Guidelines:**
+- **Default**: Launch at least 1 Plan agent for most tasks - it helps validate your understanding and consider alternatives
+- **Skip agents**: Only for truly trivial tasks (typo fixes, single-line changes, simple renames)
 ${agentCount > 1
-        ? `- **Multiple agents**: Use up to ${agentCount} agents for complex tasks that benefit from different perspectives
-
-Examples of when to use multiple agents:
-- The task touches multiple parts of the codebase
-- It's a large refactor or architectural change
-- There are many edge cases to consider
-- You'd benefit from exploring different approaches
-
-Example perspectives by task type:
-- New feature: simplicity vs performance vs maintainability
-- Bug fix: root cause vs workaround vs prevention
-- Refactoring: minimal change vs clean architecture
+        ? `- **Multiple agents**: Use up to ${agentCount} agents for complex tasks that benefit from different perspectives
+
+Examples of when to use multiple agents:
+- The task touches multiple parts of the codebase
+- It's a large refactor or architectural change
+- There are many edge cases to consider
+- You'd benefit from exploring different approaches
+
+Example perspectives by task type:
+- New feature: simplicity vs performance vs maintainability
+- Bug fix: root cause vs workaround vs prevention
+- Refactoring: minimal change vs clean architecture
 `
-        : ''}
-In the agent prompt:
-- Provide comprehensive background context from Phase 1 exploration including filenames and code path traces
-- Describe requirements and constraints
-- Request a detailed implementation plan
-
-### Phase 3: Review
-Goal: Review the plan(s) from Phase 2 and ensure alignment with the user's intentions.
-1. Read the critical files identified by agents to deepen your understanding
-2. Ensure that the plans align with the user's original request
-3. Use ${ASK_USER_QUESTION_TOOL_NAME} to clarify any remaining questions with the user
-
-${getPlanPhase4Section()}
-
-### Phase 5: Call ${ExitPlanModeV2Tool.name}
-At the very end of your turn, once you have asked the user questions and are happy with your final plan file - you should always call ${ExitPlanModeV2Tool.name} to indicate to the user that you are done planning.
-This is critical - your turn should only end with either using the ${ASK_USER_QUESTION_TOOL_NAME} tool OR calling ${ExitPlanModeV2Tool.name}. Do not stop unless it's for these 2 reasons
-
-**Important:** Use ${ASK_USER_QUESTION_TOOL_NAME} ONLY to clarify requirements or choose between approaches. Use ${ExitPlanModeV2Tool.name} to request plan approval. Do NOT ask about plan approval in any other way - no text questions, no AskUserQuestion. Phrases like "Is this plan okay?", "Should I proceed?", "How does this plan look?", "Any changes before we start?", or similar MUST use ${ExitPlanModeV2Tool.name}.
-
+        : ''}
+In the agent prompt:
+- Provide comprehensive background context from Phase 1 exploration including filenames and code path traces
+- Describe requirements and constraints
+- Request a detailed implementation plan
+
+### Phase 3: Review
+Goal: Review the plan(s) from Phase 2 and ensure alignment with the user's intentions.
+1. Read the critical files identified by agents to deepen your understanding
+2. Ensure that the plans align with the user's original request
+3. Use ${ASK_USER_QUESTION_TOOL_NAME} to clarify any remaining questions with the user
+
+${getPlanPhase4Section()}
+
+### Phase 5: Call ${ExitPlanModeV2Tool.name}
+At the very end of your turn, once you have asked the user questions and are happy with your final plan file - you should always call ${ExitPlanModeV2Tool.name} to indicate to the user that you are done planning.
+This is critical - your turn should only end with either using the ${ASK_USER_QUESTION_TOOL_NAME} tool OR calling ${ExitPlanModeV2Tool.name}. Do not stop unless it's for these 2 reasons
+
+**Important:** Use ${ASK_USER_QUESTION_TOOL_NAME} ONLY to clarify requirements or choose between approaches. Use ${ExitPlanModeV2Tool.name} to request plan approval. Do NOT ask about plan approval in any other way - no text questions, no AskUserQuestion. Phrases like "Is this plan okay?", "Should I proceed?", "How does this plan look?", "Any changes before we start?", or similar MUST use ${ExitPlanModeV2Tool.name}.
+
 NOTE: At any point in time through this workflow you should feel free to ask the user questions or clarifications using the ${ASK_USER_QUESTION_TOOL_NAME} tool. Don't make large assumptions about user intent. The goal is to present a well researched plan to the user, and tie any loose ends before implementation begins.`;
     return wrapMessagesInSystemReminder([
         createUserMessage({ content, isMeta: true }),
@@ -2518,53 +2518,53 @@ function getPlanModeInterviewInstructions(attachment) {
     const planFileInfo = attachment.planExists
         ? `A plan file already exists at ${attachment.planFilePath}. You can read it and make incremental edits using the ${FileEditTool.name} tool.`
         : `No plan file exists yet. You should create your plan at ${attachment.planFilePath} using the ${FileWriteTool.name} tool.`;
-    const content = `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.
-
-## Plan File Info:
-${planFileInfo}
-
-## Iterative Planning Workflow
-
-You are pair-planning with the user. Explore the code to build context, ask the user questions when you hit decisions you can't make alone, and write your findings into the plan file as you go. The plan file (above) is the ONLY file you may edit — it starts as a rough skeleton and gradually becomes the final plan.
-
-### The Loop
-
-Repeat this cycle until the plan is complete:
-
-1. **Explore** — Use ${getReadOnlyToolNames()} to read code. Look for existing functions, utilities, and patterns to reuse.${areExplorePlanAgentsEnabled() ? ` You can use the ${EXPLORE_AGENT.agentType} agent type to parallelize complex searches without filling your context, though for straightforward queries direct tools are simpler.` : ''}
-2. **Update the plan file** — After each discovery, immediately capture what you learned. Don't wait until the end.
-3. **Ask the user** — When you hit an ambiguity or decision you can't resolve from code alone, use ${ASK_USER_QUESTION_TOOL_NAME}. Then go back to step 1.
-
-### First Turn
-
-Start by quickly scanning a few key files to form an initial understanding of the task scope. Then write a skeleton plan (headers and rough notes) and ask the user your first round of questions. Don't explore exhaustively before engaging the user.
-
-### Asking Good Questions
-
-- Never ask what you could find out by reading the code
-- Batch related questions together (use multi-question ${ASK_USER_QUESTION_TOOL_NAME} calls)
-- Focus on things only the user can answer: requirements, preferences, tradeoffs, edge case priorities
-- Scale depth to the task — a vague feature request needs many rounds; a focused bug fix may need one or none
-
-### Plan File Structure
-Your plan file should be divided into clear sections using markdown headers, based on the request. Fill out these sections as you go.
-- Begin with a **Context** section: explain why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome
-- Include only your recommended approach, not all alternatives
-- Ensure that the plan file is concise enough to scan quickly, but detailed enough to execute effectively
-- Include the paths of critical files to be modified
-- Reference existing functions and utilities you found that should be reused, with their file paths
-- Include a verification section describing how to test the changes end-to-end (run the code, use MCP tools, run tests)
-
-### When to Converge
-
-Your plan is ready when you've addressed all ambiguities and it covers: what to change, which files to modify, what existing code to reuse (with file paths), and how to verify the changes. Call ${ExitPlanModeV2Tool.name} when the plan is ready for approval.
-
-### Ending Your Turn
-
-Your turn should only end by either:
-- Using ${ASK_USER_QUESTION_TOOL_NAME} to gather more information
-- Calling ${ExitPlanModeV2Tool.name} when the plan is ready for approval
-
+    const content = `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.
+
+## Plan File Info:
+${planFileInfo}
+
+## Iterative Planning Workflow
+
+You are pair-planning with the user. Explore the code to build context, ask the user questions when you hit decisions you can't make alone, and write your findings into the plan file as you go. The plan file (above) is the ONLY file you may edit — it starts as a rough skeleton and gradually becomes the final plan.
+
+### The Loop
+
+Repeat this cycle until the plan is complete:
+
+1. **Explore** — Use ${getReadOnlyToolNames()} to read code. Look for existing functions, utilities, and patterns to reuse.${areExplorePlanAgentsEnabled() ? ` You can use the ${EXPLORE_AGENT.agentType} agent type to parallelize complex searches without filling your context, though for straightforward queries direct tools are simpler.` : ''}
+2. **Update the plan file** — After each discovery, immediately capture what you learned. Don't wait until the end.
+3. **Ask the user** — When you hit an ambiguity or decision you can't resolve from code alone, use ${ASK_USER_QUESTION_TOOL_NAME}. Then go back to step 1.
+
+### First Turn
+
+Start by quickly scanning a few key files to form an initial understanding of the task scope. Then write a skeleton plan (headers and rough notes) and ask the user your first round of questions. Don't explore exhaustively before engaging the user.
+
+### Asking Good Questions
+
+- Never ask what you could find out by reading the code
+- Batch related questions together (use multi-question ${ASK_USER_QUESTION_TOOL_NAME} calls)
+- Focus on things only the user can answer: requirements, preferences, tradeoffs, edge case priorities
+- Scale depth to the task — a vague feature request needs many rounds; a focused bug fix may need one or none
+
+### Plan File Structure
+Your plan file should be divided into clear sections using markdown headers, based on the request. Fill out these sections as you go.
+- Begin with a **Context** section: explain why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome
+- Include only your recommended approach, not all alternatives
+- Ensure that the plan file is concise enough to scan quickly, but detailed enough to execute effectively
+- Include the paths of critical files to be modified
+- Reference existing functions and utilities you found that should be reused, with their file paths
+- Include a verification section describing how to test the changes end-to-end (run the code, use MCP tools, run tests)
+
+### When to Converge
+
+Your plan is ready when you've addressed all ambiguities and it covers: what to change, which files to modify, what existing code to reuse (with file paths), and how to verify the changes. Call ${ExitPlanModeV2Tool.name} when the plan is ready for approval.
+
+### Ending Your Turn
+
+Your turn should only end by either:
+- Using ${ASK_USER_QUESTION_TOOL_NAME} to gather more information
+- Calling ${ExitPlanModeV2Tool.name} when the plan is ready for approval
+
 **Important:** Use ${ExitPlanModeV2Tool.name} to request plan approval. Do NOT ask about plan approval via text or AskUserQuestion.`;
     return wrapMessagesInSystemReminder([
         createUserMessage({ content, isMeta: true }),
@@ -2583,11 +2583,11 @@ function getPlanModeV2SubAgentInstructions(attachment) {
     const planFileInfo = attachment.planExists
         ? `A plan file already exists at ${attachment.planFilePath}. You can read it and make incremental edits using the ${FileEditTool.name} tool if you need to.`
         : `No plan file exists yet. You should create your plan at ${attachment.planFilePath} using the ${FileWriteTool.name} tool if you need to.`;
-    const content = `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits, run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received (for example, to make edits). Instead, you should:
-
-## Plan File Info:
-${planFileInfo}
-You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
+    const content = `Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits, run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received (for example, to make edits). Instead, you should:
+
+## Plan File Info:
+${planFileInfo}
+You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.
 Answer the user's query comprehensively, using the ${ASK_USER_QUESTION_TOOL_NAME} tool if you need to ask the user clarifying questions. If you do use the ${ASK_USER_QUESTION_TOOL_NAME}, make sure to ask all clarifying questions you need to fully understand the user's intent before proceeding.`;
     return wrapMessagesInSystemReminder([
         createUserMessage({ content, isMeta: true }),
@@ -2600,15 +2600,15 @@ function getAutoModeInstructions(attachment) {
     return getAutoModeFullInstructions();
 }
 function getAutoModeFullInstructions() {
-    const content = `## Auto Mode Active
-
-Auto mode is active. The user chose continuous, autonomous execution. You should:
-
-1. **Execute immediately** — Start implementing right away. Make reasonable assumptions and proceed on low-risk work.
-2. **Minimize interruptions** — Prefer making reasonable assumptions over asking questions for routine decisions.
-3. **Prefer action over planning** — Do not enter plan mode unless the user explicitly asks. When in doubt, start coding.
-4. **Expect course corrections** — The user may provide suggestions or course corrections at any point; treat those as normal input.
-5. **Do not take overly destructive actions** — Auto mode is not a license to destroy. Anything that deletes data or modifies shared or production systems still needs explicit user confirmation. If you reach such a decision point, ask and wait, or course correct to a safer method instead.
+    const content = `## Auto Mode Active
+
+Auto mode is active. The user chose continuous, autonomous execution. You should:
+
+1. **Execute immediately** — Start implementing right away. Make reasonable assumptions and proceed on low-risk work.
+2. **Minimize interruptions** — Prefer making reasonable assumptions over asking questions for routine decisions.
+3. **Prefer action over planning** — Do not enter plan mode unless the user explicitly asks. When in doubt, start coding.
+4. **Expect course corrections** — The user may provide suggestions or course corrections at any point; treat those as normal input.
+5. **Do not take overly destructive actions** — Auto mode is not a license to destroy. Anything that deletes data or modifies shared or production systems still needs explicit user confirmation. If you reach such a decision point, ask and wait, or course correct to a safer method instead.
 6. **Avoid data exfiltration** — Post even routine messages to chat platforms or work tickets only if the user has directed you to. You must not share secrets (e.g. credentials, internal documentation) unless the user has explicitly authorized both that specific secret and its destination.`;
     return wrapMessagesInSystemReminder([
         createUserMessage({ content, isMeta: true }),
@@ -2633,31 +2633,31 @@ export function normalizeAttachmentForAPI(attachment) {
         if (attachment.type === 'team_context') {
             return [
                 createUserMessage({
-                    content: `<system-reminder>
-# Team Coordination
-
-You are a teammate in team "${attachment.teamName}".
-
-**Your Identity:**
-- Name: ${attachment.agentName}
-
-**Team Resources:**
-- Team config: ${attachment.teamConfigPath}
-- Task list: ${attachment.taskListPath}
-
-**Team Leader:** The team lead's name is "team-lead". Send updates and completion notifications to them.
-
-Read the team config to discover your teammates' names. Check the task list periodically. Create new tasks when work should be divided. Mark tasks resolved when complete.
-
-**IMPORTANT:** Always refer to teammates by their NAME (e.g., "team-lead", "analyzer", "researcher"), never by UUID. When messaging, use the name directly:
-
-\`\`\`json
-{
-  "to": "team-lead",
-  "message": "Your message here",
-  "summary": "Brief 5-10 word preview"
-}
-\`\`\`
+                    content: `<system-reminder>
+# Team Coordination
+
+You are a teammate in team "${attachment.teamName}".
+
+**Your Identity:**
+- Name: ${attachment.agentName}
+
+**Team Resources:**
+- Team config: ${attachment.teamConfigPath}
+- Task list: ${attachment.taskListPath}
+
+**Team Leader:** The team lead's name is "team-lead". Send updates and completion notifications to them.
+
+Read the team config to discover your teammates' names. Check the task list periodically. Create new tasks when work should be divided. Mark tasks resolved when complete.
+
+**IMPORTANT:** Always refer to teammates by their NAME (e.g., "team-lead", "analyzer", "researcher"), never by UUID. When messaging, use the name directly:
+
+\`\`\`json
+{
+  "to": "team-lead",
+  "message": "Your message here",
+  "summary": "Brief 5-10 word preview"
+}
+\`\`\`
 </system-reminder>`,
                     isMeta: true,
                 }),
@@ -2961,18 +2961,18 @@ Read the team config to discover your teammates' names. Check the task list peri
             return getPlanModeInstructions(attachment);
         }
         case 'plan_mode_reentry': {
-            const content = `## Re-entering Plan Mode
-
-You are returning to plan mode after having previously exited it. A plan file exists at ${attachment.planFilePath} from your previous planning session.
-
-**Before proceeding with any new planning, you should:**
-1. Read the existing plan file to understand what was previously planned
-2. Evaluate the user's current request against that plan
-3. Decide how to proceed:
-   - **Different task**: If the user's request is for a different task—even if it's similar or related—start fresh by overwriting the existing plan
-   - **Same task, continuing**: If this is explicitly a continuation or refinement of the exact same task, modify the existing plan while cleaning up outdated or irrelevant sections
-4. Continue on with the plan process and most importantly you should always edit the plan file one way or the other before calling ${ExitPlanModeV2Tool.name}
-
+            const content = `## Re-entering Plan Mode
+
+You are returning to plan mode after having previously exited it. A plan file exists at ${attachment.planFilePath} from your previous planning session.
+
+**Before proceeding with any new planning, you should:**
+1. Read the existing plan file to understand what was previously planned
+2. Evaluate the user's current request against that plan
+3. Decide how to proceed:
+   - **Different task**: If the user's request is for a different task—even if it's similar or related—start fresh by overwriting the existing plan
+   - **Same task, continuing**: If this is explicitly a continuation or refinement of the exact same task, modify the existing plan while cleaning up outdated or irrelevant sections
+4. Continue on with the plan process and most importantly you should always edit the plan file one way or the other before calling ${ExitPlanModeV2Tool.name}
+
 Treat this as a fresh planning session. Do not assume the existing plan is relevant without evaluating it first.`;
             return wrapMessagesInSystemReminder([
                 createUserMessage({ content, isMeta: true }),
@@ -2982,8 +2982,8 @@ Treat this as a fresh planning session. Do not assume the existing plan is relev
             const planReference = attachment.planExists
                 ? ` The plan file is located at ${attachment.planFilePath} if you need to reference it.`
                 : '';
-            const content = `## Exited Plan Mode
-
+            const content = `## Exited Plan Mode
+
 You have exited plan mode. You can now make edits, run tools, and take actions.${planReference}`;
             return wrapMessagesInSystemReminder([
                 createUserMessage({ content, isMeta: true }),
@@ -2993,8 +2993,8 @@ You have exited plan mode. You can now make edits, run tools, and take actions.$
             return getAutoModeInstructions(attachment);
         }
         case 'auto_mode_exit': {
-            const content = `## Exited Auto Mode
-
+            const content = `## Exited Auto Mode
+
 You have exited auto mode. The user may now want to interact more directly. You should ask clarifying questions when the approach is ambiguous rather than making assumptions.`;
             return wrapMessagesInSystemReminder([
                 createUserMessage({ content, isMeta: true }),