@iaforged/context-code 1.2.9 → 1.2.10

package/dist/src/tools/EnterPlanModeTool/prompt.js

@@ -1,15 +1,15 @@
 import { isPlanModeInterviewPhaseEnabled } from '../../utils/planModeV2.js';
 import { ASK_USER_QUESTION_TOOL_NAME } from '../AskUserQuestionTool/prompt.js';
-const WHAT_HAPPENS_SECTION = `## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use ${ASK_USER_QUESTION_TOOL_NAME} if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
+const WHAT_HAPPENS_SECTION = `## What Happens in Plan Mode
+
+In plan mode, you'll:
+1. Thoroughly explore the codebase using Glob, Grep, and Read tools
+2. Understand existing patterns and architecture
+3. Design an implementation approach
+4. Present your plan to the user for approval
+5. Use ${ASK_USER_QUESTION_TOOL_NAME} if you need to clarify approaches
+6. Exit plan mode with ExitPlanMode when ready to implement
+
 `;
 function getEnterPlanModeToolPromptExternal() {
     // When interview phase is enabled, omit the "What Happens" section —
@@ -17,81 +17,81 @@ function getEnterPlanModeToolPromptExternal() {
     const whatHappens = isPlanModeInterviewPhaseEnabled()
         ? ''
         : WHAT_HAPPENS_SECTION;
-    return `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 ${ASK_USER_QUESTION_TOOL_NAME} 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 with explore agent instead)
-
-${whatHappens}## 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
+    return `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 ${ASK_USER_QUESTION_TOOL_NAME} 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 with explore agent instead)
+
+${whatHappens}## 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
 `;
 }
 function getEnterPlanModeToolPromptAnt() {
@@ -100,61 +100,61 @@ function getEnterPlanModeToolPromptAnt() {
     const whatHappens = isPlanModeInterviewPhaseEnabled()
         ? ''
         : WHAT_HAPPENS_SECTION;
-    return `Use this tool when a task has genuine ambiguity about the right approach and getting user input before coding would prevent significant rework. 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
-
-Plan mode is valuable when the implementation approach is genuinely unclear. Use it when:
-
-1. **Significant Architectural Ambiguity**: Multiple reasonable approaches exist and the choice meaningfully affects the codebase
-   - Example: "Add caching to the API" - Redis vs in-memory vs file-based
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-
-2. **Unclear Requirements**: You need to explore and clarify before you can make progress
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Refactor this module" - need to understand what the target architecture should be
-
-3. **High-Impact Restructuring**: The task will significantly restructure existing code and getting buy-in first reduces risk
-   - Example: "Redesign the authentication system"
-   - Example: "Migrate from one state management approach to another"
-
-## When NOT to Use This Tool
-
-Skip plan mode when you can reasonably infer the right approach:
-- The task is straightforward even if it touches multiple files
-- The user's request is specific enough that the implementation path is clear
-- You're adding a feature with an obvious implementation pattern (e.g., adding a button, a new endpoint following existing conventions)
-- Bug fixes where the fix is clear once you understand the bug
-- Research/exploration tasks (use the Agent tool instead)
-- The user says something like "can we work on X" or "let's do X" — just get started
-
-When in doubt, prefer starting work and using ${ASK_USER_QUESTION_TOOL_NAME} for specific questions over entering a full planning phase.
-
-${whatHappens}## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Genuinely ambiguous: session vs JWT, where to store tokens, middleware structure
-
-User: "Redesign the data pipeline"
-- Major restructuring where the wrong approach wastes significant effort
-
-### BAD - Don't use EnterPlanMode:
-User: "Add a delete button to the user profile"
-- Implementation path is clear; just do it
-
-User: "Can we work on the search feature?"
-- User wants to get started, not plan
-
-User: "Update the error handling in the API"
-- Start working; ask specific questions if needed
-
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
+    return `Use this tool when a task has genuine ambiguity about the right approach and getting user input before coding would prevent significant rework. 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
+
+Plan mode is valuable when the implementation approach is genuinely unclear. Use it when:
+
+1. **Significant Architectural Ambiguity**: Multiple reasonable approaches exist and the choice meaningfully affects the codebase
+   - Example: "Add caching to the API" - Redis vs in-memory vs file-based
+   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
+
+2. **Unclear Requirements**: You need to explore and clarify before you can make progress
+   - Example: "Make the app faster" - need to profile and identify bottlenecks
+   - Example: "Refactor this module" - need to understand what the target architecture should be
+
+3. **High-Impact Restructuring**: The task will significantly restructure existing code and getting buy-in first reduces risk
+   - Example: "Redesign the authentication system"
+   - Example: "Migrate from one state management approach to another"
+
+## When NOT to Use This Tool
+
+Skip plan mode when you can reasonably infer the right approach:
+- The task is straightforward even if it touches multiple files
+- The user's request is specific enough that the implementation path is clear
+- You're adding a feature with an obvious implementation pattern (e.g., adding a button, a new endpoint following existing conventions)
+- Bug fixes where the fix is clear once you understand the bug
+- Research/exploration tasks (use the Agent tool instead)
+- The user says something like "can we work on X" or "let's do X" — just get started
+
+When in doubt, prefer starting work and using ${ASK_USER_QUESTION_TOOL_NAME} for specific questions over entering a full planning phase.
+
+${whatHappens}## Examples
+
+### GOOD - Use EnterPlanMode:
+User: "Add user authentication to the app"
+- Genuinely ambiguous: session vs JWT, where to store tokens, middleware structure
+
+User: "Redesign the data pipeline"
+- Major restructuring where the wrong approach wastes significant effort
+
+### BAD - Don't use EnterPlanMode:
+User: "Add a delete button to the user profile"
+- Implementation path is clear; just do it
+
+User: "Can we work on the search feature?"
+- User wants to get started, not plan
+
+User: "Update the error handling in the API"
+- Start working; ask specific questions if needed
+
+User: "Fix the typo in the README"
+- Straightforward, no planning needed
+
+## Important Notes
+
+- This tool REQUIRES user approval - they must consent to entering plan mode
 `;
 }
 export function getEnterPlanModeToolPrompt() {

package/dist/src/tools/ExitPlanModeTool/ExitPlanModeV2Tool.js

@@ -330,18 +330,18 @@ export const ExitPlanModeV2Tool = buildTool({
         if (awaitingLeaderApproval) {
             return {
                 type: 'tool_result',
-                content: `Your plan has been submitted to the team lead for approval.
-
-Plan file: ${filePath}
-
-**What happens next:**
-1. Wait for the team lead to review your plan
-2. You will receive a message in your inbox with approval/rejection
-3. If approved, you can proceed with implementation
-4. If rejected, refine your plan based on the feedback
-
-**Important:** Do NOT proceed until you receive approval. Check your inbox for response.
-
+                content: `Your plan has been submitted to the team lead for approval.
+
+Plan file: ${filePath}
+
+**What happens next:**
+1. Wait for the team lead to review your plan
+2. You will receive a message in your inbox with approval/rejection
+3. If approved, you can proceed with implementation
+4. If rejected, refine your plan based on the feedback
+
+**Important:** Do NOT proceed until you receive approval. Check your inbox for response.
+
 Request ID: ${requestId}`,
                 tool_use_id: toolUseID,
             };
@@ -372,12 +372,12 @@ Request ID: ${requestId}`,
             : 'Approved Plan';
         return {
             type: 'tool_result',
-            content: `User has approved your plan. You can now start coding. Start with updating your todo list if applicable
-
-Your plan has been saved to: ${filePath}
-You can refer back to it if needed during implementation.${teamHint}
-
-## ${planLabel}:
+            content: `User has approved your plan. You can now start coding. Start with updating your todo list if applicable
+
+Your plan has been saved to: ${filePath}
+You can refer back to it if needed during implementation.${teamHint}
+
+## ${planLabel}:
 ${plan}`,
             tool_use_id: toolUseID,
         };

