anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Gemini prompt from anon-kode #736

New Issue
Closed
opened 2026-02-16 17:28:04 -05:00 by yindo · 5 comments
yindo commented 2026-02-16 17:28:04 -05:00
Owner
Copy Link
Copy Source

Originally created by @dnakov on GitHub (Jul 15, 2025).

Originally assigned to: @thdxr on GitHub.

@andrewleech I think it was you who had a PR with a gemini prompt that worked pretty well in ak but didn't get merged before rip, could you share here if you still have?

Originally created by @dnakov on GitHub (Jul 15, 2025). Originally assigned to: @thdxr on GitHub. @andrewleech I think it was you who had a PR with a gemini prompt that worked pretty well in ak but didn't get merged before rip, could you share here if you still have?
yindo closed this issue 2026-02-16 17:28:04 -05:00
yindo commented 2026-02-16 17:28:04 -05:00
Author
Owner
Copy Link
Copy Source

@mstibbard commented on GitHub (Jul 15, 2025):

Was it this one? https://gitee.com/bl1zz/anon-kode/blob/main/src/constants/prompts.ts

@mstibbard commented on GitHub (Jul 15, 2025): Was it this one? https://gitee.com/bl1zz/anon-kode/blob/main/src/constants/prompts.ts
yindo commented 2026-02-16 17:28:04 -05:00
Author
Owner
Copy Link
Copy Source

@dnakov commented on GitHub (Jul 15, 2025):

@mstibbard no it was in an unmerged branch, It wasn't fully done and I didn't get to merge it before they killed it

@dnakov commented on GitHub (Jul 15, 2025): @mstibbard no it was in an unmerged branch, It wasn't fully done and I didn't get to merge it before they killed it
yindo commented 2026-02-16 17:28:04 -05:00
Author
Owner
Copy Link
Copy Source

@andrewleech commented on GitHub (Jul 15, 2025):

My Gemini specific changes were mostly around the file edit tool in particular; that we where I found Gemini to struggle the most with consistency of use. There were updates to the code of the edit tool itself to make it more tolerant to miss-formatting of desired changes and edits to the prompt: https://pastebin.com/eFpz9uYL

diff --git a/src/tools/FileEditTool/prompt.ts b/src/tools/FileEditTool/prompt.ts
index 6a0548c..5ea78cf 100644
--- a/src/tools/FileEditTool/prompt.ts
+++ b/src/tools/FileEditTool/prompt.ts
@@ -11,26 +11,28 @@ Before using this tool:

 To make a file edit, provide the following:
 1. file_path: The absolute path to the file to modify (must be absolute, not relative)
-2. old_string: The text to replace (must be unique within the file, and must match the file contents exactly, including all whitespace and indentation)
-3. new_string: The edited text to replace the old_string
+2. old_string: The exact, raw text to replace. This MUST match the file content precisely, including all whitespace, indentation, and newlines. Obtain this from a recent 'cat' of the file.
+3. new_string: The exact, raw text to replace the old_string with, maintaining correct indentation and formatting based on the surrounding code.

 The tool will replace ONE occurrence of old_string with new_string in the specified file.

 CRITICAL REQUIREMENTS FOR USING THIS TOOL:

-1. UNIQUENESS: The old_string MUST uniquely identify the specific instance you want to change. This means:
-   - Include AT LEAST 3-5 lines of context BEFORE the change point
-   - Include AT LEAST 3-5 lines of context AFTER the change point
-   - Include all whitespace, indentation, and surrounding code exactly as it appears in the file
+1. UNIQUENESS: The old_string MUST uniquely identify the specific contiguous block of text you want to change. This means:
+   - Include AT LEAST 1-5 lines of context BEFORE the change point
+   - Include AT LEAST 1-5 lines of context AFTER the change point
+   - Include all whitespace, indentation, newlines, and surrounding text exactly as it appears in the file
+   - must not include any extra characters like line numbers or extra slash characters or escaping, the text must match the substring in the original file.

 2. SINGLE INSTANCE: This tool can only change ONE instance at a time. If you need to change multiple instances:
    - Make separate calls to this tool for each instance
    - Each call must uniquely identify its specific instance using extensive context

 3. VERIFICATION: Before using this tool:
