{"version":3,"file":"tools-prompt-data.d.ts","sourceRoot":"","sources":["../../../src/core/tools/tools-prompt-data.ts"],"names":[],"mappings":"AAAA;;;GAGG;AA+mBH;;;;;GAKG;AACH,wBAAgB,aAAa,CAAC,QAAQ,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS,CAElE;AAyBD;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAAC,QAAQ,EAAE,MAAM,GAAG,MAAM,CAE3D","sourcesContent":["/**\n * Rich LLM-facing tool prompts.\n * Returns detailed instructions for each tool, covering usage, parameters, and best practices.\n */\n\nconst TOOL_PROMPTS: Record<string, string> = {\n\t/**\n\t * Read tool - file content reading\n\t */\n\tread: `Read file contents.\n\nUsage: Use this tool to read files from the filesystem.\n\nWhen to use:\n- ALWAYS use read instead of \\`cat\\`, \\`head\\`, \\`tail\\`, or \\`sed\\` to display file contents\n- You MUST read a file before editing it\n- Read configuration files, source code, documentation, and any text-based files\n- Use before modifying any file to understand its current state\n\nParameters:\n- path: Relative or absolute path to the file\n- offset: Line number to start reading from (1-indexed), optional\n- limit: Maximum number of lines to read, optional\n\nBehavior:\n- Returns file contents up to the limits specified\n- For large files, use offset and limit to read in chunks\n- Binary files (images, executables, etc.) are not readable - will return an error\n- Respects the working directory configured for the tool\n\nBest practices:\n- Always read before editing to understand the exact content\n- Use offset/limit for large files instead of shell commands like head/tail\n- Read files completely when you need to understand the full context`,\n\n\t/**\n\t * Bash tool - command execution\n\t */\n\tbash: `Execute bash commands in the terminal.\n\nUsage: Run shell commands for operations not covered by specialized tools.\n\nWhen to use:\n- Git operations (commit, push, pull, branch management)\n- Running build scripts, tests, or development servers\n- System operations (process management, environment variables)\n- Operations requiring shell features (pipes, redirects, conditionals)\n- Any command not covered by specialized tools (read, grep, find, ls, edit, write)\n\nParameters:\n- command: The shell command to execute\n- timeout: Optional timeout in seconds (default varies by configuration)\n- cwd: Working directory for the command (defaults to configured directory)\n\nBehavior:\n- Commands run in a shell environment (bash)\n- The working directory persists between commands\n- Shell state does NOT persist (environment is re-initialized each call)\n- Returns stdout and stderr output\n\nSafety notes:\n- DO NOT run destructive commands unless explicitly instructed:\n  - \\`git reset --hard\\`, \\`git clean -fd\\`, \\`git branch -D\\`\n  - \\`rm -rf\\` without verification\n  - Force pushes to main/master branches\n- Prefer specific file operations over \\`git add -A\\` or \\`git add .\\`\n- Always verify paths before operations that modify files\n\nBest practices:\n- Use absolute paths to avoid working directory issues\n- Chain dependent commands with \\`&&\\` or \\`;\\`\n- Run independent commands in parallel when possible\n- Check command exit status when operations depend on success — a non-zero exit code means the command failed\n- Use appropriate timeouts for long-running operations\n- Classify commands before execution: SHORT (fast, foreground), LONG_RUNNING (needs timeout), PERSISTENT (servers/watchers — use start/stop scripts, never run indefinitely in foreground)\n- On Linux: use native Bash syntax, POSIX paths, and Bourne-shell-compatible quoting\n- On Windows via Git Bash: prefer the powershell tool for Windows-native operations; use bash for cross-platform git/script commands\n- Do NOT use \\`nohup\\`, bare \\`&\\`, or unowned background processes`,\n\n\t/**\n\t * PowerShell tool - Windows-first command execution\n\t */\n\tpowershell: `Execute PowerShell commands in the terminal.\n\nUsage: Run Windows-first shell commands for workflows that need real PowerShell semantics.\n\nWhen to use:\n- Windows and Unity workflows that rely on PowerShell cmdlets or Windows-native tools\n- PowerShell-specific scripting, pipelines, and object-oriented command composition\n- Native Windows automation where bash semantics would be the wrong fit\n- Any task where the user explicitly wants PowerShell instead of bash\n- Managing Windows processes, listeners, services, and paths\n- Use for persistent server processes (Next.js, dev servers) instead of nohup or Git Bash backgrounding\n\nParameters:\n- command: The PowerShell command to execute\n- timeout: Optional timeout in seconds (default varies by configuration)\n\nBehavior:\n- Commands run in a PowerShell host with standard execution flags\n- The working directory persists between commands\n- Shell state does NOT persist (environment is re-initialized each call)\n- On Windows, prefers PowerShell 7 (pwsh) and falls back to Windows PowerShell when needed\n- On non-Windows hosts, requires PowerShell 7+ (pwsh)\n- Returns combined stdout and stderr output\n- Output encoding is forced to UTF-8 via -EncodedCommand wrapper\n- A health probe runs on first invocation; if transport is broken (encoding mismatch), execution fails with JENSEN_POWERSHELL_TRANSPORT_BROKEN\n\nSafety notes:\n- Do NOT use PowerShell for dedicated built-in file tools when read/grep/find/ls/edit/write are available\n- Do NOT run destructive commands unless explicitly instructed\n- Prefer explicit file paths and PowerShell call syntax when invoking Windows executables with spaces\n- Do NOT fall back to Git Bash when PowerShell transport fails. PowerShell failures are infrastructure errors, not a signal to use bash instead.\n- Treat (no output) from a probe command that should produce output as a transport failure, not an empty result.\n\nBest practices:\n- Keep PowerShell usage explicit and intentional; do not assume bash syntax applies\n- Use PowerShell cmdlets and quoting rules correctly for Windows paths and arguments\n- Use appropriate timeouts for long-running commands\n- Prefer the dedicated built-in file tools over shell-based file inspection when available\n- For port checking: use Get-NetTCPConnection with $_.LocalPort, not $.LocalPort\n- For process details (CommandLine): use Get-CimInstance Win32_Process, not Get-Process ... CommandLine\n- Apply timeouts to HTTP requests, tests, and polling loops\n- Use the process_manager tool for persistent servers, not nohup, &, or Git Bash backgrounding\n- When executing PowerShell remotely via SSH: the controller command is in Bash, but the payload runs in PowerShell. Do not send Bash syntax as the PowerShell payload.\n- For remote PowerShell via SSH, prefer -EncodedCommand with UTF-16LE Base64 encoding for reliable quoting, exit code propagation, and Unicode. Use -Command only for trivial single-statements without pipes or special characters.\n- Use $ErrorActionPreference = 'Stop' in remote scripts to convert non-terminating cmdlet errors into catchable failures.\n- Use $ProgressPreference = 'SilentlyContinue' to suppress CLIXML progress noise in EncodedCommand output.\n- [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new() helps preserve Unicode characters in pipeline output.\n- $LASTEXITCODE applies to native executables only (cmd.exe, .exe). Cmdlet errors use try/catch or $ErrorActionPreference. Propagate the remote exit code back through the SSH process with an explicit exit statement.\n- For complex payloads, prefer: (1) EncodedCommand with UTF-16LE Base64, (2) a temporary script file with controlled lifecycle. Avoid fragile multi-layer manual quoting.\n- Never interpolate untrusted data (paths, user input) directly into PowerShell source. Use EncodedCommand or parameterized scripts.`,\n\n\t/**\n\t * Edit tool - surgical file modifications\n\t */\n\tedit: `Make surgical edits to files by finding exact text and replacing it.\n\nUsage: Modify specific portions of existing files without rewriting the entire file.\n\nWhen to use:\n- Change a specific function or method\n- Update configuration values\n- Fix bugs in existing code\n- Add or remove specific lines\n- Any targeted modification to file contents\n\nParameters:\n- path: Path to the file to edit\n- oldText: EXACT text to find in the file (must match exactly, including whitespace)\n- newText: New text to replace the old text with\n\nCritical rules:\n- oldText MUST match the file content exactly - every character, whitespace, and newline\n- Use the read tool first to get the exact content\n- The edit replaces the first occurrence of oldText in the file\n- If oldText appears multiple times, only the first occurrence is replaced\n\nCommon pitfalls:\n1. Whitespace mismatches: Copy EXACTLY from the file, including indentation\n2. Missing newlines: Ensure newText has appropriate line endings\n3. Partial matches: oldText must be a complete, unique section\n4. Regex escaping: This is NOT regex - treat all characters as literals\n5. Multi-line edits: Include all lines from start to end of the section being replaced\n\nBest practices:\n- ALWAYS read the file first to get exact content\n- Use small, specific oldText chunks to minimize mismatch risk\n- Verify the edit worked by reading the file again\n- If multiple edits are needed in the same file, make them in separate calls\n- For large rewrites, consider using write instead`,\n\n\t/**\n\t * Write tool - file creation and overwrite\n\t */\n\twrite: `Create new files or completely overwrite existing files.\n\nUsage: Create new files or replace entire file contents.\n\nWhen to use:\n- Creating brand new files that don't exist\n- Completely rewriting an existing file (not partial edits)\n- Generating files from templates\n- Writing configuration files, source code, or documentation\n\nParameters:\n- path: Path to the file to write (relative or absolute)\n- content: The complete file content to write\n\nBehavior:\n- Creates the file if it doesn't exist\n- OVERWRITES the entire file if it exists (complete replacement)\n- Does NOT append to existing content\n- Creates parent directories automatically if needed\n\nImportant:\n- This is a complete file replacement, NOT a partial update\n- For partial modifications to existing files, use the edit tool instead\n- Always read existing files before overwriting to understand current state\n- Be certain you want to replace ALL content when using this tool\n\nBest practices:\n- Use for new files or complete rewrites only\n- Use edit for partial modifications to existing files\n- Verify the file was written correctly by reading it back\n- Ensure proper file encoding (UTF-8)`,\n\n\t/**\n\t * Grep tool - content search\n\t */\n\tgrep: `Search file contents for patterns using ripgrep.\n\nUsage: Find text within files using regex or literal patterns.\n\nWhen to use:\n- Search for function definitions, variable names, or imports\n- Find all occurrences of a string or pattern across files\n- Search within specific file types (e.g., only .ts files)\n- When you need to find where something is defined or used\n- Content search respects .gitignore by default\n\nParameters:\n- pattern: Search pattern (regex or literal string)\n- path: Directory or file to search in (default: current directory)\n- glob: Optional glob pattern to filter files (e.g., \"*.ts\", \"**/*.js\")\n- ignoreCase: Case-insensitive search (default: false)\n- literal: Treat pattern as literal string instead of regex (default: false)\n- context: Number of lines to show before and after each match (default: 0)\n\nBehavior:\n- Respects .gitignore - won't search ignored files/directories\n- Supports regex patterns for powerful search\n- Can limit search to specific file types with glob\n- Returns matching lines with file paths and line numbers\n\nWhen to prefer over bash grep:\n- Faster and more efficient for most searches\n- Automatically respects .gitignore\n- Better regex support (PCRE-like)\n- Outputs structured results with line numbers\n- Parallel search by default\n\nBest practices:\n- Use glob to limit search to relevant file types\n- Use ignoreCase for case-insensitive searches\n- Use context to see surrounding lines\n- Use literal for simple string searches to avoid regex issues`,\n\n\t/**\n\t * Find tool - file glob search\n\t */\n\tfind: `Find files by glob pattern matching.\n\nUsage: Locate files matching specific patterns in the filesystem.\n\nWhen to use:\n- Find all files of a certain type (e.g., all .ts files)\n- Search for files with specific naming patterns\n- Discover project structure and file organization\n- Find configuration files, test files, or source files\n- Respects .gitignore by default\n\nParameters:\n- pattern: Glob pattern to match files (e.g., \"*.ts\", \"**/*.js\", \"src/**/*.test.ts\")\n- path: Directory to search in (default: current directory)\n- limit: Maximum number of results (default: 1000)\n\nBehavior:\n- Respects .gitignore - won't return ignored files/directories\n- Supports standard glob patterns:\n  - * matches any characters in a single path component\n  - ** matches any characters across path components (recursive)\n  - ? matches a single character\n  - [abc] matches character classes\n- Returns file paths relative to the search directory\n\nWhen to prefer over bash find:\n- Faster and more intuitive for common patterns\n- Automatically respects .gitignore\n- Simpler syntax for typical use cases\n- Better output formatting\n\nBest practices:\n- Use ** for recursive searches (e.g., \"**/*.ts\" for all TypeScript files)\n- Use * for non-recursive searches within a directory\n- Combine with grep tool for finding files containing specific content\n- Use appropriate limits to avoid overwhelming output`,\n\n\t/**\n\t * Ls tool - directory listing\n\t */\n\tls: `List directory contents.\n\nUsage: Display files and directories in a specified location.\n\nWhen to use:\n- Explore directory structure\n- Verify files exist before operations\n- See what files are in a directory\n- Check directory organization\n- Respects .gitignore by default (doesn't list ignored files)\n\nParameters:\n- path: Directory to list (default: current directory)\n- limit: Maximum number of entries to return (default: 500)\n\nBehavior:\n- Returns entries sorted alphabetically\n- Directories are marked with '/' suffix\n- Includes dotfiles (files starting with .)\n- Respects .gitignore - won't list ignored files/directories\n\nWhen to prefer over bash ls:\n- Faster and more efficient for exploration\n- Automatically respects .gitignore\n- Structured output that's easier to parse\n- Better defaults for code exploration\n\nBest practices:\n- Use to verify directory contents before creating files\n- Check parent directory exists before creating new files\n- Use after file operations to verify success\n- Explore project structure systematically`,\n\n\t/**\n\t * Todo write tool - task/todo list management\n\t */\n\ttodo_write: `Update the session's structured task/todo list for multi-step workflows.\n\nUsage: Create and track a list of tasks to complete. This provides visible progress tracking during execution.\n\nWhen to use proactively:\n- The user provides a list of things to do (treat each as a todo item)\n- Work spans multiple files or distinct phases\n- Starting complex work without a clear plan (create todos as your plan)\n\nParameters:\n- todos: Array of task objects with:\n  - id: Optional stable identifier from a prior todo_read or write. Omit for new items; preserved on replacement.\n  - content: Imperative description of what needs to be done (e.g., \"Implement user authentication\")\n  - activeForm: Present continuous form shown during execution (e.g., \"Implementing user authentication\")\n  - status: One of \"pending\", \"in_progress\", or \"completed\"\n- confirmClear: Optional boolean. Set to true explicitly when passing empty todos to clear the list.\n\nSemantics:\n- FULL LIST REPLACEMENT: Each call completely replaces the previous list — include ALL current todos in every call\n- Use todo_update for status or progress transitions.\n- Use todo_read when the current IDs or revision are not available.\n- Do not reconstruct or replace the entire list merely to complete one item.\n- Mark tasks in_progress when you start working on them, completed when done\n- Mark tasks complete IMMEDIATELY after finishing (do not leave them in_progress)\n- Exactly ONE task should be in_progress at any time during active work\n- To view the current todo list without modifying it, call todo_read instead of todo_write\n\nWhen NOT to use:\n- For status progressions of existing items — use todo_update instead\n- Single trivial operations (just do them directly)\n- Quick file reads or lookups\n- Tasks better tracked mentally\n\nExamples:\n- Start workflow: todos=[{content: \"Read existing code\", activeForm: \"Reading existing code\", status: \"pending\"}, {content: \"Implement feature\", activeForm: \"Implementing feature\", status: \"pending\"}]\n- Clear list: todos=[], confirmClear=true (when all tasks are done)`,\n\n\t/**\n\t * Todo read tool - task/todo list inspection\n\t */\n\ttodo_read: `Read the session's structured task/todo list without modifying it.\n\nUsage: Retrieve the current state, task items with stable IDs, and revision number of the active todo list.\n\nWhen to use:\n- You need to inspect existing todos without modifying state\n- You want to verify active tasks before making updates\n- You need stable IDs or the current revision number for a todo_update call\n\nParameters: None\n\nReturns stable IDs and current revision for use with todo_update. Use todo_update for progress transitions, not todo_write.`,\n\n\t/**\n\t * Todo update tool - partial progress transitions\n\t */\n\ttodo_update: `Apply partial progress transitions to the todo list without replacing the entire list.\n\nUsage: Mark items as in_progress or completed, or update activeForm/content fields, using stable IDs from todo_read or a prior todo_write.\n\nWhen to use:\n- Mark a task as in_progress when you start working on it\n- Mark a task as completed when you finish it\n- Update activeForm to reflect current work phrasing\n- Transition exactly ONE task to in_progress at a time\n\nParameters:\n- updates: Array of partial updates, each with:\n  - id: Stable identifier of the todo item to update (from todo_read)\n  - status: New status - \"pending\", \"in_progress\", or \"completed\" (optional)\n  - activeForm: Updated present continuous form (optional)\n  - content: Updated task description (optional)\n- expectedRevision: Current revision number from todo_read or the last successful mutation. Prevents stale updates.\n\nWhen NOT to use:\n- You don't know the current IDs or revision — call todo_read first\n- Creating new todo items — use todo_write instead\n- Clearing all todos — use todo_write with confirmClear: true\n- You want to replace the entire list — use todo_write instead\n\nExamples:\n- Mark first item as in_progress: updates=[{id: \"td_xxx_1\", status: \"in_progress\"}], expectedRevision=3\n- Complete first and start second: updates=[{id: \"td_xxx_1\", status: \"completed\"}, {id: \"td_xxx_2\", status: \"in_progress\"}], expectedRevision=3\n- Update activeForm: updates=[{id: \"td_xxx_1\", activeForm: \"Refactoring auth module\"}], expectedRevision=3`,\n\n\t/**\n\t * Memory write tool - structured session memory\n\t */\n\tmemory_write: `Record or clear structured session memory that must survive compaction.\n\nUsage: Store stable facts, constraints, decisions, or working context that should remain visible on future turns even after conversation history is compacted.\n\nWhen to use:\n- Stable constraints from the user (e.g., \"never run npm test\", \"do not modify reference repo\")\n- Important decisions that later turns must respect\n- Working context that is likely to matter after compaction\n- Facts that complement, but do not replace, the active todo list\n\nParameters:\n- action: \"set\" to store/update a memory item, \"clear\" to remove all session memory\n- key: Short stable key (required for action=set), such as \"constraints.test_command\"\n- value: Memory value (required for action=set)\n\nSemantics:\n- Session-local persistence: memory is saved in the session and restored on resume\n- Compaction-safe: memory is injected into the real model-facing context path after compaction\n- Prefer concise, durable facts over noisy notes\n- Update an existing key by calling action=set with the same key\n- Clear everything only when the stored memory is no longer trustworthy or relevant\n\nWhen NOT to use:\n- Temporary step-by-step task progress (use todo_write)\n- Large notes or raw transcripts\n- Facts that are already obvious from current prompt context\n- Speculative information that may go stale quickly`,\n\n\t/**\n\t * Process manager tool - persistent background process management on Windows\n\t */\n\tprocess_manager: `Manage persistent background processes on Windows via PowerShell.\n\nUsage: Start, monitor, and stop long-running processes without Git Bash or nohup.\n\nWhen to use:\n- Starting a Next.js dev server (npm run dev)\n- Starting any persistent HTTP listener\n- Managing background processes on Windows\n- Checking if a managed process is still alive\n- Stopping a process started by this tool\n- Never use nohup, Git Bash &, or shell wrappers for persistent processes on Windows\n\nActions:\n- start: Launch a new background process. Required params: command, optional: cwd, expectedPort, readyTimeout.\n- status: Check if a managed process is running. Required: runId.\n- stop: Terminate a managed process. Required: runId.\n- list: Show all managed processes.\n\nParameters:\n- action: \"start\", \"status\", \"stop\", or \"list\"\n- command: The full command to execute (for start). Example: \"npm run dev -- -p 3000\"\n- cwd: Working directory (defaults to current)\n- expectedPort: TCP port the process should listen on. Enables readiness polling with port-ownership verification.\n- readyTimeout: Max seconds to wait for readiness (default 30, max 45)\n- runId: The run ID returned by start (required for status and stop)\n\nBehavior:\n- On start: spawns process via PowerShell Start-Process, redirects stdout/stderr to log files, returns runId and root PID\n- Polls for readiness when expectedPort is given: verifies port owner belongs to the process tree\n- Never declares \"ready\" just because a port is occupied -- verifies PID tree ownership\n- If port is owned by a foreign process, returns a clear conflict error\n- On stop: kills only processes registered by this tool, never unknown PIDs\n- On status: checks if root PID is alive, reports stdout/stderr log paths\n\nSafety notes:\n- Never kills unknown processes\n- Only stops processes registered by this session\n- Port ownership is verified before declaring readiness\n- Readiness polling is limited to max 45 seconds`,\n\n\t/**\n\t * Task create tool - structured multi-step work tracking\n\t */\n\ttask_create: `Create a structured task for multi-step work tracking.\n\nUsage: Create a new explicit work item that can be inspected, updated, and tracked across the session.\n\nWhen to use:\n- The work is multi-step and spans multiple tool calls or turns\n- The work has a clear deliverable that should be tracked explicitly\n- The work is complex enough that it benefits from having a separate subject and description\n- You want to give the model explicit awareness of a work item it is currently doing\n- Use task_update to mark it in_progress when you start working on it\n\nWhen to use vs task_list:\n- Always call task_list FIRST to check for existing tasks and avoid duplicates\n- Only create a new task if no existing task covers the work\n\nParameters:\n- subject: Brief title/subject of the task (required)\n- description: Detailed description of what the task involves\n- activeForm: Strongly recommended — active-form phrasing shown when task is in_progress (e.g., \"Implementing feature X\")\n- metadata: Optional free-form metadata object\n\nStatus transitions:\n- After creating, use task_update to mark the task as in_progress before starting work\n- When the deliverable is complete, use task_update to mark it as completed\n- Keep status in_sync with actual work state\n\nMeaningful tasks only:\n- Do NOT create a task for every trivial step; reserve tasks for meaningful multi-step work\n- A task should represent a coherent unit of work, not a single command\n- Quick lookups, file reads, or exploratory work do not need tasks\n\nAnti-patterns:\n- Do NOT create a task and then never update its status\n- Do NOT confuse tasks with todo_write items — tasks have explicit id/subject/description and are designed for model-visible work tracking\n\nExamples:\n- Create a task before starting multi-file refactoring\n- Create a task when the user assigns a complex feature to implement\n- Create a task when you need to track a complex investigation across multiple steps`,\n\n\t/**\n\t * Task list tool - list all structured tasks\n\t */\n\ttask_list: `List all structured tasks with their current status.\n\nUsage: Get a summary view of all tasks grouped by status (pending, in_progress, completed).\n\nWhen to use:\n- Before creating a new task: ALWAYS check here first to avoid duplicates\n- You want to check the current state of all tracked work\n- You are about to start new work and want to know what is already in progress\n- You need to assess what remains before wrapping up\n\nWhen to use vs task_get:\n- Use task_list for a summary view or when you don't have a specific task ID\n- Use task_get when you have a task ID and need full details\n\nParameters: None\n\nExamples:\n- List tasks before creating a new one to check for overlap\n- List tasks at the start of a session to assess current state\n- List tasks before updating status to see the full picture`,\n\n\t/**\n\t * Task get tool - retrieve a specific task by ID\n\t */\n\ttask_get: `Retrieve full details of a specific task by its ID.\n\nUsage: Inspect a single task's subject, description, status, activeForm, and metadata.\n\nWhen to use:\n- You have a task ID and need to see the full task details\n- You need the current status before updating\n- You want to verify task state after resuming a session\n- You are about to update a task and want to confirm the current values\n\nParameters:\n- taskId: The unique ID of the task (required)\n\nWhen NOT to use:\n- You don't know the task ID — use task_list first\n- You want to update multiple tasks — use task_update directly with known IDs\n- You just want a summary — use task_list instead\n\nExamples:\n- Get task details before updating status\n- Verify a task exists after session resume\n- Read description to understand what a task involves before working on it\n\nAnti-patterns:\n- Do NOT use task_get to list all tasks — use task_list instead`,\n\n\t/**\n\t * Task update tool - update an existing task's fields\n\t */\n\ttask_update: `Update one or more fields of an existing task.\n\nUsage: Modify task status, subject, description, activeForm, or metadata.\n\nWhen to use:\n- Mark a task as in_progress when you start working on it\n- Mark a task as completed when you finish it\n- Update the subject or description if requirements change\n- Change the activeForm to reflect current work phrasing\n- Update metadata to record progress or decisions\n\nStatus transition rules:\n- pending → in_progress: Mark when you begin working on a task\n- in_progress → completed: Mark immediately when the deliverable is done\n- Exactly ONE task should be in_progress at any time\n- Do not leave tasks in_progress after finishing — mark them completed immediately\n\nWhen NOT to use:\n- You don't know the task ID — use task_list first\n- You want to create a new task — use task_create instead\n- You want to see task details — use task_get instead\n\nParameters:\n- taskId: The unique ID of the task to update (required)\n- subject: New subject/title (optional)\n- description: New description (optional)\n- status: New status — \"pending\", \"in_progress\", or \"completed\" (optional)\n- activeForm: New active-form phrasing for in_progress display (optional)\n- metadata: Replacement metadata object (optional)\n\nAnti-patterns:\n- Do NOT update a task you did not create or verify exists\n- Do NOT leave a task in_progress when you finish — update to completed immediately\n- Do NOT use task_update to create tasks — use task_create instead\n\nExamples:\n- Update task status to in_progress when starting work\n- Update task status to completed when done\n- Update activeForm to show \"Refactoring authentication module\" while in_progress`,\n};\n\n/**\n * Get rich LLM-facing prompt instructions for a specific tool.\n *\n * @param toolName - Name of the tool (read, bash, edit, write, grep, find, ls, todo_write, memory_write)\n * @returns Rich prompt instructions for the tool, or undefined if no rich prompt exists\n */\nexport function getToolPrompt(toolName: string): string | undefined {\n\treturn TOOL_PROMPTS[toolName];\n}\n\n/**\n * Get a fallback one-line description for tools without rich prompts.\n */\nconst FALLBACK_DESCRIPTIONS: Record<string, string> = {\n\tread: \"Read file contents\",\n\tbash: \"Execute bash commands (ls, grep, find, etc.)\",\n\tpowershell: \"Execute PowerShell commands with Windows-first semantics\",\n\tedit: \"Make surgical edits to files (find exact text and replace)\",\n\twrite: \"Create or overwrite files\",\n\tgrep: \"Search file contents for patterns (respects .gitignore)\",\n\tfind: \"Find files by glob pattern (respects .gitignore)\",\n\tls: \"List directory contents\",\n\ttodo_write: \"Update the session's structured task/todo list for multi-step workflows\",\n\ttodo_read: \"Read the session's structured task/todo list without modifying it\",\n\ttodo_update: \"Apply partial progress transitions to the todo list without replacing the entire list\",\n\tmemory_write: \"Record or clear structured session memory that survives compaction\",\n\tprocess_manager: \"Manage persistent background processes on Windows (start, status, stop, list)\",\n\ttask_create: \"Create a structured task for multi-step work tracking\",\n\ttask_list: \"List all structured tasks with their current status\",\n\ttask_get: \"Retrieve full details of a specific task by its ID\",\n\ttask_update: \"Update an existing task's fields (status, subject, description, etc.)\",\n};\n\n/**\n * Get tool description - rich prompt if available, otherwise fallback.\n *\n * @param toolName - Name of the tool\n * @returns Rich prompt or one-line fallback description\n */\nexport function getToolDescription(toolName: string): string {\n\treturn TOOL_PROMPTS[toolName] ?? FALLBACK_DESCRIPTIONS[toolName] ?? toolName;\n}\n"]}