package/dist/src/tools/ExitPlanModeTool/prompt.js

@@ -1,27 +1,27 @@
 // External stub for ExitPlanModeTool prompt - excludes Ant-only allowedPrompts section
 // Hardcoded to avoid relative import issues in stub
 const ASK_USER_QUESTION_TOOL_NAME = 'AskUserQuestion';
-export const EXIT_PLAN_MODE_V2_TOOL_PROMPT = `Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
-
-## How This Tool Works
-- You should have already written your plan to the plan file specified in the plan mode system message
-- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
-- This tool simply signals that you're done planning and ready for the user to review and approve
-- The user will see the contents of your plan file when they review it
-
-## When to Use This Tool
-IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
-
-## Before Using This Tool
-Ensure your plan is complete and unambiguous:
-- If you have unresolved questions about requirements or approach, use ${ASK_USER_QUESTION_TOOL_NAME} first (in earlier phases)
-- Once your plan is finalized, use THIS tool to request approval
-
-**Important:** Do NOT use ${ASK_USER_QUESTION_TOOL_NAME} to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
-
-## Examples
-
-1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
-2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
-3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use ${ASK_USER_QUESTION_TOOL_NAME} first, then use exit plan mode tool after clarifying the approach.
+export const EXIT_PLAN_MODE_V2_TOOL_PROMPT = `Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
+
+## How This Tool Works
+- You should have already written your plan to the plan file specified in the plan mode system message
+- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
+- This tool simply signals that you're done planning and ready for the user to review and approve
+- The user will see the contents of your plan file when they review it
+
+## When to Use This Tool
+IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
+
+## Before Using This Tool
+Ensure your plan is complete and unambiguous:
+- If you have unresolved questions about requirements or approach, use ${ASK_USER_QUESTION_TOOL_NAME} first (in earlier phases)
+- Once your plan is finalized, use THIS tool to request approval
+
+**Important:** Do NOT use ${ASK_USER_QUESTION_TOOL_NAME} to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
+
+## Examples
+
+1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
+2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
+3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use ${ASK_USER_QUESTION_TOOL_NAME} first, then use exit plan mode tool after clarifying the approach.
 `;

package/dist/src/tools/ExitWorktreeTool/prompt.js

@@ -1,32 +1,32 @@
 export function getExitWorktreeToolPrompt() {
-    return `Exit a worktree session created by EnterWorktree and return the session to the original working directory.
-
-## Scope
-
-This tool ONLY operates on worktrees created by EnterWorktree in this session. It will NOT touch:
-- Worktrees you created manually with \`git worktree add\`
-- Worktrees from a previous session (even if created by EnterWorktree then)
-- The directory you're in if EnterWorktree was never called
-
-If called outside an EnterWorktree session, the tool is a **no-op**: it reports that no worktree session is active and takes no action. Filesystem state is unchanged.
-
-## When to Use
-
-- The user explicitly asks to "exit the worktree", "leave the worktree", "go back", or otherwise end the worktree session
-- Do NOT call this proactively — only when the user asks
-
-## Parameters
-
-- \`action\` (required): \`"keep"\` or \`"remove"\`
-  - \`"keep"\` — leave the worktree directory and branch intact on disk. Use this if the user wants to come back to the work later, or if there are changes to preserve.
-  - \`"remove"\` — delete the worktree directory and its branch. Use this for a clean exit when the work is done or abandoned.
-- \`discard_changes\` (optional, default false): only meaningful with \`action: "remove"\`. If the worktree has uncommitted files or commits not on the original branch, the tool will REFUSE to remove it unless this is set to \`true\`. If the tool returns an error listing changes, confirm with the user before re-invoking with \`discard_changes: true\`.
-
-## Behavior
-
-- Restores the session's working directory to where it was before EnterWorktree
-- Clears CWD-dependent caches (system prompt sections, memory files, plans directory) so the session state reflects the original directory
-- If a tmux session was attached to the worktree: killed on \`remove\`, left running on \`keep\` (its name is returned so the user can reattach)
-- Once exited, EnterWorktree can be called again to create a fresh worktree
+    return `Exit a worktree session created by EnterWorktree and return the session to the original working directory.
+
+## Scope
+
+This tool ONLY operates on worktrees created by EnterWorktree in this session. It will NOT touch:
+- Worktrees you created manually with \`git worktree add\`
+- Worktrees from a previous session (even if created by EnterWorktree then)
+- The directory you're in if EnterWorktree was never called
+
+If called outside an EnterWorktree session, the tool is a **no-op**: it reports that no worktree session is active and takes no action. Filesystem state is unchanged.
+
+## When to Use
+
+- The user explicitly asks to "exit the worktree", "leave the worktree", "go back", or otherwise end the worktree session
+- Do NOT call this proactively — only when the user asks
+
+## Parameters
+
+- \`action\` (required): \`"keep"\` or \`"remove"\`
+  - \`"keep"\` — leave the worktree directory and branch intact on disk. Use this if the user wants to come back to the work later, or if there are changes to preserve.
+  - \`"remove"\` — delete the worktree directory and its branch. Use this for a clean exit when the work is done or abandoned.
+- \`discard_changes\` (optional, default false): only meaningful with \`action: "remove"\`. If the worktree has uncommitted files or commits not on the original branch, the tool will REFUSE to remove it unless this is set to \`true\`. If the tool returns an error listing changes, confirm with the user before re-invoking with \`discard_changes: true\`.
+
+## Behavior
+
+- Restores the session's working directory to where it was before EnterWorktree
+- Clears CWD-dependent caches (system prompt sections, memory files, plans directory) so the session state reflects the original directory
+- If a tmux session was attached to the worktree: killed on \`remove\`, left running on \`keep\` (its name is returned so the user can reattach)
+- Once exited, EnterWorktree can be called again to create a fresh worktree
 `;
 }

