import type { WorkspaceContext } from "../extensions/context"; import type { WorkspaceInfo } from "../session/workspace"; /** * Explains the wrapper and elements the * runtime stamps on user messages (prepareTurnInput / formatUserInputBlock). * Every host that sends through the SDK runtime produces those tags, so every * host's system prompt must explain them: without this section the model has * no idea what the attribute means, and a mid-conversation mode switch is an * invisible system-prompt swap it cannot diff. Included for BOTH modes, since * after a switch the transcript still contains messages tagged with the other * mode. */ export declare const MODE_TAG_INSTRUCTIONS = "# Plan / Act Modes\n\nUser messages arrive wrapped in a tag. The mode attribute is the interaction mode the user was in when they sent that message: \"plan\" means plan-mode constraints applied (explore, analyze, and align on a plan -- no edits or state-changing commands), while \"act\" (or \"yolo\") means implementation was allowed. If the mode attribute changes between messages, the user switched modes -- the newest message's mode is what governs right now, regardless of what earlier messages allowed. A block inside a message marks exactly when such a switch happened."; export declare const PLAN_MODE_INSTRUCTIONS = "# Plan Mode\n\nYou are in Plan mode. Your role is to explore, analyze, and plan -- not to execute.\n\n- Read files, search the codebase, and gather context to understand the problem\n- Ask clarifying questions when requirements are ambiguous\n- Present your plan as a structured outline with clear steps\n- Explain tradeoffs between different approaches when they exist\n- Do NOT edit files, write code, run destructive commands, or make any changes\n- Do NOT implement anything -- focus on understanding and alignment first\n\nThe run_commands tool remains available in plan mode strictly for read-only inspection -- listing files, searching (grep), reading configs, inspecting git history and diffs, checking tool versions, and the like. Never use it to change anything: no creating, modifying, or deleting files, no writing scripts that make changes, and no state-changing commands (installs, migrations, database or schema changes, container commands that mutate state, etc.). File-editing commands (rm/mv/cp, in-place edits like sed -i, output redirection to files outside /tmp, git commands that change the working tree, package installs) are hard-blocked in plan mode: they are not executed and return a tool error instead, so do not attempt them. If the task requires a mutation, put it in the plan; it happens only after the user switches to act mode.\n\nOnce the user has reviewed your plan and explicitly approved it in a follow-up message, use the switch_to_act_mode tool to switch to act mode and begin implementation. Calling switch_to_act_mode immediately starts execution, so never call it in the same turn you present a plan and never treat the original task request as approval -- end your turn after presenting the plan and wait for the user's response."; /** * Plan-mode contract for hosts that do NOT expose the switch_to_act_mode tool * (the VS Code extension, matching the legacy extension's behavior). The model * must direct the user to flip the Plan/Act toggle instead of calling a tool * that does not exist in its toolset. */ export declare const PLAN_MODE_INSTRUCTIONS_MANUAL_SWITCH = "# Plan Mode\n\nYou are in Plan mode. Your role is to explore, analyze, and plan -- not to execute.\n\n- Read files, search the codebase, and gather context to understand the problem\n- Ask clarifying questions when requirements are ambiguous\n- Present your plan as a structured outline with clear steps\n- Explain tradeoffs between different approaches when they exist\n- Do NOT edit files, write code, run destructive commands, or make any changes\n- Do NOT implement anything -- focus on understanding and alignment first\n\nThe run_commands tool remains available in plan mode strictly for read-only inspection -- listing files, searching (grep), reading configs, inspecting git history and diffs, checking tool versions, and the like. Never use it to change anything: no creating, modifying, or deleting files, no writing scripts that make changes, and no state-changing commands (installs, migrations, database or schema changes, container commands that mutate state, etc.). File-editing commands (rm/mv/cp, in-place edits like sed -i, output redirection to files outside /tmp, git commands that change the working tree, package installs) are hard-blocked in plan mode: they are not executed and return a tool error instead, so do not attempt them. If the task requires a mutation, put it in the plan; it happens only after the user switches to act mode.\n\nOnce you have presented your plan, end your turn and wait for the user's response. You do NOT have the ability to switch to act mode yourself -- the user must do it manually with the Plan/Act toggle once they are satisfied with the plan. If the task requires tools that are only available in act mode, ask the user to \"toggle to Act mode\" (use those words)."; export declare function processWorkspaceInfo(info: WorkspaceInfo): string; /** * Options for building the Cline system prompt. * * Extends WorkspaceContext so callers can spread an ExtensionContext.workspace * directly. `workspaceRoot` is accepted as an alias for `rootPath` to support * existing call sites that set it explicitly. */ export interface ClineSystemPromptOptions extends Omit { /** * Workspace root path. Accepts either `rootPath` (from WorkspaceContext/WorkspaceInfo) * or `workspaceRoot` (legacy alias) — whichever is provided will be used. */ rootPath?: string; /** Alias for rootPath — kept for backwards compatibility with existing call sites */ workspaceRoot?: string; /** Per-request system prompt override */ overridePrompt?: string; /** Provider ID — used to gate Cline-specific metadata injection */ providerId?: string; /** * Whether the host exposes the switch_to_act_mode tool in plan mode. * Defaults to true (CLI behavior). Hosts that require the user to flip the * Plan/Act toggle themselves (the VS Code extension) set this to false so * the plan-mode contract directs the model to ask the user instead of * calling a tool that is not in its toolset. */ planModeSwitchTool?: boolean; } export declare function buildClineSystemPrompt(options: ClineSystemPromptOptions): string;