fix(opencode): instruct all chat agents to use KaTeX-compatible math syntax

packages/opencode/src/session/prompt/anthropic.txt

@@ -14,6 +14,7 @@ When the user directly asks about OpenCode (eg. "can OpenCode do...", "does Open
 # Tone and style
 - Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
 - Your output will be displayed on a command line interface. Your responses should be short and concise. You can use GitHub-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification.
+- {MATH_FORMATTING_RULES}
 - Output text to communicate with the user; all text you output outside of tool use is displayed to the user. Only use tools to complete tasks. Never use tools like Bash or code comments as means to communicate with the user during the session.
 - NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one. This includes markdown files.
 

packages/opencode/src/session/prompt/codex_header.txt

@@ -65,6 +65,7 @@ You are producing plain text that will later be styled by the CLI. Follow these
 - Bullets: use - ; merge related points; keep to one line when possible; 4–6 per list ordered by importance; keep phrasing consistent.
 - Monospace: backticks for commands/paths/env vars/code ids and inline examples; use for literal keyword bullets; never combine with **.
 - Code samples or multi-line snippets should be wrapped in fenced code blocks; include an info string as often as possible.
+- {MATH_FORMATTING_RULES}
 - Structure: group related bullets; order sections general → specific → supporting; for subsections, start with a bolded keyword bullet, then items; match complexity to the task.
 - Tone: collaborative, concise, factual; present tense, active voice; self‑contained; no "above/below"; parallel wording.
 - Don'ts: no nested bullets/hierarchies; no ANSI codes; don't cram unrelated keywords; keep keyword lists short—wrap/reformat if long; avoid naming formatting styles in answers.

packages/opencode/src/session/prompt/gemini.txt

@@ -42,6 +42,7 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 - **Clarity over Brevity (When Needed):** While conciseness is key, prioritize clarity for essential explanations or when seeking necessary clarification if a request is ambiguous.
 - **No Chitchat:** Avoid conversational filler, preambles ("Okay, I will now..."), or postambles ("I have finished the changes..."). Get straight to the action or answer.
 - **Formatting:** Use GitHub-flavored Markdown. Responses will be rendered in monospace.
+- {MATH_FORMATTING_RULES}
 - **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls or code blocks unless specifically part of the required code/command itself.
 - **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly (1-2 sentences) without excessive justification. Offer alternatives if appropriate.
 

packages/opencode/src/session/prompt/math_formatting_rules.txt

@@ -0,0 +1,12 @@
+Math formatting:
+  * Inline LaTeX equations: use `$...$` (never `\( ... \)`)
+  * Prefer display equations for complex formulas or multi-term expressions.
+  * Display equations: use `$$ ... $$` (never `\[ ... \]`), with a blank line before the opening `$$` and after the closing `$$`.
+  * Display equations: the `$$` delimiter lines must be flush-left (no indentation), or some renderers treat it as code.
+  * Example (with required blank lines):
+
+$$
+E = mc^2
+$$
+
+  * Do not wrap display equations in code fences (this prevents rendering in the browser).

packages/opencode/src/session/prompt/qwen.txt

@@ -13,6 +13,7 @@ When the user directly asks about opencode (eg 'can opencode do...', 'does openc
 # Tone and style
 You should be concise, direct, and to the point. When you run a non-trivial bash command, you should explain what the command does and why you are running it, to make sure the user understands what you are doing (this is especially important when you are running a command that will make changes to the user's system).
 Remember that your output will be displayed on a command line interface. Your responses can use GitHub-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification.
+{MATH_FORMATTING_RULES}
 Output text to communicate with the user; all text you output outside of tool use is displayed to the user. Only use tools to complete tasks. Never use tools like Bash or code comments as means to communicate with the user during the session.
 If you cannot or will not help the user with something, please do not say why or what it could lead to, since this comes across as preachy and annoying. Please offer helpful alternatives if possible, and otherwise keep your response to 1-2 sentences.
 Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.

packages/opencode/src/session/prompt/trinity.txt

@@ -3,6 +3,7 @@ You are opencode, an interactive CLI tool that helps users with software enginee
 # Tone and style
 You should be concise, direct, and to the point. When you run a non-trivial bash command, you should explain what the command does and why you are running it, to make sure the user understands what you are doing (this is especially important when you are running a command that will make changes to the user's system).
 Remember that your output will be displayed on a command line interface. Your responses can use GitHub-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification.
+{MATH_FORMATTING_RULES}
 Output text to communicate with the user; all text you output outside of tool use is displayed to the user. Only use tools to complete tasks. Never use tools like Bash or code comments as means to communicate with the user during the session.
 If you cannot or will not help the user with something, please do not say why or what it could lead to, since this comes across as preachy and annoying. Please offer helpful alternatives if possible, and otherwise keep your response to 1-2 sentences.
 Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.

packages/opencode/src/session/system.ts

@@ -9,21 +9,27 @@ import PROMPT_GEMINI from "./prompt/gemini.txt"
 
 import PROMPT_CODEX from "./prompt/codex_header.txt"
 import PROMPT_TRINITY from "./prompt/trinity.txt"
+import PROMPT_MATH_FORMATTING_RULES from "./prompt/math_formatting_rules.txt"
 import type { Provider } from "@/provider/provider"
 
+function inject(prompt: string): string {
+  const rules = PROMPT_MATH_FORMATTING_RULES.trim()
+  return prompt.replace("{MATH_FORMATTING_RULES}", () => rules)
+}
+
 export namespace SystemPrompt {
   export function instructions() {
-    return PROMPT_CODEX.trim()
+    return inject(PROMPT_CODEX).trim()
   }
 
   export function provider(model: Provider.Model) {
-    if (model.api.id.includes("gpt-5")) return [PROMPT_CODEX]
+    if (model.api.id.includes("gpt-5")) return [inject(PROMPT_CODEX)]
     if (model.api.id.includes("gpt-") || model.api.id.includes("o1") || model.api.id.includes("o3"))
       return [PROMPT_BEAST]
-    if (model.api.id.includes("gemini-")) return [PROMPT_GEMINI]
-    if (model.api.id.includes("claude")) return [PROMPT_ANTHROPIC]
-    if (model.api.id.toLowerCase().includes("trinity")) return [PROMPT_TRINITY]
-    return [PROMPT_ANTHROPIC_WITHOUT_TODO]
+    if (model.api.id.includes("gemini-")) return [inject(PROMPT_GEMINI)]
+    if (model.api.id.includes("claude")) return [inject(PROMPT_ANTHROPIC)]
+    if (model.api.id.toLowerCase().includes("trinity")) return [inject(PROMPT_TRINITY)]
+    return [inject(PROMPT_ANTHROPIC_WITHOUT_TODO)]
   }
 
   export async function environment(model: Provider.Model) {