package/dist/src/tools/FileEditTool/prompt.js

@@ -13,12 +13,12 @@ function getDefaultEditDescription() {
     const minimalUniquenessHint = process.env.USER_TYPE === 'ant'
         ? `\n- Use the smallest old_string that's clearly unique — usually 2-4 adjacent lines is sufficient. Avoid including 10+ lines of context when less uniquely identifies the target.`
         : '';
-    return `Performs exact string replacements in files.
-
-Usage:${getPreReadInstruction()}
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: ${prefixFormat}. Everything after that is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if \`old_string\` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use \`replace_all\` to change every instance of \`old_string\`.${minimalUniquenessHint}
+    return `Performs exact string replacements in files.
+
+Usage:${getPreReadInstruction()}
+- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: ${prefixFormat}. Everything after that is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
+- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
+- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
+- The edit will FAIL if \`old_string\` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use \`replace_all\` to change every instance of \`old_string\`.${minimalUniquenessHint}
 - Use \`replace_all\` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.`;
 }

package/dist/src/tools/FileReadTool/FileReadTool.js

@@ -10,6 +10,8 @@ import { logEvent } from '../../services/analytics/index.js';
 import { getFileExtensionForAnalytics, } from '../../services/analytics/metadata.js';
 import { countTokensWithAPI, roughTokenCountEstimationForFileType, } from '../../services/tokenEstimation.js';
 import { activateConditionalSkillsForPaths, addSkillDirectories, discoverSkillDirsForPaths, } from '../../skills/loadSkillsDir.js';
