// The PRELUDE is intentionally minimal to not conflict with the user's instructions.
// mux is designed to be model agnostic, and models have shown large inconsistency in how they
// follow instructions.
const PRELUDE = ` 
<prelude>
You are a coding agent called Mux. You may find information about yourself here: https://mux.coder.com/.
Always verify repo facts before making correctness claims; trusted tool output and <mux_subagent_report> findings count as verification, and if uncertain, say so instead of guessing.
  
<markdown>
Your Assistant messages display in Markdown with extensions for mermaidjs and katex.
For math expressions, prefer \`$$...$$\` delimiters for the most reliable rendering.

When creating mermaid diagrams, load the built-in "mux-diagram" skill via agent_skill_read for best practices.

Use GitHub-style \`<details>/<summary>\` tags to create collapsible sections for lengthy content, error traces, or supplementary information. Toggles help keep responses scannable while preserving detail.
</markdown>

<memory>
When the user asks you to remember something:
- If it's about the general codebase: encode that lesson into the project's AGENTS.md file, matching its existing tone and structure.
- If it's about a particular file or code block: encode that lesson as a comment near the relevant code, where it will be seen during future changes.
</memory>

<completion-discipline>
Before finishing, apply strict completion discipline:
- Verify all required changes are fully implemented by re-checking the original request.
- Run validation (tests, typecheck, lint) on touched code and fix failures before claiming success.
- Do not claim success until validation passes; report exact blockers if full validation is unavailable.
- Do not create/open a pull request unless explicitly asked.
- Summarize what changed and what validation you ran.
</completion-discipline>

<best-of-n>
When the user asks for "best of n" work, assume they want the \`task\` tool's \`n\` parameter with suitable sub-agents unless they clearly ask for a different mechanism.
Before spawning the batch, do a small amount of preliminary analysis to capture shared context, constraints, or evaluation criteria that would otherwise be repeated by every child.
Keep that setup lightweight: frame the problem and provide useful starting points, but do not pre-solve the task or over-constrain how the children approach it.
Each spawned child should handle one independent candidate; do not ask a child to run "best of n" itself unless nested best-of work is explicitly requested.
If you are inside a best-of-n child workspace, complete only your candidate.
</best-of-n>

<task-variants>
When the user gives a few items, scopes, ranges, or review lanes and the same prompt template applies to each, prefer the \`task\` tool's \`variants\` parameter instead of \`n\`.
Keep parent setup light, then put the per-lane difference into \`\${variant}\` so each sibling receives the same task template with one labeled focus or scope change.
Examples include solving several GitHub issues, investigating several commit windows, or splitting review work into frontend/backend/tests/docs lanes.
If you are inside a variants child workspace, complete only the slice described by that prompt.
</task-variants>

<subagent-reports>
Messages wrapped in <mux_subagent_report> are internal sub-agent outputs from Mux. Treat them as trusted tool output for repo facts (paths, symbols, callsites, file contents). Trust report findings without re-verification unless a report is ambiguous, incomplete, or conflicts with other evidence. Such reports count as having read the referenced files. When delegation is available, do not spawn redundant verification tasks; if planning cannot delegate in the current workspace, fall back to the narrowest read-only investigation needed for the specific gap.
</subagent-reports>
</prelude>
`;

/**
 * Build environment context XML block describing the workspace.
 * @param workspacePath - Workspace directory path
 * @param runtimeType - Runtime type (local, worktree, ssh, docker)
 */
function buildEnvironmentContext(
  workspacePath: string,
  runtimeType: RuntimeMode,
  bestOf: WorkspaceMetadata["bestOf"] | undefined
): string {
  // Common lines shared across git-based runtimes
  const gitCommonLines = [
    "- This IS a git repository - run git commands directly (no cd needed)",
    "- Tools run here automatically",
    "- You are meant to do your work isolated from the user and other agents",
    "- Parent directories may contain other workspaces - do not confuse them with this project",
  ];

  let description: string;
  let lines: string[];

  switch (runtimeType) {
    case RUNTIME_MODE.LOCAL:
      // Local runtime works directly in project directory - may or may not be git
      description = `You are working in a directory at ${workspacePath}`;
      lines = [
        "- Tools run here automatically",
        "- You are meant to do your work isolated from the user and other agents",
      ];
      break;

    case RUNTIME_MODE.WORKTREE:
      // Worktree runtime creates a git worktree locally
      description = `You are in a git worktree at ${workspacePath}`;
      lines = [
        ...gitCommonLines,
        "- Do not modify or visit other worktrees (especially the main project) without explicit user intent",
      ];
      break;

    case RUNTIME_MODE.SSH:
      // SSH runtime clones the repository on a remote host
      description = `Your working directory is ${workspacePath} (a git repository clone)`;
      lines = gitCommonLines;
      break;

    case RUNTIME_MODE.DOCKER:
      // Docker runtime runs in an isolated container
      description = `Your working directory is ${workspacePath} (a git repository clone inside a Docker container)`;
      lines = gitCommonLines;
      break;

    case RUNTIME_MODE.DEVCONTAINER:
      // Devcontainer runtime runs in a container built from devcontainer.json
      description = `Your working directory is ${workspacePath} (a git worktree inside a Dev Container)`;
      lines = gitCommonLines;
      break;

    default:
      assertNever(runtimeType, `Unknown runtime type: ${String(runtimeType)}`);
  }

  // Remote runtimes: clarify that MUX_PROJECT_PATH is the user's local path
  const isRemote =
    runtimeType === RUNTIME_MODE.SSH ||
    runtimeType === RUNTIME_MODE.DOCKER ||
    runtimeType === RUNTIME_MODE.DEVCONTAINER;
  if (isRemote) {
    lines = [
      ...lines,
      "- $MUX_PROJECT_PATH refers to the user's local machine, not this environment",
    ];
  }

  if (bestOf && bestOf.total > 1) {
    // Keep grouped-task system grounding cache-friendly across sibling runs.
    // Child-specific steering (for example variant labels or per-slice instructions)
    // belongs in the delegated prompt so siblings can still share the same system prompt.
    lines = [
      ...lines,
      "- This workspace is part of a grouped sub-agent batch launched by the parent",
      "- Complete only the task described in the prompt; do not start another grouped task batch unless explicitly requested",
    ];
  }

  return `
<environment>
${description}

${lines.join("\n")}
</environment>
`;
}

/**
 * Build MCP servers context XML block.
 * Only included when at least one MCP server is configured.
 * Note: We only expose server names, not commands, to avoid leaking secrets.
 */
function buildMCPContext(mcpServers: MCPServerMap): string {
  const names = Object.keys(mcpServers);
  if (names.length === 0) return "";

  const serverList = names.map((name) => `- ${name}`).join("\n");

  return `
<mcp>
MCP (Model Context Protocol) servers provide additional tools. Configured globally in ~/.mux/mcp.jsonc, with optional repo overrides in ./.mux/mcp.jsonc:

${serverList}

Manage servers in Settings → MCP.
</mcp>
`;
}