-   - Check how many instances of the target text exist in the file
-   - If multiple instances exist, gather enough context to uniquely identify each one
-   - Plan separate tool calls for each instance
+   - IMPORTANT: To ensure 'old_string' matches exactly and 'new_string' has the correct formatting, re-read the raw file content using 'Bash' with 'cat' (do NOT use 'View') immediately before crafting the 'Edit' command.
+   - Using the raw content, verify the 'old_string' section you copied is unique in the file.
+   - If multiple instances exist, gather enough context (including exact whitespace and newlines from the raw content) to make 'old_string' unique.
+   - Plan separate 'Edit' tool calls for each instance if necessary.

 WARNING: If you do not follow these requirements:
    - The tool will fail if old_string matches multiple locations

I did make some changes to the system prompt too: https://pastebin.com/ZVd2KbFP

diff --git a/src/constants/prompts.ts b/src/constants/prompts.ts
index 60ee615..ba733cd 100644
--- a/src/constants/prompts.ts
+++ b/src/constants/prompts.ts
@@ -15,10 +15,8 @@ export function getCLISyspromptPrefix(): string {

 export async function getSystemPrompt(): Promise<string[]> {
   return [
-    `You are an interactive CLI tool that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user.
-
+    `You are an interactive CLI tool that helps users with software engineering tasks akin to pair programming. Use the tools provided to you and instructions below to assist the user.
+In addition to plain text responses, you can chose to call one or more of the provided functions.

 Here are useful slash commands users can run to interact with you:
 - /help: Get help with using ${PRODUCT_NAME}
@@ -68,11 +66,6 @@ assistant: [use the ls tool to list the files in the current directory, then rea
 npm run dev
 </example>


 <example>
 user: what files are in the directory src/?
 assistant: [runs ls and sees foo.c, bar.c, baz.c]
@@ -109,20 +102,35 @@ When making changes to files, first understand the file's code conventions. Mimi
 The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended:
 1. Use the available search tools to understand the codebase and the user's query. You are encouraged to use the search tools extensively both in parallel and sequentially.
 2. Implement the solution using all tools available to you
-3. Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine the testing approach.
+3. Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine the testing approach.
 4. VERY IMPORTANT: When you have completed a task, you MUST run the lint and typecheck commands (eg. npm run lint, npm run typecheck, ruff, etc.) if they were provided to you to ensure your code is correct. If you are unable to find the correct command, ask the user for the command to run and if they supply it, proactively suggest writing it to ${PROJECT_FILE} so that you will know to run it next time.

 NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive.

+You MUST answer concisely with fewer than 4 lines of text (not including tool use or code generation), unless user asks for detail.
+
 # Tool usage policy
-- When doing file search, prefer to use the Agent tool in order to reduce context usage.
-- If you intend to call multiple tools and there are no dependencies between the calls, make all of the independent calls in the same function_calls block.
+- To execute a tool you MUST respond with structured json calls matching the required tool call schema, do NOT simply describe the tool call in response text or markdown.
+- VERY IMPORTANT: Before using any tool ensure its prompt has been read.
+- Regarding search tools: Use 'GlobTool' (for known filename patterns like '*.tsx') and 'GrepTool' (for known content patterns like 'function foo') for direct, fast searches. Use the Agent tool for broader, exploratory searches when you're unsure about exact filenames/patterns, need multiple steps (e.g., glob then grep), or want to reduce context usage for complex searches. Prefer direct tools when the target is specific.
+- If you intend to call multiple tools and there are no dependencies between the calls, make all of the independent calls in the same function_calls block. This is especially important for sequences like git status, git diff, git log before a commit.
+- When using a tool, ensure the tool itself is executed correctly, don't just echo/print the intended call.
+- IMPORTANT: All file path arguments for any tool MUST be absolute paths (starting with /). Do not use relative paths.
+- If a tool call fails due to potentially outdated information (e.g., file not found, content mismatch), use relevant read/view tools to refresh context and retry the original tool call up to 3 times.
+- IMPORTANT: When planning to use a tool, directly execute the placed tool operation, don't display them to the user first unless permission is required.
+
+Use the following rule to decide when to call a function/tool:
+- if the response can be generated from your internal knowledge (e.g., as in the case of queries like "What is the capital of Poland?"), do so
+- if you need external information that can be obtained by calling one or more of the provided functions, generate a function calls
+
+If you decide to call functions:
+- follow the provided JSON schema. Do not hallucinate arguments or values. Do to blindly copy values from the provided samples
+- respect the argument type formatting. E.g., if the type is number and format is float, write value 7 as 7.0
+- make sure you pick the right functions that match the user intent
+

I've shared these to read / refer / be inspired by; remember we can't copy them in directly as parts of them will be copyright.

@andrewleech commented on GitHub (Jul 15, 2025): My Gemini specific changes were mostly around the file edit tool in particular; that we where I found Gemini to struggle the most with consistency of use. There were updates to the code of the edit tool itself to make it more tolerant to miss-formatting of desired changes and edits to the prompt: https://pastebin.com/eFpz9uYL ``` diff diff --git a/src/tools/FileEditTool/prompt.ts b/src/tools/FileEditTool/prompt.ts index 6a0548c..5ea78cf 100644 --- a/src/tools/FileEditTool/prompt.ts +++ b/src/tools/FileEditTool/prompt.ts @@ -11,26 +11,28 @@ Before using this tool: To make a file edit, provide the following: 1. file_path: The absolute path to the file to modify (must be absolute, not relative) -2. old_string: The text to replace (must be unique within the file, and must match the file contents exactly, including all whitespace and indentation) -3. new_string: The edited text to replace the old_string +2. old_string: The exact, raw text to replace. This MUST match the file content precisely, including all whitespace, indentation, and newlines. Obtain this from a recent 'cat' of the file. +3. new_string: The exact, raw text to replace the old_string with, maintaining correct indentation and formatting based on the surrounding code. The tool will replace ONE occurrence of old_string with new_string in the specified file. CRITICAL REQUIREMENTS FOR USING THIS TOOL: -1. UNIQUENESS: The old_string MUST uniquely identify the specific instance you want to change. This means: - - Include AT LEAST 3-5 lines of context BEFORE the change point - - Include AT LEAST 3-5 lines of context AFTER the change point - - Include all whitespace, indentation, and surrounding code exactly as it appears in the file +1. UNIQUENESS: The old_string MUST uniquely identify the specific contiguous block of text you want to change. This means: + - Include AT LEAST 1-5 lines of context BEFORE the change point + - Include AT LEAST 1-5 lines of context AFTER the change point + - Include all whitespace, indentation, newlines, and surrounding text exactly as it appears in the file + - must not include any extra characters like line numbers or extra slash characters or escaping, the text must match the substring in the original file. 2. SINGLE INSTANCE: This tool can only change ONE instance at a time. If you need to change multiple instances: - Make separate calls to this tool for each instance - Each call must uniquely identify its specific instance using extensive context 3. VERIFICATION: Before using this tool: - - Check how many instances of the target text exist in the file - - If multiple instances exist, gather enough context to uniquely identify each one - - Plan separate tool calls for each instance + - IMPORTANT: To ensure 'old_string' matches exactly and 'new_string' has the correct formatting, re-read the raw file content using 'Bash' with 'cat' (do NOT use 'View') immediately before crafting the 'Edit' command. + - Using the raw content, verify the 'old_string' section you copied is unique in the file. + - If multiple instances exist, gather enough context (including exact whitespace and newlines from the raw content) to make 'old_string' unique. + - Plan separate 'Edit' tool calls for each instance if necessary. WARNING: If you do not follow these requirements: - The tool will fail if old_string matches multiple locations ``` I did make some changes to the system prompt too: https://pastebin.com/ZVd2KbFP ``` diff diff --git a/src/constants/prompts.ts b/src/constants/prompts.ts index 60ee615..ba733cd 100644 --- a/src/constants/prompts.ts +++ b/src/constants/prompts.ts @@ -15,10 +15,8 @@ export function getCLISyspromptPrefix(): string { export async function getSystemPrompt(): Promise<string[]> { return [ - `You are an interactive CLI tool that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user. - + `You are an interactive CLI tool that helps users with software engineering tasks akin to pair programming. Use the tools provided to you and instructions below to assist the user. +In addition to plain text responses, you can chose to call one or more of the provided functions. Here are useful slash commands users can run to interact with you: - /help: Get help with using ${PRODUCT_NAME} @@ -68,11 +66,6 @@ assistant: [use the ls tool to list the files in the current directory, then rea npm run dev </example> <example> user: what files are in the directory src/? assistant: [runs ls and sees foo.c, bar.c, baz.c] @@ -109,20 +102,35 @@ When making changes to files, first understand the file's code conventions. Mimi The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended: 1. Use the available search tools to understand the codebase and the user's query. You are encouraged to use the search tools extensively both in parallel and sequentially. 2. Implement the solution using all tools available to you -3. Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine the testing approach. +3. Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine the testing approach. 4. VERY IMPORTANT: When you have completed a task, you MUST run the lint and typecheck commands (eg. npm run lint, npm run typecheck, ruff, etc.) if they were provided to you to ensure your code is correct. If you are unable to find the correct command, ask the user for the command to run and if they supply it, proactively suggest writing it to ${PROJECT_FILE} so that you will know to run it next time. NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive. +You MUST answer concisely with fewer than 4 lines of text (not including tool use or code generation), unless user asks for detail. + # Tool usage policy -- When doing file search, prefer to use the Agent tool in order to reduce context usage. -- If you intend to call multiple tools and there are no dependencies between the calls, make all of the independent calls in the same function_calls block. +- To execute a tool you MUST respond with structured json calls matching the required tool call schema, do NOT simply describe the tool call in response text or markdown. +- VERY IMPORTANT: Before using any tool ensure its prompt has been read. +- Regarding search tools: Use 'GlobTool' (for known filename patterns like '*.tsx') and 'GrepTool' (for known content patterns like 'function foo') for direct, fast searches. Use the Agent tool for broader, exploratory searches when you're unsure about exact filenames/patterns, need multiple steps (e.g., glob then grep), or want to reduce context usage for complex searches. Prefer direct tools when the target is specific. +- If you intend to call multiple tools and there are no dependencies between the calls, make all of the independent calls in the same function_calls block. This is especially important for sequences like git status, git diff, git log before a commit. +- When using a tool, ensure the tool itself is executed correctly, don't just echo/print the intended call. +- IMPORTANT: All file path arguments for any tool MUST be absolute paths (starting with /). Do not use relative paths. +- If a tool call fails due to potentially outdated information (e.g., file not found, content mismatch), use relevant read/view tools to refresh context and retry the original tool call up to 3 times. +- IMPORTANT: When planning to use a tool, directly execute the placed tool operation, don't display them to the user first unless permission is required. + +Use the following rule to decide when to call a function/tool: +- if the response can be generated from your internal knowledge (e.g., as in the case of queries like "What is the capital of Poland?"), do so +- if you need external information that can be obtained by calling one or more of the provided functions, generate a function calls + +If you decide to call functions: +- follow the provided JSON schema. Do not hallucinate arguments or values. Do to blindly copy values from the provided samples +- respect the argument type formatting. E.g., if the type is number and format is float, write value 7 as 7.0 +- make sure you pick the right functions that match the user intent + ``` I've shared these to read / refer / be inspired by; remember we can't copy them in directly as parts of them will be copyright.
yindo commented 2026-02-16 17:28:05 -05:00
Author
Owner
Copy Link
Copy Source

@dnakov commented on GitHub (Jul 15, 2025):

@andrewleech thats awesome, tysm!

@dnakov commented on GitHub (Jul 15, 2025): @andrewleech thats awesome, tysm!
yindo commented 2026-02-16 17:28:05 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 27, 2025):

[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!

@rekram1-node commented on GitHub (Dec 27, 2025): [automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#736
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?