+import { isCoreToolsEnabled } from '../../core/tools/contracts.js';
+import { executeCoreFileRead } from '../../core/tools/filesCore.js';
 import { buildTool } from '../../Tool.js';
 import { getCwd } from '../../utils/cwd.js';
 import { getClaudeConfigHomeDir, isEnvTruthy } from '../../utils/envUtils.js';
@@ -768,7 +770,22 @@ async function callInner(file_path, fullFilePath, resolvedFilePath, ext, offset,
     }
     // --- Text file (single async read via readFileInRange) ---
     const lineOffset = offset === 0 ? 0 : offset - 1;
-    const { content, lineCount, totalLines, totalBytes, readBytes, mtimeMs } = await readFileInRange(resolvedFilePath, lineOffset, limit, limit === undefined ? maxSizeBytes : undefined, context.abortController.signal);
+    const coreReadResult = isCoreToolsEnabled()
+        ? await executeCoreFileRead({
+            absolute_path: resolvedFilePath,
+            offset,
+            limit,
+            max_bytes: limit === undefined ? maxSizeBytes : undefined,
+        }, {
+            abortSignal: context.abortController.signal,
+        })
+        : null;
+    if (coreReadResult && (!coreReadResult.success || !coreReadResult.data)) {
+        throw new Error(coreReadResult.error ?? 'Core file read failed');
+    }
+    const { content, lineCount, totalLines, totalBytes, readBytes, mtimeMs, } = coreReadResult
+        ? coreReadResult.data
+        : await readFileInRange(resolvedFilePath, lineOffset, limit, limit === undefined ? maxSizeBytes : undefined, context.abortController.signal);
     await validateContentTokens(content, ext, maxTokens);
     readFileState.set(fullFilePath, {
         content,

package/dist/src/tools/FileWriteTool/prompt.js

@@ -5,11 +5,11 @@ function getPreReadInstruction() {
     return `\n- If this is an existing file, you MUST use the ${FILE_READ_TOOL_NAME} tool first to read the file's contents. This tool will fail if you did not read the file first.`;
 }
 export function getWriteToolDescription() {
-    return `Writes a file to the local filesystem.
-
-Usage:
-- This tool will overwrite the existing file if there is one at the provided path.${getPreReadInstruction()}
-- Prefer the Edit tool for modifying existing files \u2014 it only sends the diff. Only use this tool to create new files or for complete rewrites.
-- NEVER create documentation files (*.md) or README files unless explicitly requested by the User.
+    return `Writes a file to the local filesystem.
+
+Usage:
+- This tool will overwrite the existing file if there is one at the provided path.${getPreReadInstruction()}
+- Prefer the Edit tool for modifying existing files \u2014 it only sends the diff. Only use this tool to create new files or for complete rewrites.
+- NEVER create documentation files (*.md) or README files unless explicitly requested by the User.
 - Only use emojis if the user explicitly requests it. Avoid writing emojis to files unless asked.`;
 }

package/dist/src/tools/GlobTool/prompt.js

@@ -1,6 +1,6 @@
 export const GLOB_TOOL_NAME = 'Glob';
-export const DESCRIPTION = `- Fast file pattern matching tool that works with any codebase size
-- Supports glob patterns like "**/*.js" or "src/**/*.ts"
-- Returns matching file paths sorted by modification time
-- Use this tool when you need to find files by name patterns
+export const DESCRIPTION = `- Fast file pattern matching tool that works with any codebase size
+- Supports glob patterns like "**/*.js" or "src/**/*.ts"
+- Returns matching file paths sorted by modification time
+- Use this tool when you need to find files by name patterns
 - When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead`;

package/dist/src/tools/GrepTool/prompt.js

@@ -2,15 +2,15 @@ import { AGENT_TOOL_NAME } from '../AgentTool/constants.js';
 import { BASH_TOOL_NAME } from '../BashTool/toolName.js';
 export const GREP_TOOL_NAME = 'Grep';
 export function getDescription() {
-    return `A powerful search tool built on ripgrep
-
-  Usage:
-  - ALWAYS use ${GREP_TOOL_NAME} for search tasks. NEVER invoke \`grep\` or \`rg\` as a ${BASH_TOOL_NAME} command. The ${GREP_TOOL_NAME} tool has been optimized for correct permissions and access.
-  - Supports full regex syntax (e.g., "log.*Error", "function\\s+\\w+")
-  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx") or type parameter (e.g., "js", "py", "rust")
-  - Output modes: "content" shows matching lines, "files_with_matches" shows only file paths (default), "count" shows match counts
-  - Use ${AGENT_TOOL_NAME} tool for open-ended searches requiring multiple rounds
-  - Pattern syntax: Uses ripgrep (not grep) - literal braces need escaping (use \`interface\\{\\}\` to find \`interface{}\` in Go code)
-  - Multiline matching: By default patterns match within single lines only. For cross-line patterns like \`struct \\{[\\s\\S]*?field\`, use \`multiline: true\`
+    return `A powerful search tool built on ripgrep
+
+  Usage:
+  - ALWAYS use ${GREP_TOOL_NAME} for search tasks. NEVER invoke \`grep\` or \`rg\` as a ${BASH_TOOL_NAME} command. The ${GREP_TOOL_NAME} tool has been optimized for correct permissions and access.
+  - Supports full regex syntax (e.g., "log.*Error", "function\\s+\\w+")
+  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx") or type parameter (e.g., "js", "py", "rust")
+  - Output modes: "content" shows matching lines, "files_with_matches" shows only file paths (default), "count" shows match counts
+  - Use ${AGENT_TOOL_NAME} tool for open-ended searches requiring multiple rounds
+  - Pattern syntax: Uses ripgrep (not grep) - literal braces need escaping (use \`interface\\{\\}\` to find \`interface{}\` in Go code)
+  - Multiline matching: By default patterns match within single lines only. For cross-line patterns like \`struct \\{[\\s\\S]*?field\`, use \`multiline: true\`
 `;
 }

package/dist/src/tools/LSPTool/prompt.js

@@ -1,20 +1,20 @@
 export const LSP_TOOL_NAME = 'LSP';
-export const DESCRIPTION = `Interact with Language Server Protocol (LSP) servers to get code intelligence features.
-
-Supported operations:
-- goToDefinition: Find where a symbol is defined
-- findReferences: Find all references to a symbol
-- hover: Get hover information (documentation, type info) for a symbol
-- documentSymbol: Get all symbols (functions, classes, variables) in a document
-- workspaceSymbol: Search for symbols across the entire workspace
-- goToImplementation: Find implementations of an interface or abstract method
-- prepareCallHierarchy: Get call hierarchy item at a position (functions/methods)
-- incomingCalls: Find all functions/methods that call the function at a position
-- outgoingCalls: Find all functions/methods called by the function at a position
-
-All operations require:
-- filePath: The file to operate on
-- line: The line number (1-based, as shown in editors)
-- character: The character offset (1-based, as shown in editors)
-
+export const DESCRIPTION = `Interact with Language Server Protocol (LSP) servers to get code intelligence features.
+
+Supported operations:
+- goToDefinition: Find where a symbol is defined
+- findReferences: Find all references to a symbol
+- hover: Get hover information (documentation, type info) for a symbol
+- documentSymbol: Get all symbols (functions, classes, variables) in a document
+- workspaceSymbol: Search for symbols across the entire workspace
+- goToImplementation: Find implementations of an interface or abstract method
+- prepareCallHierarchy: Get call hierarchy item at a position (functions/methods)
+- incomingCalls: Find all functions/methods that call the function at a position
+- outgoingCalls: Find all functions/methods called by the function at a position
+
+All operations require:
+- filePath: The file to operate on
+- line: The line number (1-based, as shown in editors)
+- character: The character offset (1-based, as shown in editors)
+
 Note: LSP servers must be configured for the file type. If no server is available, an error will be returned.`;