@polka-codes/cli 0.8.4 → 0.8.6

package/dist/index.js

@@ -31550,7 +31550,7 @@ var {
   Help
 } = import__.default;
 // package.json
-var version = "0.8.4";
+var version = "0.8.6";
 
 // ../core/src/AiService/AiServiceBase.ts
 class AiServiceBase {
@@ -40953,6 +40953,14 @@ var getStringArray = (args2, name2, defaultValue) => {
   if (ret === "") {
     return [];
   }
+  if (Array.isArray(ret)) {
+    for (const item of ret) {
+      if (typeof item !== "string") {
+        throw new Error(`Invalid argument type: ${name2} ${item}`);
+      }
+    }
+    return ret;
+  }
   if (typeof ret !== "string") {
     throw new Error(`Invalid argument type: ${name2} ${ret}`);
   }
@@ -43154,7 +43162,7 @@ You have access to two tools for working with files: **${toolNamePrefix}write_to
 
 ## Important Considerations
 
-- Using ${toolNamePrefix}write_to_file requires providing the file’s complete final content.
+- Using ${toolNamePrefix}write_to_file requires providing the file's complete final content.
 - If you only need to make small changes to an existing file, consider using ${toolNamePrefix}replace_in_file instead to avoid unnecessarily rewriting the entire file.
 - While ${toolNamePrefix}write_to_file should not be your default choice, don't hesitate to use it when the situation truly calls for it.
 
@@ -43167,12 +43175,12 @@ You have access to two tools for working with files: **${toolNamePrefix}write_to
 ## When to Use
 
 - Small, localized changes like updating a few lines, function implementations, changing variable names, modifying a section of text, etc.
-- Targeted improvements where only specific portions of the file’s content needs to be altered.
+- Targeted improvements where only specific portions of the file's content needs to be altered.
 - Especially useful for long files where much of the file will remain unchanged.
 
 ## Advantages
 
-- More efficient for minor edits, since you don’t need to supply the entire file content.
+- More efficient for minor edits, since you don't need to supply the entire file content.
 - Reduces the chance of errors that can occur when overwriting large files.
 
 # Choosing the Appropriate Tool
@@ -43198,41 +43206,39 @@ var rules = (toolNamePrefix) => `
 
 RULES
 
-- You may use \`cd\` to enter any child directory within the current working directory. For example, \`cd myChildDir\`. But you may never move to a parent directory or any directory outside your current path. For example, do not use \`cd ..\`, \`cd /\`, or any absolute path.
-- Always work with relative path names, and never use absolute paths.
-- When generating code or test or any file that support comments, add a comment on top of the file with a description of the file's purpose and a note that this file is generated by "polka.codes".
-- When generate text file such as README.md, add a footer indicating this file is generated by "polka.codes".
-- Before using the ${toolNamePrefix}execute_command tool, you must first think about the SYSTEM INFORMATION context provided to understand the user's environment and tailor your commands to ensure they are compatible with their system. You must also consider if the command you need to run should be executed in a specific directory outside of the current working directory, and if so prepend with \`cd\`'ing into that directory && then executing the command (as one command). For example, if you needed to run \`npm install\` in a project that's not in the current working directory, you would need to prepend with a \`cd\` i.e. pseudocode for this would be \`cd (path to project) && (command, in this case npm install)\`. However, you can only cd into child directory, but never parent directory or root directory or home directory.
-- When using the ${toolNamePrefix}search_files tool, craft your regex patterns carefully to balance specificity and flexibility. Based on the user's task you may use it to find code patterns, TODO comments, function definitions, or any text-based information across the project. The results include context, so analyze the surrounding code to better understand the matches. Leverage the ${toolNamePrefix}search_files tool in combination with other tools for more comprehensive analysis. For example, use it to find specific code patterns, then use ${toolNamePrefix}read_file to examine the full context of interesting matches before using ${toolNamePrefix}replace_in_file to make informed changes.
-- When creating a new project (such as an app, website, or any software project), organize all new files within a dedicated project directory unless the user specifies otherwise. Use appropriate file paths when creating files, as the ${toolNamePrefix}write_to_file tool will automatically create any necessary directories. Structure the project logically, adhering to best practices for the specific type of project being created. Unless otherwise specified, new projects should be easily run without additional setup, for example most projects can be built in HTML, CSS, and JavaScript - which you can open in a browser.
-- Be sure to consider the type of project (e.g. Python, JavaScript, web application) when determining the appropriate structure and files to include. Also consider what files may be most relevant to accomplishing the task, for example looking at a project's manifest file would help you understand the project's dependencies, which you could incorporate into any code you write.
-- When making changes to code, always consider the context in which the code is being used. Ensure that your changes are compatible with the existing codebase and that they follow the project's coding standards and best practices.
-- **Adhere to any established coding style, linting rules, or naming conventions if they are known or can be inferred from the existing codebase, to maintain consistency.**
-- When you want to modify a file, use the ${toolNamePrefix}replace_in_file or ${toolNamePrefix}write_to_file tool directly with the desired changes. You do not need to display the changes before using the tool.
-- **Do not guess or hallucinate file content that has not been explicitly provided or read. Always read an existing file with \`${toolNamePrefix}read_file\` (or rely on content the user directly provided) before modifying it, unless you are creating a brand-new file.**
-- Do not ask for more information than necessary. Use the tools provided to accomplish the user's request efficiently and effectively. When you've completed your task, you must use the ${toolNamePrefix}attempt_completion tool to present the result to the user.
-- The user may provide a file's contents directly in their message, in which case you shouldn't use the ${toolNamePrefix}read_file tool to get the file contents again since you already have it.
-- Your goal is to try to accomplish the user's task, NOT engage in a back and forth conversation.
-- NEVER end ${toolNamePrefix}attempt_completion result with a question or request to engage in further conversation! Formulate the end of your result in a way that is final and does not require further input from the user.
-- You are STRICTLY FORBIDDEN from starting your messages with "Great", "Certainly", "Okay", "Sure". You should NOT be conversational in your responses, but rather direct and to the point. For example you should NOT say "Great, I've updated the CSS" but instead something like "I've updated the CSS". It is important you be clear and technical in your messages.
-- When presented with images, utilize your vision capabilities to thoroughly examine them and extract meaningful information. Incorporate these insights into your thought process as you accomplish the user's task.
-- When using the ${toolNamePrefix}replace_in_file tool, you must include complete lines in your SEARCH blocks, not partial lines. The system requires exact line matches and cannot match partial lines. For example, if you want to match a line containing "const x = 5;", your SEARCH block must include the entire line, not just "x = 5" or other fragments.
-- When using the ${toolNamePrefix}replace_in_file tool, if you use multiple SEARCH/REPLACE blocks, list them in the order they appear in the file. For example if you need to make changes to both line 10 and line 50, first include the SEARCH/REPLACE block for line 10, followed by the SEARCH/REPLACE block for line 50.
-- It is critical you wait for the user's response after each tool use, in order to confirm the success of the tool use. For example, if asked to make a todo app, you would create a file, wait for the user's response it was created successfully, then create another file if needed, wait for the user's response it was created successfully, etc.
-- Keep the inline docs up to date if needed.
+- Work only with relative paths; you may \`cd\` into child directories but never use \`cd ..\`, root, or absolute paths.
+- When generating code, tests, or other comment-capable files, prepend a comment describing the file's purpose plus “generated by polka.codes”.
+  For text files (e.g. README.md), append a footer with the same notice.
+- Never describe what changed inside code comments; comments must focus on purpose or usage only.
+- Before using ${toolNamePrefix}execute_command, consider SYSTEM INFORMATION to ensure commands suit the user's OS. If a command must run in a subdirectory, prepend a single \`cd childDir &&\` segment.
+- Use ${toolNamePrefix}search_files for broad analysis, then ${toolNamePrefix}read_file to inspect context, and finally ${toolNamePrefix}replace_in_file or ${toolNamePrefix}write_to_file to modify.
+- Prefer ${toolNamePrefix}replace_in_file for focused edits; choose ${toolNamePrefix}write_to_file for new files or complete rewrites.
+- When creating a new file, look for existing files with similar content or patterns; if found, read them and use their structure or conventions as a reference.
+- SEARCH blocks in ${toolNamePrefix}replace_in_file must match whole lines. If multiple blocks are needed, list them in file order.
+- Do not guess unseen content. Read existing files first unless creating new ones.
+- Follow existing style, lint, and naming conventions. Ensure all changes compile and pass tests where applicable.
+- ALWAYS wait for the user's confirmation after each tool call before starting the next step.
+- The agent must never invoke more than 5 tools in a single response.
+- Do not end ${toolNamePrefix}attempt_completion output with questions or conversational prompts.
+- Avoid filler words like “Great”, “Certainly”, “Okay”, “Sure” at the start of responses; be direct and technical.
+- Keep inline documentation current as you edit.
 `;
 var objectives = (toolNamePrefix) => `
 ====
 
 OBJECTIVE
 
-You accomplish a given task iteratively, breaking it down into clear steps and working through them methodically.
+You solve the user's task by working in small, verifiable steps.
 
-1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
-2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
-3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Then, think about which of the provided tools is the most relevant tool to accomplish the user's task. Next, go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use.
-4. Once you've completed the user's task, you must use the ${toolNamePrefix}attempt_completion tool to present the result of the task to the user.
-5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.`;
+1. **Plan** - Parse the task, list clear goals, and order them logically.
+2. **Think** - Wrap private reasoning in <thinking></thinking>.
+   • Review project context.
+   • Select the single best tool for the next goal.
+   • Ensure every required parameter is available or can be inferred.
+3. **Act** - Invoke one tool per step. Wait for the system's response (and user confirmation where required) before continuing.
+4. **Iterate** - Repeat Plan → Think → Act until all goals are complete.
+5. **Complete** - Use ${toolNamePrefix}attempt_completion to deliver the final result. Do not invite further discussion unless the user explicitly requests changes.
+`;
 var fullSystemPrompt4 = (info2, tools, toolNamePrefix, instructions, scripts) => `
 ${basePrompt2}
 ${toolUsePrompt(tools, toolNamePrefix)}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@polka-codes/cli",
-  "version": "0.8.4",
+  "version": "0.8.6",
   "license": "AGPL-3.0",
   "author": "github@polka.codes",
   "type": "module",