chore: fix typos and GitHub capitalization (#12852)

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

@@ -56,7 +56,7 @@ user: which file contains the implementation of foo?
 assistant: src/foo.c
 </example>
 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.
+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.
 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/anthropic.txt

@@ -13,7 +13,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.
+- 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.
 - 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/beast.txt

@@ -76,7 +76,7 @@ Carefully read the issue and think hard about a plan to solve it before coding.
 - Create a todo list in markdown format to track your progress.
 - Each time you complete a step, check it off using `[x]` syntax.
 - Each time you check off a step, display the updated todo list to the user.
-- Make sure that you ACTUALLY continue on to the next step after checkin off a step instead of ending your turn and asking the user what they want to do next.
+- Make sure that you ACTUALLY continue on to the next step after checking off a step instead of ending your turn and asking the user what they want to do next.
 
 ## 6. Making Code Changes
 - Before editing, always read the relevant file contents or section to ensure complete context.

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

@@ -60,7 +60,7 @@ You are producing plain text that will later be styled by the CLI. Follow these
 
 ## Final answer structure and style guidelines
 
-- Plain text; CLI handles styling. Use structure only when it helps scanability.
+- Plain text; CLI handles styling. Use structure only when it helps scannability.
 - Headers: optional; short Title Case (1-3 words) wrapped in **…**; no blank line before the first bullet; add only if they truly help.
 - 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 **.

packages/opencode/src/session/prompt/copilot-gpt-5.txt

@@ -39,7 +39,7 @@ incremental steps - use the todo tool to track your progress.
 - What are the edge cases?
 - What are the potential pitfalls?
 - How does this fit into the larger context of the codebase?
-- What are the dependencies and interactions with other parts of the codee
+- What are the dependencies and interactions with other parts of the code
 
 ## 2. Codebase Investigation
 - Explore relevant files and directories.

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

@@ -12,7 +12,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.
+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.
 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

@@ -2,7 +2,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.
+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.
 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/tool/bash.txt

@@ -87,7 +87,7 @@ Important notes:
 - If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
 
 # Creating pull requests
-Use the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a Github URL use the gh command to get the information needed.
+Use the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a GitHub URL use the gh command to get the information needed.
 
 IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:
 
@@ -112,4 +112,4 @@ Important:
 - Return the PR URL when you're done, so the user can see it
 
 # Other common operations
-- View comments on a Github PR: gh api repos/foo/bar/pulls/123/comments
+- View comments on a GitHub PR: gh api repos/foo/bar/pulls/123/comments