feat: rename execute_command tool, improve go prompt

chatgpt_config.yaml

@@ -28,6 +28,6 @@ tool_auto_accept:
   read_file: true
   edit_file: true
   replace_in_file: true
-  executeCommand: false
+  execute_command: false
   # If you set any of these to true, it will auto accept them without prompting.
   # 'executeCommand' should remain false by default unless you're certain it's safe.

lua/chatgpt_nvim/config.lua

@@ -76,7 +76,7 @@ function M.load()
       read_file = false,
       edit_file = false,
       replace_in_file = false,
-      executeCommand = false,
+      execute_command = false,
     }
   }
 

lua/chatgpt_nvim/prompts.lua

@@ -244,16 +244,17 @@ local M = {
 
     You are helping me develop a large Go (Golang) project. Please keep the following points in mind when generating or explaining code:
 
-    1. **Go Modules**  
+    1. **Go Modules & Dependency Management**  
        - Use a single `go.mod` file at the project root for module management.  
        - Ensure you use proper import paths based on the module name.  
        - If you refer to internal packages, use relative paths consistent with the module’s structure (e.g., `moduleName/internal/packageA`).  
+       - **Use the execute_command Tool for Dependencies:** Instead of manually editing version numbers in `go.mod`, please utilize the `execute_command` tool to run dependency commands (such as `go get`) to automatically fetch and update dependencies. This ensures that the correct versions are used without relying on manually provided values.
 
     2. **Package Structure**  
        - Each folder should contain exactly one package.  
        - Avoid creating multiple packages in the same folder.  
        - Use descriptive folder names and keep package names concise, following Go naming conventions.  
-       - Do not duplicate function or type names across different files in the same folder/package.  
+       - Do not duplicate function or type names across different files in the same folder/package.
 
     3. **File & Folder Organization**  
        - Organize source code in a folder hierarchy that reflects functionality. For example:
@@ -271,24 +272,24 @@ local M = {
              └── shared/
          ```
        - Keep external-facing, reusable packages in `pkg/` and internal logic in `internal/`.  
-       - Place the `main()` function in the `cmd/<appname>` folder.  
+       - Place the `main()` function in the `cmd/<appname>` folder.
 
     4. **Coding Best Practices**  
        - Maintain idiomatic Go code (e.g., short function and variable names where obvious, PascalCase for exported symbols).  
        - Keep functions short, focused, and tested.  
        - Use Go’s standard library where possible before adding third-party dependencies.  
-       - When introducing new functions or types, ensure they are uniquely named to avoid collisions.  
+       - When introducing new functions or types, ensure they are uniquely named to avoid collisions.
 
     5. **Import Management**  
        - Ensure that every import is actually used in your code.  
        - Remove unused imports to keep your code clean and maintainable.  
        - Include all necessary imports for anything referenced in your code to avoid missing imports.  
-       - Verify that any introduced import paths match your module’s structure and do not cause naming conflicts.  
+       - Verify that any introduced import paths match your module’s structure and do not cause naming conflicts.
 
     6. **Output Format**  
        - Present any generated source code as well-organized Go files, respecting the single-package-per-folder rule.  
        - When explaining your reasoning, include any relevant architectural trade-offs and rationale (e.g., “I placed function X in package `my_lib` to keep the business logic separate from the command-line interface.”).  
-       - If you modify existing files, specify precisely which changes or additions you are making.  
+       - If you modify existing files, specify precisely which changes or additions you are making.
   ]],
   ["typo3"] = [[
     ### TYPO3 Development Guidelines
@@ -476,7 +477,7 @@ local M = {
          ```yaml
          project_name: "%PROJECT_NAME%"
          tools:
-           - tool: "executeCommand"
+           - tool: "execute_command"
              command: "shell command here"
          ```
 
@@ -490,7 +491,7 @@ local M = {
        - **Step 4: Make Changes**  
          Only after reading the file, proceed to use `edit_file` or `replace_in_file`.
        - **Step 5: Execute Commands if Needed**  
-         Use `executeCommand` as necessary, always within the YAML block.
+         Use `execute_command` as necessary, always within the YAML block.
        - **Step 6: Tell that request is complete**  
          Once all operations are done, confirm that the request is complete with a little summary.
        - **Step 7: Repeat other steps as necessary**
@@ -514,7 +515,7 @@ local M = {
         content: |
           # Full updated file content here
 
-      - tool: "executeCommand"
+      - tool: "execute_command"
         command: "ls -la"
     ```
 

lua/chatgpt_nvim/tools/execute_command.lua

@@ -4,7 +4,7 @@ M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file
   -- Validate the command exists
   local cmd = tool_call.command
   if not cmd then
-    return "[executeCommand] Missing 'command'."
+    return "[execute_command] Missing 'command'."
   end
 
   -- Capture stderr and stdout together by redirecting stderr to stdout
@@ -14,7 +14,7 @@ M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file
   -- Attempt to popen the command
   local handle = io.popen(cmd, "r")
   if not handle then
-    return string.format("Tool [executeCommand '%s'] FAILED to popen.", cmd)
+    return string.format("Tool [execute_command '%s'] FAILED to popen.", cmd)
   end
 
   -- Read the full output (stdout + stderr)
@@ -25,7 +25,7 @@ M.run = function(tool_call, conf, prompt_user_tool_accept, is_subpath, read_file
 
   -- Provide a richer summary including exit code and reason
   return string.format(
-    "Tool [executeCommand '%s'] exited with code %s (%s)\n%s",
+    "Tool [execute_command '%s'] exited with code %s (%s)\n%s",
     cmd,
     tostring(exit_code),
     tostring(exit_reason),

lua/chatgpt_nvim/tools/init.lua

@@ -23,8 +23,8 @@ M.available_tools = {
     explanation = "Use this to apply incremental changes without fully overwriting the file."
   },
   {
-    name = "executeCommand",
-    usage = "Run a shell command. Provide { tool='executeCommand', command='...' }",
+    name = "execute_command",
+    usage = "Run a shell command. Provide { tool='execute_command', command='...' }",
     explanation = "Just run one single command per tool invocation, without comment. It must be a single line. Use with caution, especially for destructive operations (rm, sudo, etc.)."
   },
 }
@@ -33,7 +33,7 @@ M.tools_by_name = {
   read_file = read_file_tool,
   edit_file = edit_file_tool,
   replace_in_file = replace_in_file_tool,
-  executeCommand = execute_command_tool
+  execute_command = execute_command_tool
 }
 
 return M

lua/chatgpt_nvim/tools/manager.lua

@@ -16,8 +16,8 @@ end
 local function prompt_user_tool_accept(tool_call, conf)
   local auto_accept = conf.tool_auto_accept[tool_call.tool]
 
-  -- If this is an executeCommand and we see it's destructive, force a user prompt
-  if tool_call.tool == "executeCommand" and auto_accept then
+  -- If this is an execute_command and we see it's destructive, force a user prompt
+  if tool_call.tool == "execute_command" and auto_accept then
     if is_destructive_command(tool_call.command) then
       auto_accept = false
     end