on main help sign in
test: re-record vcr cassettes
commit8bab8b3f7b9d95921a24fe86d003d3c4d829698e authorAndrey Nering <andreynering@users.noreply.github.com> dateThu 16 Apr 2026, 17:47 (6 months ago) parentf546a07
13 files changed+2347−445
internal/agent/testdata/TestCoderAgent/glm-5.1/bash_tool.yaml+180−30 internal/agent/testdata/TestCoderAgent/glm-5.1/download_tool.yaml+123−27 internal/agent/testdata/TestCoderAgent/glm-5.1/fetch_tool.yaml+137−29 internal/agent/testdata/TestCoderAgent/glm-5.1/glob_tool.yaml+99−27 internal/agent/testdata/TestCoderAgent/glm-5.1/grep_tool.yaml+106−30 internal/agent/testdata/TestCoderAgent/glm-5.1/ls_tool.yaml+87−29 internal/agent/testdata/TestCoderAgent/glm-5.1/multiedit_tool.yaml+705−43 internal/agent/testdata/TestCoderAgent/glm-5.1/parallel_tool_calls.yaml+96−32 internal/agent/testdata/TestCoderAgent/glm-5.1/read_a_file.yaml+121−37 internal/agent/testdata/TestCoderAgent/glm-5.1/simple_test.yaml+25−13 internal/agent/testdata/TestCoderAgent/glm-5.1/sourcegraph_tool.yaml+305−89 internal/agent/testdata/TestCoderAgent/glm-5.1/update_a_file.yaml+243−35 internal/agent/testdata/TestCoderAgent/glm-5.1/write_tool.yaml+120−24
internal/agent/testdata/TestCoderAgent/glm-5.1/bash_tool.yaml+180−30
@@ -25,29 +25,29 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"B"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"B"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"ash"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"ash"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" command"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" script"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" create"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" create"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" test"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" test"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".txt"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".txt"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
44+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
4545
46− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" hello"},"finish_reason":null}]}
46+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" hello"},"finish_reason":null}]}
4747
48− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" bash"},"finish_reason":null}]}
48+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" bash"},"finish_reason":null}]}
4949
50− data: {"id":"chatcmpl-04b99a08603e4ed19c0a373d","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":11,"completion_tokens":278,"total_tokens":497}}
50+ data: {"id":"chatcmpl-d398f349fdddf325c9b169a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":11,"completion_tokens":208,"total_tokens":427}}
5151
5252 data: [DONE]
5353
@@ -56,15 +56,15 @@ interactions:
5656 - text/event-stream
5757 status: 200 OK
5858 code: 200
59− duration: 3.052443875s
59+ duration: 2.437881292s
6060- id: 1
6161 request:
6262 proto: HTTP/1.1
6363 proto_major: 1
6464 proto_minor: 1
65− content_length: 32379
65+ content_length: 32514
6666 host: ""
67− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use bash to create a file named test.txt with content 'hello bash'. do not print its timestamp\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
67+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use bash to create a file named test.txt with content 'hello bash'. do not print its timestamp\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6868 headers:
6969 Accept:
7070 - application/json
@@ -81,13 +81,147 @@ interactions:
8181 content_length: -1
8282 uncompressed: true
8383 body: |+
84− data: {"id":"chatcmpl-992c43e079e072ed4f08abc7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
84+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
8585
86− data: {"id":"chatcmpl-992c43e079e072ed4f08abc7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_4412","type":"function","index":0,"function":{"name":"bash","arguments":""}}]},"finish_reason":null}]}
86+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980a1273b68cea9ca17e17bc0c3a","type":"function","index":0,"function":{"name":"bash","arguments":""}}]},"finish_reason":null}]}
8787
88− data: {"id":"chatcmpl-992c43e079e072ed4f08abc7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"command\": \"echo 'hello bash' \u003e /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool/test.txt\", \"description\": \"Create test.txt with content 'hello bash'\"}"}}]},"finish_reason":null}]}
88+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
8989
90− data: {"id":"chatcmpl-992c43e079e072ed4f08abc7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":499,"completion_tokens":57,"total_tokens":7500}}
90+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"command\": "}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"touch"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" -"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"t"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" 202"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"50"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"010"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"000"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" /"}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"tmp"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
117+
118+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
119+
120+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
125+
126+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
127+
128+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
129+
130+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
131+
132+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
135+
136+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
137+
138+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/bash"}}]},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
141+
142+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/test"}}]},"finish_reason":null}]}
143+
144+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".txt"}}]},"finish_reason":null}]}
145+
146+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \u0026\u0026"}}]},"finish_reason":null}]}
147+
148+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" printf"}}]},"finish_reason":null}]}
149+
150+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" '"}}]},"finish_reason":null}]}
151+
152+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"hello"}}]},"finish_reason":null}]}
153+
154+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" bash"}}]},"finish_reason":null}]}
155+
156+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"'"}}]},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \u003e"}}]},"finish_reason":null}]}
159+
160+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" /"}}]},"finish_reason":null}]}
161+
162+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"tmp"}}]},"finish_reason":null}]}
163+
164+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
165+
166+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
167+
168+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
169+
170+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
171+
172+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
173+
174+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
179+
180+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
181+
182+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
183+
184+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/bash"}}]},"finish_reason":null}]}
189+
190+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
191+
192+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/test"}}]},"finish_reason":null}]}
193+
194+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".txt"}}]},"finish_reason":null}]}
195+
196+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
197+
198+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
199+
200+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"description\": "}}]},"finish_reason":null}]}
201+
202+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"Create"}}]},"finish_reason":null}]}
203+
204+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" test"}}]},"finish_reason":null}]}
205+
206+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".txt"}}]},"finish_reason":null}]}
207+
208+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" with"}}]},"finish_reason":null}]}
209+
210+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" content"}}]},"finish_reason":null}]}
211+
212+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" '"}}]},"finish_reason":null}]}
213+
214+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"hello"}}]},"finish_reason":null}]}
215+
216+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" bash"}}]},"finish_reason":null}]}
217+
218+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"'"}}]},"finish_reason":null}]}
219+
220+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
221+
222+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
223+
224+ data: {"id":"chatcmpl-5c27a73157558b0036eef501","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":555,"completion_tokens":75,"total_tokens":7542}}
91225
92226 data: [DONE]
93227
@@ -96,15 +230,15 @@ interactions:
96230 - text/event-stream
97231 status: 200 OK
98232 code: 200
99− duration: 10.348750292s
233+ duration: 4.2711765s
100234- id: 2
101235 request:
102236 proto: HTTP/1.1
103237 proto_major: 1
104238 proto_minor: 1
105− content_length: 32719
239+ content_length: 32985
106240 host: ""
107− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use bash to create a file named test.txt with content 'hello bash'. do not print its timestamp\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_4412\",\"function\":{\"arguments\":\"{\\\"command\\\": \\\"echo 'hello bash' > /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool/test.txt\\\", \\\"description\\\": \\\"Create test.txt with content 'hello bash'\\\"}\",\"name\":\"bash\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"no output\",\"tool_call_id\":\"call_4412\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
241+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use bash to create a file named test.txt with content 'hello bash'. do not print its timestamp\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980a1273b68cea9ca17e17bc0c3a\",\"function\":{\"arguments\":\"{\\\"command\\\": \\\"touch -t 202501010000 /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool/test.txt && printf 'hello bash' > /tmp/crush-test/TestCoderAgent/glm-5.1/bash_tool/test.txt\\\", \\\"description\\\": \\\"Create test.txt with content 'hello bash'\\\"}\",\"name\":\"bash\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"no output\",\"tool_call_id\":\"019d980a1273b68cea9ca17e17bc0c3a\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
108242 headers:
109243 Accept:
110244 - application/json
@@ -121,19 +255,35 @@ interactions:
121255 content_length: -1
122256 uncompressed: true
123257 body: |+
124− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
258+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
259+
260+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Done"},"finish_reason":null}]}
261+
262+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
263+
264+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Created"},"finish_reason":null}]}
265+
266+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
267+
268+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"test"},"finish_reason":null}]}
269+
270+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".txt"},"finish_reason":null}]}
271+
272+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
273+
274+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
125275
126− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Done —"},"finish_reason":null}]}
276+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" content"},"finish_reason":null}]}
127277
128− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
278+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
129279
130− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"test.txt` created"},"finish_reason":null}]}
280+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"hello"},"finish_reason":null}]}
131281
132− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with content"},"finish_reason":null}]}
282+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" bash"},"finish_reason":null}]}
133283
134− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `hello bash`."},"finish_reason":null}]}
284+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`."},"finish_reason":null}]}
135285
136− data: {"id":"chatcmpl-a14fec75a37a8976cf74f5d9","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":73,"completion_tokens":14,"total_tokens":7511}}
286+ data: {"id":"chatcmpl-1fd0e009e26aea9dff7b04ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":637,"completion_tokens":14,"total_tokens":7563}}
137287
138288 data: [DONE]
139289
@@ -142,4 +292,4 @@ interactions:
142292 - text/event-stream
143293 status: 200 OK
144294 code: 200
145− duration: 873.565917ms
295+ duration: 2.2743725s
internal/agent/testdata/TestCoderAgent/glm-5.1/download_tool.yaml+123−27
@@ -25,23 +25,23 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Download"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Download"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" save"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Save"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" example"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" example"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".txt"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".txt"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" from"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" from"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" URL"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" URL"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-62b357edbb5872fdcf168b97","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":14,"completion_tokens":128,"total_tokens":350}}
44+ data: {"id":"chatcmpl-94f2b9d7e0f03b37bafdabe7","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":14,"completion_tokens":99,"total_tokens":321}}
4545
4646 data: [DONE]
4747
@@ -50,15 +50,15 @@ interactions:
5050 - text/event-stream
5151 status: 200 OK
5252 code: 200
53− duration: 1.617242791s
53+ duration: 1.431387417s
5454- id: 1
5555 request:
5656 proto: HTTP/1.1
5757 proto_major: 1
5858 proto_minor: 1
59− content_length: 32404
59+ content_length: 32539
6060 host: ""
61− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/download_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"download the file from https://example-files.online-convert.com/document/txt/example.txt and save it as example.txt\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
61+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/download_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"download the file from https://example-files.online-convert.com/document/txt/example.txt and save it as example.txt\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6262 headers:
6363 Accept:
6464 - application/json
@@ -75,13 +75,87 @@ interactions:
7575 content_length: -1
7676 uncompressed: true
7777 body: |+
78− data: {"id":"chatcmpl-eff4c1e49c52444ef8aabff6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
78+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
7979
80− data: {"id":"chatcmpl-eff4c1e49c52444ef8aabff6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_d627","type":"function","index":0,"function":{"name":"download","arguments":""}}]},"finish_reason":null}]}
80+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980a30df5f8f3e88069dd0f858d4","type":"function","index":0,"function":{"name":"download","arguments":""}}]},"finish_reason":null}]}
8181
82− data: {"id":"chatcmpl-eff4c1e49c52444ef8aabff6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/download_tool/example.txt\", \"url\": \"https://example-files.online-convert.com/document/txt/example.txt\"}"}}]},"finish_reason":null}]}
82+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
8383
84− data: {"id":"chatcmpl-eff4c1e49c52444ef8aabff6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":7414,"completion_tokens":45,"total_tokens":7491}}
84+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/download"}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
117+
118+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/example"}}]},"finish_reason":null}]}
119+
120+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".txt"}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
125+
126+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"url\": "}}]},"finish_reason":null}]}
127+
128+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"https"}}]},"finish_reason":null}]}
129+
130+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"://"}}]},"finish_reason":null}]}
131+
132+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"example"}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-files"}}]},"finish_reason":null}]}
135+
136+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".online"}}]},"finish_reason":null}]}
137+
138+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"convert"}}]},"finish_reason":null}]}
141+
142+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".com"}}]},"finish_reason":null}]}
143+
144+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/document"}}]},"finish_reason":null}]}
145+
146+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/t"}}]},"finish_reason":null}]}
147+
148+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"xt"}}]},"finish_reason":null}]}
149+
150+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/example"}}]},"finish_reason":null}]}
151+
152+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".txt"}}]},"finish_reason":null}]}
153+
154+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
155+
156+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-acb511dd7353c66f2bb5af01","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":558,"completion_tokens":72,"total_tokens":7542}}
85159
86160 data: [DONE]
87161
@@ -90,7 +164,7 @@ interactions:
90164 - text/event-stream
91165 status: 200 OK
92166 code: 200
93− duration: 3.898478625s
167+ duration: 3.791854667s
94168- id: 2
95169 request:
96170 proto: HTTP/1.1
@@ -136,15 +210,15 @@ interactions:
136210 - text/plain; charset=UTF-8
137211 status: 200 OK
138212 code: 200
139− duration: 1.5313565s
213+ duration: 1.5185405s
140214- id: 3
141215 request:
142216 proto: HTTP/1.1
143217 proto_major: 1
144218 proto_minor: 1
145− content_length: 32835
219+ content_length: 33016
146220 host: ""
147− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/download_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"download the file from https://example-files.online-convert.com/document/txt/example.txt and save it as example.txt\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_d627\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/download_tool/example.txt\\\", \\\"url\\\": \\\"https://example-files.online-convert.com/document/txt/example.txt\\\"}\",\"name\":\"download\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"Successfully downloaded 2574 bytes to example.txt (Content-Type: text/plain; charset=UTF-8)\",\"tool_call_id\":\"call_d627\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
221+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/download_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"download the file from https://example-files.online-convert.com/document/txt/example.txt and save it as example.txt\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980a30df5f8f3e88069dd0f858d4\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/download_tool/example.txt\\\", \\\"url\\\": \\\"https://example-files.online-convert.com/document/txt/example.txt\\\"}\",\"name\":\"download\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"Successfully downloaded 2574 bytes to example.txt (Content-Type: text/plain; charset=UTF-8)\",\"tool_call_id\":\"019d980a30df5f8f3e88069dd0f858d4\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
148222 headers:
149223 Accept:
150224 - application/json
@@ -161,17 +235,39 @@ interactions:
161235 content_length: -1
162236 uncompressed: true
163237 body: |+
164− data: {"id":"chatcmpl-ccfca343b9e5855eeed25d1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
238+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
239+
240+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"File"},"finish_reason":null}]}
241+
242+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" downloaded"},"finish_reason":null}]}
243+
244+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
245+
246+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" saved"},"finish_reason":null}]}
247+
248+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" as"},"finish_reason":null}]}
249+
250+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
251+
252+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"example"},"finish_reason":null}]}
253+
254+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".txt"},"finish_reason":null}]}
255+
256+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
257+
258+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" ("},"finish_reason":null}]}
259+
260+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"25"},"finish_reason":null}]}
165261
166− data: {"id":"chatcmpl-ccfca343b9e5855eeed25d1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"File"},"finish_reason":null}]}
262+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"7"},"finish_reason":null}]}
167263
168− data: {"id":"chatcmpl-ccfca343b9e5855eeed25d1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" downloaded and"},"finish_reason":null}]}
264+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"4"},"finish_reason":null}]}
169265
170− data: {"id":"chatcmpl-ccfca343b9e5855eeed25d1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" saved as"},"finish_reason":null}]}
266+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" bytes"},"finish_reason":null}]}
171267
172− data: {"id":"chatcmpl-ccfca343b9e5855eeed25d1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `example.txt`."},"finish_reason":null}]}
268+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":")."},"finish_reason":null}]}
173269
174− data: {"id":"chatcmpl-ccfca343b9e5855eeed25d1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":30,"completion_tokens":10,"total_tokens":7528}}
270+ data: {"id":"chatcmpl-d7be9ae3c50e1d11fc3f9092","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":118,"completion_tokens":16,"total_tokens":7558}}
175271
176272 data: [DONE]
177273
@@ -180,4 +276,4 @@ interactions:
180276 - text/event-stream
181277 status: 200 OK
182278 code: 200
183− duration: 1.214644041s
279+ duration: 2.276888375s
internal/agent/testdata/TestCoderAgent/glm-5.1/fetch_tool.yaml+137−29
@@ -25,21 +25,25 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Check"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Check"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" URL"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" example"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".html"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" John"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Doe"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" presence"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" occurrence"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" of"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-23cb017d163f02af73899b85","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3,"completion_tokens":134,"total_tokens":361}}
42+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" John"},"finish_reason":null}]}
43+
44+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Doe"},"finish_reason":null}]}
45+
46+ data: {"id":"chatcmpl-b5ecccdabaf2739cf6c865ed","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3,"completion_tokens":202,"total_tokens":429}}
4347
4448 data: [DONE]
4549
@@ -48,15 +52,15 @@ interactions:
4852 - text/event-stream
4953 status: 200 OK
5054 code: 200
51− duration: 1.755835166s
55+ duration: 2.462296417s
5256- id: 1
5357 request:
5458 proto: HTTP/1.1
5559 proto_major: 1
5660 proto_minor: 1
57− content_length: 32422
61+ content_length: 32557
5862 host: ""
59− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/fetch_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"fetch the content from https://example-files.online-convert.com/website/html/example.html and tell me if it contains the word 'John Doe'\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
63+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/fetch_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"fetch the content from https://example-files.online-convert.com/website/html/example.html and tell me if it contains the word 'John Doe'\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6064 headers:
6165 Accept:
6266 - application/json
@@ -73,13 +77,55 @@ interactions:
7377 content_length: -1
7478 uncompressed: true
7579 body: |+
76− data: {"id":"chatcmpl-d2011747aaaf0f20c36c2b3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
80+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
81+
82+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980a55ccb97115543c42140e8984","type":"function","index":0,"function":{"name":"fetch","arguments":""}}]},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"format\": "}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"text"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"url\": "}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"https"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"://"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"example"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-files"}}]},"finish_reason":null}]}
77105
78− data: {"id":"chatcmpl-d2011747aaaf0f20c36c2b3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_815c","type":"function","index":0,"function":{"name":"fetch","arguments":""}}]},"finish_reason":null}]}
106+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".online"}}]},"finish_reason":null}]}
79107
80− data: {"id":"chatcmpl-d2011747aaaf0f20c36c2b3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"format\": \"text\", \"url\": \"https://example-files.online-convert.com/website/html/example.html\"}"}}]},"finish_reason":null}]}
108+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
81109
82− data: {"id":"chatcmpl-d2011747aaaf0f20c36c2b3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":509,"completion_tokens":49,"total_tokens":7502}}
110+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"convert"}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".com"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/"}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"website"}}]},"finish_reason":null}]}
117+
118+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/html"}}]},"finish_reason":null}]}
119+
120+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/example"}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".html"}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
125+
126+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
127+
128+ data: {"id":"chatcmpl-71bd0994e6436dde2cdc642e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":565,"completion_tokens":28,"total_tokens":7505}}
83129
84130 data: [DONE]
85131
@@ -88,7 +134,7 @@ interactions:
88134 - text/event-stream
89135 status: 200 OK
90136 code: 200
91− duration: 3.850198333s
137+ duration: 4.440376208s
92138- id: 2
93139 request:
94140 proto: HTTP/1.1
@@ -159,15 +205,15 @@ interactions:
159205 - text/html; charset=UTF-8
160206 status: 200 OK
161207 code: 200
162− duration: 412.366875ms
208+ duration: 437.682709ms
163209- id: 3
164210 request:
165211 proto: HTTP/1.1
166212 proto_major: 1
167213 proto_minor: 1
168− content_length: 35202
214+ content_length: 35383
169215 host: ""
170− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/fetch_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"fetch the content from https://example-files.online-convert.com/website/html/example.html and tell me if it contains the word 'John Doe'\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_815c\",\"function\":{\"arguments\":\"{\\\"format\\\": \\\"text\\\", \\\"url\\\": \\\"https://example-files.online-convert.com/website/html/example.html\\\"}\",\"name\":\"fetch\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"HTML test file Purpose: Provide example of this file type Document file type: HTML Version: 1.0 Remark: Example content: The names \\\"John Doe\\\" for males, \\\"Jane Doe\\\" or \\\"Jane Roe\\\" for females, or \\\"Jonnie Doe\\\" and \\\"Janie Doe\\\" for children, or just \\\"Doe\\\" non-gender-specifically are used as placeholder names for a party whose true identity is unknown or must be withheld in a legal action, case, or discussion. The names are also used to refer to acorpse or hospital patient whose identity is unknown. This practice is widely used in the United States and Canada, but is rarely used in other English-speaking countries including the United Kingdom itself, from where the use of \\\"John Doe\\\" in a legal context originates. The names Joe Bloggs or John Smith are used in the UK instead, as well as in Australia and New Zealand. John Doe is sometimes used to refer to a typical male in other contexts as well, in a similar manner to John Q. Public, known in Great Britain as Joe Public, John Smith or Joe Bloggs. For example, the first name listed on a form is often John Doe, along with a fictional address or other fictional information to provide an example of how to fill in the form. The name is also used frequently in popular culture, for example in the Frank Capra film Meet John Doe. John Doe was also the name of a 2002 American television series. Similarly, a child or baby whose identity is unknown may be referred to as Baby Doe. A notorious murder case in Kansas City, Missouri, referred to the baby victim as Precious Doe. Other unidentified female murder victims are Cali Doe and Princess Doe. Additional persons may be called James Doe, Judy Doe, etc. However, to avoid possible confusion, if two anonymous or unknown parties are cited in a specific case or action, the surnames Doe and Roe may be used simultaneously; for example, \\\"John Doe v. Jane Roe\\\". If several anonymous parties are referenced, they may simply be labelled John Doe #1, John Doe #2, etc. (the U.S. Operation Delego cited 21 (numbered) \\\"John Doe\\\"s) or labelled with other variants of Doe / Roe / Poe / etc. Other early alternatives such as John Stiles and Richard Miles are now rarely used, and Mary Major has been used in some American federal cases. File created by https://www.online-convert.com More example files: https://www.online-convert.com/file-type Text of \\\"Example content\\\": Wikipedia License: Attribution-ShareAlike 3.0 Unported Feel free to use and share the file according to license above.\",\"tool_call_id\":\"call_815c\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
216+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/fetch_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"fetch the content from https://example-files.online-convert.com/website/html/example.html and tell me if it contains the word 'John Doe'\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980a55ccb97115543c42140e8984\",\"function\":{\"arguments\":\"{\\\"format\\\": \\\"text\\\", \\\"url\\\": \\\"https://example-files.online-convert.com/website/html/example.html\\\"}\",\"name\":\"fetch\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"HTML test file Purpose: Provide example of this file type Document file type: HTML Version: 1.0 Remark: Example content: The names \\\"John Doe\\\" for males, \\\"Jane Doe\\\" or \\\"Jane Roe\\\" for females, or \\\"Jonnie Doe\\\" and \\\"Janie Doe\\\" for children, or just \\\"Doe\\\" non-gender-specifically are used as placeholder names for a party whose true identity is unknown or must be withheld in a legal action, case, or discussion. The names are also used to refer to acorpse or hospital patient whose identity is unknown. This practice is widely used in the United States and Canada, but is rarely used in other English-speaking countries including the United Kingdom itself, from where the use of \\\"John Doe\\\" in a legal context originates. The names Joe Bloggs or John Smith are used in the UK instead, as well as in Australia and New Zealand. John Doe is sometimes used to refer to a typical male in other contexts as well, in a similar manner to John Q. Public, known in Great Britain as Joe Public, John Smith or Joe Bloggs. For example, the first name listed on a form is often John Doe, along with a fictional address or other fictional information to provide an example of how to fill in the form. The name is also used frequently in popular culture, for example in the Frank Capra film Meet John Doe. John Doe was also the name of a 2002 American television series. Similarly, a child or baby whose identity is unknown may be referred to as Baby Doe. A notorious murder case in Kansas City, Missouri, referred to the baby victim as Precious Doe. Other unidentified female murder victims are Cali Doe and Princess Doe. Additional persons may be called James Doe, Judy Doe, etc. However, to avoid possible confusion, if two anonymous or unknown parties are cited in a specific case or action, the surnames Doe and Roe may be used simultaneously; for example, \\\"John Doe v. Jane Roe\\\". If several anonymous parties are referenced, they may simply be labelled John Doe #1, John Doe #2, etc. (the U.S. Operation Delego cited 21 (numbered) \\\"John Doe\\\"s) or labelled with other variants of Doe / Roe / Poe / etc. Other early alternatives such as John Stiles and Richard Miles are now rarely used, and Mary Major has been used in some American federal cases. File created by https://www.online-convert.com More example files: https://www.online-convert.com/file-type Text of \\\"Example content\\\": Wikipedia License: Attribution-ShareAlike 3.0 Unported Feel free to use and share the file according to license above.\",\"tool_call_id\":\"019d980a55ccb97115543c42140e8984\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
171217 headers:
172218 Accept:
173219 - application/json
@@ -184,23 +230,85 @@ interactions:
184230 content_length: -1
185231 uncompressed: true
186232 body: |+
187− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
233+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
234+
235+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Yes"},"finish_reason":null}]}
236+
237+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":","},"finish_reason":null}]}
238+
239+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
240+
241+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" page"},"finish_reason":null}]}
242+
243+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" contains"},"finish_reason":null}]}
244+
245+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
246+
247+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" word"},"finish_reason":null}]}
248+
249+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" \""},"finish_reason":null}]}
250+
251+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"John"},"finish_reason":null}]}
252+
253+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Doe"},"finish_reason":null}]}
254+
255+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"\""},"finish_reason":null}]}
256+
257+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" —"},"finish_reason":null}]}
258+
259+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" it"},"finish_reason":null}]}
260+
261+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" appears"},"finish_reason":null}]}
262+
263+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" multiple"},"finish_reason":null}]}
264+
265+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" times"},"finish_reason":null}]}
266+
267+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" throughout"},"finish_reason":null}]}
268+
269+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
270+
271+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" content"},"finish_reason":null}]}
272+
273+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":","},"finish_reason":null}]}
274+
275+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" discussing"},"finish_reason":null}]}
276+
277+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
278+
279+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" use"},"finish_reason":null}]}
280+
281+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" of"},"finish_reason":null}]}
282+
283+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" \""},"finish_reason":null}]}
284+
285+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"John"},"finish_reason":null}]}
286+
287+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Doe"},"finish_reason":null}]}
288+
289+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"\""},"finish_reason":null}]}
290+
291+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" as"},"finish_reason":null}]}
292+
293+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" a"},"finish_reason":null}]}
294+
295+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" placeholder"},"finish_reason":null}]}
188296
189− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Yes, the fetched"},"finish_reason":null}]}
297+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" name"},"finish_reason":null}]}
190298
191− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" content contains the word"},"finish_reason":null}]}
299+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
192300
193− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" \"John Doe\""},"finish_reason":null}]}
301+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" legal"},"finish_reason":null}]}
194302
195− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" — in"},"finish_reason":null}]}
303+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
196304
197− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" fact, it appears"},"finish_reason":null}]}
305+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" cultural"},"finish_reason":null}]}
198306
199− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" multiple times throughout the"},"finish_reason":null}]}
307+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" contexts"},"finish_reason":null}]}
200308
201− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" text."},"finish_reason":null}]}
309+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
202310
203− data: {"id":"chatcmpl-2132e32f008c1a41b502b662","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":614,"completion_tokens":25,"total_tokens":8063}}
311+ data: {"id":"chatcmpl-970ea7f2c2919000d508e445","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":1150,"completion_tokens":39,"total_tokens":8101}}
204312
205313 data: [DONE]
206314
@@ -209,4 +317,4 @@ interactions:
209317 - text/event-stream
210318 status: 200 OK
211319 code: 200
212− duration: 1.222369s
320+ duration: 1.808678375s
internal/agent/testdata/TestCoderAgent/glm-5.1/glob_tool.yaml+99−27
@@ -25,25 +25,29 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Using"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Glob"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" glob"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" find"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" locate"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" all"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" all"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ."},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ."},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
44+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
4545
46− data: {"id":"chatcmpl-3cfe877f3e43495141315c3b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3,"completion_tokens":98,"total_tokens":309}}
46+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" current"},"finish_reason":null}]}
47+
48+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" directory"},"finish_reason":null}]}
49+
50+ data: {"id":"chatcmpl-be405350a6a14c0be30ea59b","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3,"completion_tokens":321,"total_tokens":532}}
4751
4852 data: [DONE]
4953
@@ -52,15 +56,15 @@ interactions:
5256 - text/event-stream
5357 status: 200 OK
5458 code: 200
55− duration: 1.296821833s
59+ duration: 3.449660583s
5660- id: 1
5761 request:
5862 proto: HTTP/1.1
5963 proto_major: 1
6064 proto_minor: 1
61− content_length: 32340
65+ content_length: 32475
6266 host: ""
63− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files in the current directory\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
67+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files in the current directory\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6468 headers:
6569 Accept:
6670 - application/json
@@ -77,13 +81,65 @@ interactions:
7781 content_length: -1
7882 uncompressed: true
7983 body: |+
80− data: {"id":"chatcmpl-5f4e0955f0237ffc41462aae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
84+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980a7b943969b8d2764ac2c70689","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"path\": "}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
81117
82− data: {"id":"chatcmpl-5f4e0955f0237ffc41462aae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_c579","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
118+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
83119
84− data: {"id":"chatcmpl-5f4e0955f0237ffc41462aae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\", \"pattern\": \"*.go\"}"}}]},"finish_reason":null}]}
120+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
85121
86− data: {"id":"chatcmpl-5f4e0955f0237ffc41462aae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":492,"completion_tokens":50,"total_tokens":7486}}
122+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lob"}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
125+
126+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
127+
128+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
129+
130+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"pattern\": "}}]},"finish_reason":null}]}
131+
132+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"**"}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/*."}}]},"finish_reason":null}]}
135+
136+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"go"}}]},"finish_reason":null}]}
137+
138+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
141+
142+ data: {"id":"chatcmpl-7eb611d22a4875856758021f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":548,"completion_tokens":37,"total_tokens":7497}}
87143
88144 data: [DONE]
89145
@@ -92,15 +148,15 @@ interactions:
92148 - text/event-stream
93149 status: 200 OK
94150 code: 200
95− duration: 2.706239375s
151+ duration: 5.499890584s
96152- id: 2
97153 request:
98154 proto: HTTP/1.1
99155 proto_major: 1
100156 proto_minor: 1
101− content_length: 32654
157+ content_length: 32838
102158 host: ""
103− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files in the current directory\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_c579\",\"function\":{\"arguments\":\"{\\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\\\", \\\"pattern\\\": \\\"*.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool/main.go\",\"tool_call_id\":\"call_c579\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
159+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files in the current directory\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980a7b943969b8d2764ac2c70689\",\"function\":{\"arguments\":\"{\\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool\\\", \\\"pattern\\\": \\\"**/*.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/glob_tool/main.go\",\"tool_call_id\":\"019d980a7b943969b8d2764ac2c70689\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
104160 headers:
105161 Accept:
106162 - application/json
@@ -117,17 +173,33 @@ interactions:
117173 content_length: -1
118174 uncompressed: true
119175 body: |+
120− data: {"id":"chatcmpl-2099ea6da063bf5cea9bee06","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
176+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Found"},"finish_reason":null}]}
179+
180+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" "},"finish_reason":null}]}
181+
182+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1"},"finish_reason":null}]}
183+
184+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `."},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
189+
190+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" file"},"finish_reason":null}]}
191+
192+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
121193
122− data: {"id":"chatcmpl-2099ea6da063bf5cea9bee06","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Found "},"finish_reason":null}]}
194+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
123195
124− data: {"id":"chatcmpl-2099ea6da063bf5cea9bee06","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1 `.go`"},"finish_reason":null}]}
196+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"main"},"finish_reason":null}]}
125197
126− data: {"id":"chatcmpl-2099ea6da063bf5cea9bee06","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" file: `main"},"finish_reason":null}]}
198+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
127199
128− data: {"id":"chatcmpl-2099ea6da063bf5cea9bee06","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go`"},"finish_reason":null}]}
200+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
129201
130− data: {"id":"chatcmpl-2099ea6da063bf5cea9bee06","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":67,"completion_tokens":19,"total_tokens":7510}}
202+ data: {"id":"chatcmpl-6aa46a0211060f316dbbb9c7","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":604,"completion_tokens":13,"total_tokens":7529}}
131203
132204 data: [DONE]
133205
@@ -136,4 +208,4 @@ interactions:
136208 - text/event-stream
137209 status: 200 OK
138210 code: 200
139− duration: 927.392666ms
211+ duration: 2.097128083s
internal/agent/testdata/TestCoderAgent/glm-5.1/grep_tool.yaml+106−30
@@ -25,25 +25,21 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"G"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"grep"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"rep"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" package"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" package"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" keyword"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
43−
44− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
45−
46− data: {"id":"chatcmpl-a61867d88e9d964d2a4002f9","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":4,"completion_tokens":90,"total_tokens":302}}
42+ data: {"id":"chatcmpl-6447644de0cdc41f425ac1ec","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":4,"completion_tokens":108,"total_tokens":320}}
4743
4844 data: [DONE]
4945
@@ -52,15 +48,15 @@ interactions:
5248 - text/event-stream
5349 status: 200 OK
5450 code: 200
55− duration: 1.423312541s
51+ duration: 1.424877917s
5652- id: 1
5753 request:
5854 proto: HTTP/1.1
5955 proto_major: 1
6056 proto_minor: 1
61− content_length: 32338
57+ content_length: 32473
6258 host: ""
63− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use grep to search for the word 'package' in go files\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
59+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use grep to search for the word 'package' in go files\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6460 headers:
6561 Accept:
6662 - application/json
@@ -77,13 +73,71 @@ interactions:
7773 content_length: -1
7874 uncompressed: true
7975 body: |+
80− data: {"id":"chatcmpl-6502c9fd39e3b313ee22aca8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
76+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
77+
78+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980a964b282889458c0b70527f59","type":"function","index":0,"function":{"name":"grep","arguments":""}}]},"finish_reason":null}]}
79+
80+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
81+
82+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"include\": "}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"*."}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"go"}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"path\": "}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
81115
82− data: {"id":"chatcmpl-6502c9fd39e3b313ee22aca8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_051a","type":"function","index":0,"function":{"name":"grep","arguments":""}}]},"finish_reason":null}]}
116+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
83117
84− data: {"id":"chatcmpl-6502c9fd39e3b313ee22aca8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"include\": \"*.go\", \"path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\", \"pattern\": \"package\"}"}}]},"finish_reason":null}]}
118+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
85119
86− data: {"id":"chatcmpl-6502c9fd39e3b313ee22aca8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":493,"completion_tokens":57,"total_tokens":7494}}
120+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rep"}}]},"finish_reason":null}]}
125+
126+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
127+
128+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
129+
130+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
131+
132+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"pattern\": "}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"package"}}]},"finish_reason":null}]}
135+
136+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
137+
138+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-161070432b6d319690d8c4ae","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":549,"completion_tokens":59,"total_tokens":7520}}
87141
88142 data: [DONE]
89143
@@ -92,15 +146,15 @@ interactions:
92146 - text/event-stream
93147 status: 200 OK
94148 code: 200
95− duration: 2.651192042s
149+ duration: 3.458155083s
96150- id: 2
97151 request:
98152 proto: HTTP/1.1
99153 proto_major: 1
100154 proto_minor: 1
101− content_length: 32730
155+ content_length: 32911
102156 host: ""
103− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use grep to search for the word 'package' in go files\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_051a\",\"function\":{\"arguments\":\"{\\\"include\\\": \\\"*.go\\\", \\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\\\", \\\"pattern\\\": \\\"package\\\"}\",\"name\":\"grep\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"Found 1 matches\\n/tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool/main.go:\\n Line 1, Char 1: package main\\n\",\"tool_call_id\":\"call_051a\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
157+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use grep to search for the word 'package' in go files\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980a964b282889458c0b70527f59\",\"function\":{\"arguments\":\"{\\\"include\\\": \\\"*.go\\\", \\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool\\\", \\\"pattern\\\": \\\"package\\\"}\",\"name\":\"grep\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"Found 1 matches\\n/tmp/crush-test/TestCoderAgent/glm-5.1/grep_tool/main.go:\\n Line 1, Char 1: package main\\n\",\"tool_call_id\":\"019d980a964b282889458c0b70527f59\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
104158 headers:
105159 Accept:
106160 - application/json
@@ -117,19 +171,41 @@ interactions:
117171 content_length: -1
118172 uncompressed: true
119173 body: |+
120− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
174+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1"},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" match"},"finish_reason":null}]}
179+
180+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" found"},"finish_reason":null}]}
181+
182+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":\n\n"},"finish_reason":null}]}
183+
184+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-"},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"main"},"finish_reason":null}]}
189+
190+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
191+
192+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
193+
194+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1"},"finish_reason":null}]}
195+
196+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
121197
122− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Found 1 match"},"finish_reason":null}]}
198+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" —"},"finish_reason":null}]}
123199
124− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":\n\n"},"finish_reason":null}]}
200+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
125201
126− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"- `main.go"},"finish_reason":null}]}
202+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"package"},"finish_reason":null}]}
127203
128− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":1` —"},"finish_reason":null}]}
204+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
129205
130− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `package main`"},"finish_reason":null}]}
206+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
131207
132− data: {"id":"chatcmpl-571f74a04c65e3fcbd5f6ca0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":92,"completion_tokens":18,"total_tokens":7534}}
208+ data: {"id":"chatcmpl-1f4af059d2eaa570d13f611b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":628,"completion_tokens":17,"total_tokens":7557}}
133209
134210 data: [DONE]
135211
@@ -138,4 +214,4 @@ interactions:
138214 - text/event-stream
139215 status: 200 OK
140216 code: 200
141− duration: 921.10325ms
217+ duration: 2.22835575s
internal/agent/testdata/TestCoderAgent/glm-5.1/ls_tool.yaml+87−29
@@ -25,23 +25,21 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Listing"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"List"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" current"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" directory"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" current"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" directory"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ls"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ls"},"finish_reason":null}]}
43−
44− data: {"id":"chatcmpl-c6c4ead5516073eb6f94f289","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":1,"completion_tokens":158,"total_tokens":367}}
42+ data: {"id":"chatcmpl-808ff38e4347f4a1cff78d6a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":1,"completion_tokens":67,"total_tokens":276}}
4543
4644 data: [DONE]
4745
@@ -50,15 +48,15 @@ interactions:
5048 - text/event-stream
5149 status: 200 OK
5250 code: 200
53− duration: 1.9139675s
51+ duration: 1.046801209s
5452- id: 1
5553 request:
5654 proto: HTTP/1.1
5755 proto_major: 1
5856 proto_minor: 1
59− content_length: 32332
57+ content_length: 32467
6058 host: ""
61− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use ls to list the files in the current directory\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
59+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use ls to list the files in the current directory\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6260 headers:
6361 Accept:
6462 - application/json
@@ -75,13 +73,53 @@ interactions:
7573 content_length: -1
7674 uncompressed: true
7775 body: |+
78− data: {"id":"chatcmpl-9537a15c444d5040a1c5b3d0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
76+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
77+
78+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980aaf5083fb4414e4a7a764ae6c","type":"function","index":0,"function":{"name":"ls","arguments":""}}]},"finish_reason":null}]}
79+
80+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
81+
82+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"path\": "}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
79107
80− data: {"id":"chatcmpl-9537a15c444d5040a1c5b3d0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_ae10","type":"function","index":0,"function":{"name":"ls","arguments":""}}]},"finish_reason":null}]}
108+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
81109
82− data: {"id":"chatcmpl-9537a15c444d5040a1c5b3d0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{}"}}]},"finish_reason":null}]}
110+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
83111
84− data: {"id":"chatcmpl-9537a15c444d5040a1c5b3d0","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":490,"completion_tokens":4,"total_tokens":7438}}
112+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ls"}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
117+
118+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
119+
120+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-d3ab71a7e37d5f256710a101","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":546,"completion_tokens":25,"total_tokens":7483}}
85123
86124 data: [DONE]
87125
@@ -90,15 +128,15 @@ interactions:
90128 - text/event-stream
91129 status: 200 OK
92130 code: 200
93− duration: 2.733496542s
131+ duration: 3.106974708s
94132- id: 2
95133 request:
96134 proto: HTTP/1.1
97135 proto_major: 1
98136 proto_minor: 1
99− content_length: 32581
137+ content_length: 32822
100138 host: ""
101− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use ls to list the files in the current directory\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_ae10\",\"function\":{\"arguments\":\"{}\",\"name\":\"ls\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"\\n- /tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool/\\n - go.mod\\n - main.go\\n\",\"tool_call_id\":\"call_ae10\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
139+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use ls to list the files in the current directory\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980aaf5083fb4414e4a7a764ae6c\",\"function\":{\"arguments\":\"{\\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool\\\"}\",\"name\":\"ls\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"\\n- /tmp/crush-test/TestCoderAgent/glm-5.1/ls_tool/\\n - go.mod\\n - main.go\\n\",\"tool_call_id\":\"019d980aaf5083fb4414e4a7a764ae6c\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
102140 headers:
103141 Accept:
104142 - application/json
@@ -115,21 +153,41 @@ interactions:
115153 content_length: -1
116154 uncompressed: true
117155 body: |+
118− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
156+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}
159+
160+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" directory"},"finish_reason":null}]}
161+
162+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" contains"},"finish_reason":null}]}
163+
164+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" two"},"finish_reason":null}]}
165+
166+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
167+
168+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":\n\n"},"finish_reason":null}]}
169+
170+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-"},"finish_reason":null}]}
171+
172+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
173+
174+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".mod"},"finish_reason":null}]}
119177
120− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}
178+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`\n"},"finish_reason":null}]}
121179
122− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" current"},"finish_reason":null}]}
180+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-"},"finish_reason":null}]}
123181
124− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" directory contains:\n"},"finish_reason":null}]}
182+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
125183
126− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"- `go.mod"},"finish_reason":null}]}
184+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"main"},"finish_reason":null}]}
127185
128− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`\n- `main"},"finish_reason":null}]}
186+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
129187
130− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go`"},"finish_reason":null}]}
188+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
131189
132− data: {"id":"chatcmpl-237e558d53f2023ebb8628c4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":49,"completion_tokens":16,"total_tokens":7489}}
190+ data: {"id":"chatcmpl-b117b658e98e051fc50e95ef","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":606,"completion_tokens":17,"total_tokens":7535}}
133191
134192 data: [DONE]
135193
@@ -138,4 +196,4 @@ interactions:
138196 - text/event-stream
139197 status: 200 OK
140198 code: 200
141− duration: 924.641667ms
199+ duration: 1.844230375s
internal/agent/testdata/TestCoderAgent/glm-5.1/multiedit_tool.yaml+705−43
@@ -25,27 +25,25 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Replace"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Replace"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Hello"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" greeting"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" World"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" add"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Hello"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" comment"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Crush"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":";"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" add"},"finish_reason":null}]}
44+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
4545
46− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" comment"},"finish_reason":null}]}
47−
48− data: {"id":"chatcmpl-fef68092ac4de4729277a40c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":7,"completion_tokens":401,"total_tokens":632}}
46+ data: {"id":"chatcmpl-e79e8b371d7ee5b55bed5aeb","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":7,"completion_tokens":188,"total_tokens":419}}
4947
5048 data: [DONE]
5149
@@ -54,15 +52,15 @@ interactions:
5452 - text/event-stream
5553 status: 200 OK
5654 code: 200
57− duration: 4.246228334s
55+ duration: 2.188941416s
5856- id: 1
5957 request:
6058 proto: HTTP/1.1
6159 proto_major: 1
6260 proto_minor: 1
63− content_length: 32418
61+ content_length: 32553
6462 host: ""
65− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
63+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6664 headers:
6765 Accept:
6866 - application/json
@@ -79,13 +77,61 @@ interactions:
7977 content_length: -1
8078 uncompressed: true
8179 body: |+
82− data: {"id":"chatcmpl-ca3fb7991d5bc4b116b79d08","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
80+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
81+
82+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980acc2bb228d009055e0673f835","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/m"}}]},"finish_reason":null}]}
117+
118+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ult"}}]},"finish_reason":null}]}
119+
120+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ied"}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"it"}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
125+
126+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
83127
84− data: {"id":"chatcmpl-ca3fb7991d5bc4b116b79d08","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_4cfa","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
128+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
85129
86− data: {"id":"chatcmpl-ca3fb7991d5bc4b116b79d08","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\"}"}}]},"finish_reason":null}]}
130+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
87131
88− data: {"id":"chatcmpl-ca3fb7991d5bc4b116b79d08","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":515,"completion_tokens":44,"total_tokens":7503}}
132+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-a28325fc9bb6f2505ba4baec","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":571,"completion_tokens":44,"total_tokens":7527}}
89135
90136 data: [DONE]
91137
@@ -94,15 +140,15 @@ interactions:
94140 - text/event-stream
95141 status: 200 OK
96142 code: 200
97− duration: 5.575144334s
143+ duration: 4.560594958s
98144- id: 2
99145 request:
100146 proto: HTTP/1.1
101147 proto_major: 1
102148 proto_minor: 1
103− content_length: 32823
149+ content_length: 33004
104150 host: ""
105− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_4cfa\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"call_4cfa\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
151+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980acc2bb228d009055e0673f835\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980acc2bb228d009055e0673f835\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
106152 headers:
107153 Accept:
108154 - application/json
@@ -119,13 +165,177 @@ interactions:
119165 content_length: -1
120166 uncompressed: true
121167 body: |+
122− data: {"id":"chatcmpl-f3d24af77f3323ceb127c6b8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
168+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
169+
170+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980ad655eff2f092778e3088393f","type":"function","index":0,"function":{"name":"multiedit","arguments":""}}]},"finish_reason":null}]}
171+
172+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
173+
174+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"edits\": "}}]},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"["}}]},"finish_reason":null}]}
179+
180+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\""}}]},"finish_reason":null}]}
181+
182+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"new"}}]},"finish_reason":null}]}
183+
184+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_string"}}]},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\":"}}]},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \""}}]},"finish_reason":null}]}
189+
190+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
191+
192+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
193+
194+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" Crush"}}]},"finish_reason":null}]}
195+
196+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\","}}]},"finish_reason":null}]}
197+
198+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \""}}]},"finish_reason":null}]}
199+
200+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"old"}}]},"finish_reason":null}]}
201+
202+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_string"}}]},"finish_reason":null}]}
203+
204+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\":"}}]},"finish_reason":null}]}
205+
206+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \""}}]},"finish_reason":null}]}
207+
208+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
209+
210+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
211+
212+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" World"}}]},"finish_reason":null}]}
213+
214+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\""}}]},"finish_reason":null}]}
215+
216+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"},"}}]},"finish_reason":null}]}
217+
218+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" {\""}}]},"finish_reason":null}]}
219+
220+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"new"}}]},"finish_reason":null}]}
221+
222+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_string"}}]},"finish_reason":null}]}
223+
224+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\":"}}]},"finish_reason":null}]}
225+
226+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \"\\"}}]},"finish_reason":null}]}
227+
228+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"t"}}]},"finish_reason":null}]}
229+
230+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"//"}}]},"finish_reason":null}]}
231+
232+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" G"}}]},"finish_reason":null}]}
233+
234+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"reeting"}}]},"finish_reason":null}]}
235+
236+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\n"}}]},"finish_reason":null}]}
237+
238+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\t"}}]},"finish_reason":null}]}
239+
240+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"fmt"}}]},"finish_reason":null}]}
241+
242+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".Println"}}]},"finish_reason":null}]}
243+
244+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"(\\\""}}]},"finish_reason":null}]}
245+
246+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
247+
248+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
249+
250+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" Crush"}}]},"finish_reason":null}]}
251+
252+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\\"}}]},"finish_reason":null}]}
253+
254+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\")"}}]},"finish_reason":null}]}
255+
256+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\","}}]},"finish_reason":null}]}
257+
258+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \""}}]},"finish_reason":null}]}
259+
260+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"old"}}]},"finish_reason":null}]}
261+
262+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_string"}}]},"finish_reason":null}]}
263+
264+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\":"}}]},"finish_reason":null}]}
265+
266+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \"\\"}}]},"finish_reason":null}]}
267+
268+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"t"}}]},"finish_reason":null}]}
269+
270+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"fmt"}}]},"finish_reason":null}]}
271+
272+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".Println"}}]},"finish_reason":null}]}
273+
274+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"(\\\""}}]},"finish_reason":null}]}
275+
276+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
277+
278+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
279+
280+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" World"}}]},"finish_reason":null}]}
281+
282+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\\"}}]},"finish_reason":null}]}
283+
284+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\")"}}]},"finish_reason":null}]}
285+
286+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"}"}}]},"finish_reason":null}]}
287+
288+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"]"}}]},"finish_reason":null}]}
289+
290+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
291+
292+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
293+
294+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
295+
296+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
297+
298+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
299+
300+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
301+
302+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
303+
304+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
123305
124− data: {"id":"chatcmpl-f3d24af77f3323ceb127c6b8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_771d","type":"function","index":0,"function":{"name":"multiedit","arguments":""}}]},"finish_reason":null}]}
306+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
125307
126− data: {"id":"chatcmpl-f3d24af77f3323ceb127c6b8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"edits\": [{\"new_string\": \"\\\"Hello, Crush!\\\"\", \"old_string\": \"\\\"Hello, World!\\\"\"}, {\"new_string\": \"\\t// Greeting\\n\\tfmt.Println(\\\"Hello, Crush!\\\")\", \"old_string\": \"\\tfmt.Println(\\\"Hello, Crush!\\\")\"}], \"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\"}"}}]},"finish_reason":null}]}
308+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
127309
128− data: {"id":"chatcmpl-f3d24af77f3323ceb127c6b8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":90,"completion_tokens":96,"total_tokens":7642}}
310+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
311+
312+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
313+
314+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
315+
316+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
317+
318+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
319+
320+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/m"}}]},"finish_reason":null}]}
321+
322+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ult"}}]},"finish_reason":null}]}
323+
324+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ied"}}]},"finish_reason":null}]}
325+
326+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"it"}}]},"finish_reason":null}]}
327+
328+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
329+
330+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
331+
332+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
333+
334+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
335+
336+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
337+
338+ data: {"id":"chatcmpl-9e0fb0e8c92dd288331f2d58","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":146,"completion_tokens":94,"total_tokens":7664}}
129339
130340 data: [DONE]
131341
@@ -134,15 +344,103 @@ interactions:
134344 - text/event-stream
135345 status: 200 OK
136346 code: 200
137− duration: 2.256761042s
347+ duration: 2.16195225s
138348- id: 3
139349 request:
140350 proto: HTTP/1.1
141351 proto_major: 1
142352 proto_minor: 1
143− content_length: 33428
353+ content_length: 33663
354+ host: ""
355+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980acc2bb228d009055e0673f835\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980acc2bb228d009055e0673f835\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980ad655eff2f092778e3088393f\",\"function\":{\"arguments\":\"{\\\"edits\\\": [{\\\"new_string\\\": \\\"Hello, Crush!\\\", \\\"old_string\\\": \\\"Hello, World!\\\"}, {\\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, World!\\\\\\\")\\\"}], \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"multiedit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nApplied 1 of 2 edits to file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go (1 edit(s) failed)\\n</result>\\n\",\"tool_call_id\":\"019d980ad655eff2f092778e3088393f\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
356+ headers:
357+ Accept:
358+ - application/json
359+ Content-Type:
360+ - application/json
361+ User-Agent:
362+ - Charm-Crush/devel (https://charm.land/crush)
363+ url: https://hyper.charm.land/v1/chat/completions
364+ method: POST
365+ response:
366+ proto: HTTP/2.0
367+ proto_major: 2
368+ proto_minor: 0
369+ content_length: -1
370+ uncompressed: true
371+ body: |+
372+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
373+
374+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980aec07963a4e3e3f98481064f7","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
375+
376+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
377+
378+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
379+
380+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
381+
382+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
383+
384+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
385+
386+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
387+
388+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
389+
390+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
391+
392+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
393+
394+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
395+
396+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
397+
398+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
399+
400+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
401+
402+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
403+
404+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
405+
406+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
407+
408+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/m"}}]},"finish_reason":null}]}
409+
410+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ult"}}]},"finish_reason":null}]}
411+
412+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ied"}}]},"finish_reason":null}]}
413+
414+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"it"}}]},"finish_reason":null}]}
415+
416+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
417+
418+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
419+
420+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
421+
422+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
423+
424+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
425+
426+ data: {"id":"chatcmpl-82878a4edb7bd9f6cc1b1545","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":801,"completion_tokens":81,"total_tokens":7794}}
427+
428+ data: [DONE]
429+
430+ headers:
431+ Content-Type:
432+ - text/event-stream
433+ status: 200 OK
434+ code: 200
435+ duration: 3.809239083s
436+- id: 4
437+ request:
438+ proto: HTTP/1.1
439+ proto_major: 1
440+ proto_minor: 1
441+ content_length: 34114
144442 host: ""
145− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_4cfa\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"call_4cfa\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"call_771d\",\"function\":{\"arguments\":\"{\\\"edits\\\": [{\\\"new_string\\\": \\\"\\\\\\\"Hello, Crush!\\\\\\\"\\\", \\\"old_string\\\": \\\"\\\\\\\"Hello, World!\\\\\\\"\\\"}, {\\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\"}], \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"multiedit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nApplied 2 edits to file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\n</result>\\n\",\"tool_call_id\":\"call_771d\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
443+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980acc2bb228d009055e0673f835\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980acc2bb228d009055e0673f835\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980ad655eff2f092778e3088393f\",\"function\":{\"arguments\":\"{\\\"edits\\\": [{\\\"new_string\\\": \\\"Hello, Crush!\\\", \\\"old_string\\\": \\\"Hello, World!\\\"}, {\\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, World!\\\\\\\")\\\"}], \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"multiedit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nApplied 1 of 2 edits to file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go (1 edit(s) failed)\\n</result>\\n\",\"tool_call_id\":\"019d980ad655eff2f092778e3088393f\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980aec07963a4e3e3f98481064f7\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, Crush!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980aec07963a4e3e3f98481064f7\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
146444 headers:
147445 Accept:
148446 - application/json
@@ -159,31 +457,395 @@ interactions:
159457 content_length: -1
160458 uncompressed: true
161459 body: |+
162− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
460+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
461+
462+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}
463+
464+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" second"},"finish_reason":null}]}
465+
466+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" edit"},"finish_reason":null}]}
467+
468+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" failed"},"finish_reason":null}]}
469+
470+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" because"},"finish_reason":null}]}
471+
472+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
473+
474+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" first"},"finish_reason":null}]}
475+
476+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" edit"},"finish_reason":null}]}
477+
478+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" already"},"finish_reason":null}]}
479+
480+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" changed"},"finish_reason":null}]}
481+
482+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
483+
484+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" text"},"finish_reason":null}]}
485+
486+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
487+
488+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" I"},"finish_reason":null}]}
489+
490+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" need"},"finish_reason":null}]}
491+
492+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
493+
494+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" match"},"finish_reason":null}]}
495+
496+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
497+
498+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" current"},"finish_reason":null}]}
499+
500+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" state"},"finish_reason":null}]}
501+
502+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
503+
504+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980af8741ef15be41ce9080c6765","type":"function","index":0,"function":{"name":"edit","arguments":""}}]},"finish_reason":null}]}
505+
506+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
507+
508+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
509+
510+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
511+
512+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
513+
514+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
515+
516+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
517+
518+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
519+
520+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
521+
522+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
523+
524+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
525+
526+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
527+
528+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
529+
530+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
531+
532+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
533+
534+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
535+
536+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
537+
538+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/m"}}]},"finish_reason":null}]}
539+
540+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ult"}}]},"finish_reason":null}]}
541+
542+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ied"}}]},"finish_reason":null}]}
543+
544+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"it"}}]},"finish_reason":null}]}
545+
546+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
547+
548+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
549+
550+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
551+
552+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
553+
554+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
555+
556+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"new_string\": "}}]},"finish_reason":null}]}
557+
558+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"\\t//"}}]},"finish_reason":null}]}
559+
560+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" G"}}]},"finish_reason":null}]}
561+
562+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"reeting"}}]},"finish_reason":null}]}
563+
564+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\n\\tfmt"}}]},"finish_reason":null}]}
565+
566+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".Println"}}]},"finish_reason":null}]}
567+
568+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"(\\\""}}]},"finish_reason":null}]}
569+
570+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
571+
572+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
573+
574+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" Crush"}}]},"finish_reason":null}]}
575+
576+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\\\")"}}]},"finish_reason":null}]}
577+
578+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
579+
580+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
581+
582+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"old_string\": "}}]},"finish_reason":null}]}
583+
584+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"\\tfmt"}}]},"finish_reason":null}]}
585+
586+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".Println"}}]},"finish_reason":null}]}
587+
588+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"(\\\""}}]},"finish_reason":null}]}
589+
590+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
591+
592+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
593+
594+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" Crush"}}]},"finish_reason":null}]}
595+
596+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\\\")"}}]},"finish_reason":null}]}
597+
598+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
599+
600+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
601+
602+ data: {"id":"chatcmpl-131bad11a8c749ef0a9d269d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":248,"completion_tokens":82,"total_tokens":7882}}
603+
604+ data: [DONE]
605+
606+ headers:
607+ Content-Type:
608+ - text/event-stream
609+ status: 200 OK
610+ code: 200
611+ duration: 2.194032791s
612+- id: 5
613+ request:
614+ proto: HTTP/1.1
615+ proto_major: 1
616+ proto_minor: 1
617+ content_length: 34777
618+ host: ""
619+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980acc2bb228d009055e0673f835\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980acc2bb228d009055e0673f835\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980ad655eff2f092778e3088393f\",\"function\":{\"arguments\":\"{\\\"edits\\\": [{\\\"new_string\\\": \\\"Hello, Crush!\\\", \\\"old_string\\\": \\\"Hello, World!\\\"}, {\\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, World!\\\\\\\")\\\"}], \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"multiedit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nApplied 1 of 2 edits to file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go (1 edit(s) failed)\\n</result>\\n\",\"tool_call_id\":\"019d980ad655eff2f092778e3088393f\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980aec07963a4e3e3f98481064f7\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, Crush!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980aec07963a4e3e3f98481064f7\",\"role\":\"tool\"},{\"content\":\"The second edit failed because the first edit already changed the text. I need to match the current state:\",\"tool_calls\":[{\"id\":\"019d980af8741ef15be41ce9080c6765\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\", \\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\"}\",\"name\":\"edit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nContent replaced in file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\n</result>\\n\",\"tool_call_id\":\"019d980af8741ef15be41ce9080c6765\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
620+ headers:
621+ Accept:
622+ - application/json
623+ Content-Type:
624+ - application/json
625+ User-Agent:
626+ - Charm-Crush/devel (https://charm.land/crush)
627+ url: https://hyper.charm.land/v1/chat/completions
628+ method: POST
629+ response:
630+ proto: HTTP/2.0
631+ proto_major: 2
632+ proto_minor: 0
633+ content_length: -1
634+ uncompressed: true
635+ body: |+
636+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
637+
638+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980b04aad430ec4f90f1986e1df8","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
639+
640+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
641+
642+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
643+
644+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
645+
646+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
647+
648+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
649+
650+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
651+
652+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
653+
654+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
655+
656+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
657+
658+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
659+
660+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
661+
662+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
663+
664+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
665+
666+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
667+
668+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
669+
670+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
671+
672+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/m"}}]},"finish_reason":null}]}
673+
674+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ult"}}]},"finish_reason":null}]}
675+
676+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"ied"}}]},"finish_reason":null}]}
677+
678+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"it"}}]},"finish_reason":null}]}
679+
680+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
681+
682+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
683+
684+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
685+
686+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
687+
688+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
689+
690+ data: {"id":"chatcmpl-f72e401d92a5686c51fdde3d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":1008,"completion_tokens":30,"total_tokens":7950}}
691+
692+ data: [DONE]
693+
694+ headers:
695+ Content-Type:
696+ - text/event-stream
697+ status: 200 OK
698+ code: 200
699+ duration: 2.116214375s
700+- id: 6
701+ request:
702+ proto: HTTP/1.1
703+ proto_major: 1
704+ proto_minor: 1
705+ content_length: 35250
706+ host: ""
707+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use multiedit to change 'Hello, World!' to 'Hello, Crush!' and add a comment '// Greeting' above the fmt.Println line in main.go\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980acc2bb228d009055e0673f835\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980acc2bb228d009055e0673f835\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980ad655eff2f092778e3088393f\",\"function\":{\"arguments\":\"{\\\"edits\\\": [{\\\"new_string\\\": \\\"Hello, Crush!\\\", \\\"old_string\\\": \\\"Hello, World!\\\"}, {\\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, World!\\\\\\\")\\\"}], \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"multiedit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nApplied 1 of 2 edits to file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go (1 edit(s) failed)\\n</result>\\n\",\"tool_call_id\":\"019d980ad655eff2f092778e3088393f\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980aec07963a4e3e3f98481064f7\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, Crush!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d980aec07963a4e3e3f98481064f7\",\"role\":\"tool\"},{\"content\":\"The second edit failed because the first edit already changed the text. I need to match the current state:\",\"tool_calls\":[{\"id\":\"019d980af8741ef15be41ce9080c6765\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\", \\\"new_string\\\": \\\"\\\\t// Greeting\\\\n\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, Crush!\\\\\\\")\\\"}\",\"name\":\"edit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nContent replaced in file: /tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\n</result>\\n\",\"tool_call_id\":\"019d980af8741ef15be41ce9080c6765\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d980b04aad430ec4f90f1986e1df8\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/multiedit_tool/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\t// Greeting\\n 7|\\tfmt.Println(\\\"Hello, Crush!\\\")\\n 8|}\\n</file>\\n\",\"tool_call_id\":\"019d980b04aad430ec4f90f1986e1df8\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
708+ headers:
709+ Accept:
710+ - application/json
711+ Content-Type:
712+ - application/json
713+ User-Agent:
714+ - Charm-Crush/devel (https://charm.land/crush)
715+ url: https://hyper.charm.land/v1/chat/completions
716+ method: POST
717+ response:
718+ proto: HTTP/2.0
719+ proto_major: 2
720+ proto_minor: 0
721+ content_length: -1
722+ uncompressed: true
723+ body: |+
724+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
725+
726+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Done"},"finish_reason":null}]}
727+
728+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
729+
730+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" The"},"finish_reason":null}]}
731+
732+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" mult"},"finish_reason":null}]}
733+
734+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"ied"},"finish_reason":null}]}
735+
736+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"it"},"finish_reason":null}]}
737+
738+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"'s"},"finish_reason":null}]}
739+
740+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" sequential"},"finish_reason":null}]}
741+
742+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" edits"},"finish_reason":null}]}
743+
744+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" conflic"},"finish_reason":null}]}
745+
746+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"ted"},"finish_reason":null}]}
747+
748+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" —"},"finish_reason":null}]}
749+
750+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
751+
752+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" first"},"finish_reason":null}]}
753+
754+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" edit"},"finish_reason":null}]}
755+
756+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" changed"},"finish_reason":null}]}
757+
758+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
759+
760+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" string"},"finish_reason":null}]}
761+
762+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":","},"finish_reason":null}]}
763+
764+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" so"},"finish_reason":null}]}
765+
766+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
767+
768+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" second"},"finish_reason":null}]}
769+
770+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" edit"},"finish_reason":null}]}
771+
772+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"'s"},"finish_reason":null}]}
773+
774+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
775+
776+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"old"},"finish_reason":null}]}
777+
778+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"_string"},"finish_reason":null}]}
779+
780+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
781+
782+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" no"},"finish_reason":null}]}
783+
784+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" longer"},"finish_reason":null}]}
785+
786+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" matched"},"finish_reason":null}]}
787+
788+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
789+
790+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Applied"},"finish_reason":null}]}
791+
792+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
793+
794+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" comment"},"finish_reason":null}]}
795+
796+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" via"},"finish_reason":null}]}
797+
798+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" a"},"finish_reason":null}]}
799+
800+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" separate"},"finish_reason":null}]}
801+
802+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" edit"},"finish_reason":null}]}
803+
804+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
805+
806+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Final"},"finish_reason":null}]}
807+
808+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" result"},"finish_reason":null}]}
809+
810+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
811+
812+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `\""},"finish_reason":null}]}
813+
814+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Hello"},"finish_reason":null}]}
815+
816+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":","},"finish_reason":null}]}
817+
818+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Crush"},"finish_reason":null}]}
819+
820+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"!\""},"finish_reason":null}]}
821+
822+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
823+
824+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
163825
164− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Done"},"finish_reason":null}]}
826+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
165827
166− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":". Changed"},"finish_reason":null}]}
828+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"//"},"finish_reason":null}]}
167829
168− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
830+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" G"},"finish_reason":null}]}
169831
170− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" greeting"},"finish_reason":null}]}
832+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"reeting"},"finish_reason":null}]}
171833
172− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" text"},"finish_reason":null}]}
834+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
173835
174− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" and added the"},"finish_reason":null}]}
836+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" comment"},"finish_reason":null}]}
175837
176− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `// Greeting"},"finish_reason":null}]}
838+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" above"},"finish_reason":null}]}
177839
178− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"` comment above"},"finish_reason":null}]}
840+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
179841
180− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
842+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" print"},"finish_reason":null}]}
181843
182− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `fmt.Println`"},"finish_reason":null}]}
844+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" line"},"finish_reason":null}]}
183845
184− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" line."},"finish_reason":null}]}
846+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
185847
186− data: {"id":"chatcmpl-540e983462b6a47b592d36e5","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":66,"completion_tokens":24,"total_tokens":7706}}
848+ data: {"id":"chatcmpl-d50728284afae0bd9a3e6391","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":144,"completion_tokens":62,"total_tokens":8078}}
187849
188850 data: [DONE]
189851
@@ -192,4 +854,4 @@ interactions:
192854 - text/event-stream
193855 status: 200 OK
194856 code: 200
195− duration: 970.935291ms
857+ duration: 2.14507825s
internal/agent/testdata/TestCoderAgent/glm-5.1/parallel_tool_calls.yaml+96−32
@@ -25,25 +25,27 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Parallel"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Parallel"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" glob"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" glob"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ."},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ."},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ls"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" listing"},"finish_reason":null}]}
44+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" ls"},"finish_reason":null}]}
4545
46− data: {"id":"chatcmpl-fcddc8bfaa763d9e537796ee","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":4,"completion_tokens":140,"total_tokens":368}}
46+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" directory"},"finish_reason":null}]}
47+
48+ data: {"id":"chatcmpl-01717753dc1a38b96633c031","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":4,"completion_tokens":330,"total_tokens":558}}
4749
4850 data: [DONE]
4951
@@ -52,15 +54,15 @@ interactions:
5254 - text/event-stream
5355 status: 200 OK
5456 code: 200
55− duration: 1.710549709s
57+ duration: 3.63693525s
5658- id: 1
5759 request:
5860 proto: HTTP/1.1
5961 proto_major: 1
6062 proto_minor: 1
61− content_length: 32429
63+ content_length: 32564
6264 host: ""
63− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files and use ls to list the current directory, it is very important that you run both tool calls in parallel\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
65+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files and use ls to list the current directory, it is very important that you run both tool calls in parallel\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6466 headers:
6567 Accept:
6668 - application/json
@@ -77,17 +79,33 @@ interactions:
7779 content_length: -1
7880 uncompressed: true
7981 body: |+
80− data: {"id":"chatcmpl-d326a05e3c78e3868f03af2e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
82+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980b75f95f1f182fe8da43d0ff72","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"pattern\": "}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"**"}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/*."}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"go"}}]},"finish_reason":null}]}
8197
82− data: {"id":"chatcmpl-d326a05e3c78e3868f03af2e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_b848","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
98+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
8399
84− data: {"id":"chatcmpl-d326a05e3c78e3868f03af2e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\", \"pattern\": \"**/*.go\"}"}}]},"finish_reason":null}]}
100+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
85101
86− data: {"id":"chatcmpl-d326a05e3c78e3868f03af2e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_2c82","type":"function","index":1,"function":{"name":"ls","arguments":""}}]},"finish_reason":null}]}
102+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980b76f0121c3e92480102f4e121","type":"function","index":1,"function":{"name":"ls","arguments":""}}]},"finish_reason":null}]}
87103
88− data: {"id":"chatcmpl-d326a05e3c78e3868f03af2e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":1,"function":{"arguments":"{\"path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\"}"}}]},"finish_reason":null}]}
104+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":1,"function":{"arguments":""}}]},"finish_reason":null}]}
89105
90− data: {"id":"chatcmpl-d326a05e3c78e3868f03af2e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":510,"completion_tokens":86,"total_tokens":7540}}
106+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":1,"function":{"arguments":"{}"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-3887882c35bbc57252ebdaa6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":566,"completion_tokens":15,"total_tokens":7493}}
91109
92110 data: [DONE]
93111
@@ -96,15 +114,15 @@ interactions:
96114 - text/event-stream
97115 status: 200 OK
98116 code: 200
99− duration: 2.973303292s
117+ duration: 5.319400458s
100118- id: 2
101119 request:
102120 proto: HTTP/1.1
103121 proto_major: 1
104122 proto_minor: 1
105− content_length: 33063
123+ content_length: 33144
106124 host: ""
107− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files and use ls to list the current directory, it is very important that you run both tool calls in parallel\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_b848\",\"function\":{\"arguments\":\"{\\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\\\", \\\"pattern\\\": \\\"**/*.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"},{\"id\":\"call_2c82\",\"function\":{\"arguments\":\"{\\\"path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\\\"}\",\"name\":\"ls\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls/main.go\",\"tool_call_id\":\"call_b848\",\"role\":\"tool\"},{\"content\":\"\\n- /tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls/\\n - go.mod\\n - main.go\\n\",\"tool_call_id\":\"call_2c82\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
125+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use glob to find all .go files and use ls to list the current directory, it is very important that you run both tool calls in parallel\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980b75f95f1f182fe8da43d0ff72\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"**/*.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"},{\"id\":\"019d980b76f0121c3e92480102f4e121\",\"function\":{\"arguments\":\"{}\",\"name\":\"ls\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls/main.go\",\"tool_call_id\":\"019d980b75f95f1f182fe8da43d0ff72\",\"role\":\"tool\"},{\"content\":\"\\n- /tmp/crush-test/TestCoderAgent/glm-5.1/parallel_tool_calls/\\n - go.mod\\n - main.go\\n\",\"tool_call_id\":\"019d980b76f0121c3e92480102f4e121\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
108126 headers:
109127 Accept:
110128 - application/json
@@ -121,23 +139,69 @@ interactions:
121139 content_length: -1
122140 uncompressed: true
123141 body: |+
124− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
142+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
143+
144+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"**"},"finish_reason":null}]}
145+
146+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"G"},"finish_reason":null}]}
147+
148+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"lob"},"finish_reason":null}]}
149+
150+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" results"},"finish_reason":null}]}
151+
152+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"**:"},"finish_reason":null}]}
153+
154+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" One"},"finish_reason":null}]}
155+
156+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `."},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
159+
160+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
161+
162+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" file"},"finish_reason":null}]}
163+
164+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" found"},"finish_reason":null}]}
165+
166+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" —"},"finish_reason":null}]}
167+
168+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
169+
170+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"main"},"finish_reason":null}]}
171+
172+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
173+
174+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`\n\n"},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"**"},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Directory"},"finish_reason":null}]}
179+
180+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" listing"},"finish_reason":null}]}
181+
182+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"**:"},"finish_reason":null}]}
183+
184+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Contains"},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
125189
126− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-"},"finish_reason":null}]}
190+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".mod"},"finish_reason":null}]}
127191
128− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" **Go"},"finish_reason":null}]}
192+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
129193
130− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" files**: `main"},"finish_reason":null}]}
194+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
131195
132− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go`\n- **"},"finish_reason":null}]}
196+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
133197
134− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Directory contents**: `"},"finish_reason":null}]}
198+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"main"},"finish_reason":null}]}
135199
136− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go.mod`,"},"finish_reason":null}]}
200+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
137201
138− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `main.go`"},"finish_reason":null}]}
202+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
139203
140− data: {"id":"chatcmpl-d7ece6a7fa6c1e25eceb43ff","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":146,"completion_tokens":23,"total_tokens":7593}}
204+ data: {"id":"chatcmpl-d0f1d3fb29166b835ab2ff69","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":126,"completion_tokens":31,"total_tokens":7581}}
141205
142206 data: [DONE]
143207
@@ -146,4 +210,4 @@ interactions:
146210 - text/event-stream
147211 status: 200 OK
148212 code: 200
149− duration: 902.887417ms
213+ duration: 1.958535834s
internal/agent/testdata/TestCoderAgent/glm-5.1/read_a_file.yaml+121−37
@@ -25,19 +25,19 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Reading"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Reading"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" go"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" go"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".mod"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".mod"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" file"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" file"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-cc5ffd146606da17b517f126","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":11,"completion_tokens":100,"total_tokens":303}}
40+ data: {"id":"chatcmpl-64e6912ac69feb86e3e0e006","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":11,"completion_tokens":82,"total_tokens":285}}
4141
4242 data: [DONE]
4343
@@ -46,15 +46,15 @@ interactions:
4646 - text/event-stream
4747 status: 200 OK
4848 code: 200
49− duration: 1.686770708s
49+ duration: 1.298010542s
5050- id: 1
5151 request:
5252 proto: HTTP/1.1
5353 proto_major: 1
5454 proto_minor: 1
55− content_length: 32302
55+ content_length: 32437
5656 host: ""
57− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Read the go mod\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
57+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Read the go mod\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
5858 headers:
5959 Accept:
6060 - application/json
@@ -71,17 +71,25 @@ interactions:
7171 content_length: -1
7272 uncompressed: true
7373 body: |+
74− data: {"id":"chatcmpl-f48bbf988d4b64b8326dfb81","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
74+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
7575
76− data: {"id":"chatcmpl-f48bbf988d4b64b8326dfb81","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_4936","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
76+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d9809c001f73e6bbbb7f92b940dec","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
7777
78− data: {"id":"chatcmpl-f48bbf988d4b64b8326dfb81","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"pattern\": \"go.mod\"}"}}]},"finish_reason":null}]}
78+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
7979
80− data: {"id":"chatcmpl-f48bbf988d4b64b8326dfb81","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_2ebd","type":"function","index":1,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
80+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
8181
82− data: {"id":"chatcmpl-f48bbf988d4b64b8326dfb81","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":1,"function":{"arguments":"{\"pattern\": \"**/go.mod\"}"}}]},"finish_reason":null}]}
82+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"pattern\": "}}]},"finish_reason":null}]}
8383
84− data: {"id":"chatcmpl-f48bbf988d4b64b8326dfb81","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":484,"completion_tokens":23,"total_tokens":7451}}
84+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"go"}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".mod"}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-0e5a0d50bff78783e1e5d80f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":540,"completion_tokens":16,"total_tokens":7468}}
8593
8694 data: [DONE]
8795
@@ -90,15 +98,15 @@ interactions:
9098 - text/event-stream
9199 status: 200 OK
92100 code: 200
93− duration: 2.807702625s
101+ duration: 3.87217775s
94102- id: 2
95103 request:
96104 proto: HTTP/1.1
97105 proto_major: 1
98106 proto_minor: 1
99− content_length: 32775
107+ content_length: 32736
100108 host: ""
101− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Read the go mod\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_4936\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"go.mod\\\"}\",\"name\":\"glob\"},\"type\":\"function\"},{\"id\":\"call_2ebd\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"**/go.mod\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\",\"tool_call_id\":\"call_4936\",\"role\":\"tool\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\",\"tool_call_id\":\"call_2ebd\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
109+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Read the go mod\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d9809c001f73e6bbbb7f92b940dec\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"go.mod\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\",\"tool_call_id\":\"019d9809c001f73e6bbbb7f92b940dec\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
102110 headers:
103111 Accept:
104112 - application/json
@@ -115,13 +123,57 @@ interactions:
115123 content_length: -1
116124 uncompressed: true
117125 body: |+
118− data: {"id":"chatcmpl-549543ea69682a2ddc74b512","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
126+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
127+
128+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d9809c999a7eb99bfe4d9144d9dc7","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
129+
130+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
131+
132+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
135+
136+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
137+
138+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
141+
142+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
143+
144+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
145+
146+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
147+
148+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
149+
150+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
151+
152+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
153+
154+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
155+
156+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
159+
160+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
119161
120− data: {"id":"chatcmpl-549543ea69682a2ddc74b512","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_c08c","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
162+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/read"}}]},"finish_reason":null}]}
121163
122− data: {"id":"chatcmpl-549543ea69682a2ddc74b512","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\"}"}}]},"finish_reason":null}]}
164+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_a"}}]},"finish_reason":null}]}
123165
124− data: {"id":"chatcmpl-549543ea69682a2ddc74b512","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":70,"completion_tokens":28,"total_tokens":7522}}
166+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_file"}}]},"finish_reason":null}]}
167+
168+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/go"}}]},"finish_reason":null}]}
169+
170+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".mod"}}]},"finish_reason":null}]}
171+
172+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
173+
174+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-9c6a3bf26ce0547f9906aa21","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":62,"completion_tokens":28,"total_tokens":7514}}
125177
126178 data: [DONE]
127179
@@ -130,15 +182,15 @@ interactions:
130182 - text/event-stream
131183 status: 200 OK
132184 code: 200
133− duration: 1.35846075s
185+ duration: 2.320719s
134186- id: 3
135187 request:
136188 proto: HTTP/1.1
137189 proto_major: 1
138190 proto_minor: 1
139− content_length: 33105
191+ content_length: 33112
140192 host: ""
141− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Read the go mod\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_4936\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"go.mod\\\"}\",\"name\":\"glob\"},\"type\":\"function\"},{\"id\":\"call_2ebd\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"**/go.mod\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\",\"tool_call_id\":\"call_4936\",\"role\":\"tool\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\",\"tool_call_id\":\"call_2ebd\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"call_c08c\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|module example.com/testproject\\n 2|\\n 3|go 1.23\\n</file>\\n\",\"tool_call_id\":\"call_c08c\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
193+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Read the go mod\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d9809c001f73e6bbbb7f92b940dec\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"go.mod\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\",\"tool_call_id\":\"019d9809c001f73e6bbbb7f92b940dec\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d9809c999a7eb99bfe4d9144d9dc7\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/read_a_file/go.mod\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|module example.com/testproject\\n 2|\\n 3|go 1.23\\n</file>\\n\",\"tool_call_id\":\"019d9809c999a7eb99bfe4d9144d9dc7\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
142194 headers:
143195 Accept:
144196 - application/json
@@ -155,25 +207,57 @@ interactions:
155207 content_length: -1
156208 uncompressed: true
157209 body: |+
158− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
210+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
211+
212+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}
213+
214+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
215+
216+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
217+
218+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".mod"},"finish_reason":null}]}
219+
220+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
221+
222+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" defines"},"finish_reason":null}]}
223+
224+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" module"},"finish_reason":null}]}
225+
226+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
227+
228+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"example"},"finish_reason":null}]}
229+
230+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".com"},"finish_reason":null}]}
231+
232+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/test"},"finish_reason":null}]}
233+
234+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"project"},"finish_reason":null}]}
235+
236+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
237+
238+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
239+
240+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
241+
242+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" version"},"finish_reason":null}]}
159243
160− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"The `"},"finish_reason":null}]}
244+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" "},"finish_reason":null}]}
161245
162− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go.mod` file"},"finish_reason":null}]}
246+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1"},"finish_reason":null}]}
163247
164− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" defines:\n\n"},"finish_reason":null}]}
248+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
165249
166− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"- **Module**:"},"finish_reason":null}]}
250+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"23"},"finish_reason":null}]}
167251
168− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `example.com/test"},"finish_reason":null}]}
252+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" and"},"finish_reason":null}]}
169253
170− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"project`\n- **"},"finish_reason":null}]}
254+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" no"},"finish_reason":null}]}
171255
172− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Go version**: "},"finish_reason":null}]}
256+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" dependencies"},"finish_reason":null}]}
173257
174− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1.23"},"finish_reason":null}]}
258+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
175259
176− data: {"id":"chatcmpl-39f5400094f5e3a67655c364","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":37,"completion_tokens":28,"total_tokens":7585}}
260+ data: {"id":"chatcmpl-8f6c9f8a3579f7fb5bfbf01e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":7549,"completion_tokens":25,"total_tokens":7574}}
177261
178262 data: [DONE]
179263
@@ -182,4 +266,4 @@ interactions:
182266 - text/event-stream
183267 status: 200 OK
184268 code: 200
185− duration: 855.52825ms
269+ duration: 2.111268084s
internal/agent/testdata/TestCoderAgent/glm-5.1/simple_test.yaml+25−13
@@ -25,13 +25,13 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-6143e3722cc6f50f4d47b83a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-5b7e249615a472bf74485690","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-6143e3722cc6f50f4d47b83a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Simple"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-5b7e249615a472bf74485690","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Simple"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-6143e3722cc6f50f4d47b83a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Greeting"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-5b7e249615a472bf74485690","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Greeting"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-6143e3722cc6f50f4d47b83a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":8,"completion_tokens":64,"total_tokens":264}}
34+ data: {"id":"chatcmpl-5b7e249615a472bf74485690","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":8,"completion_tokens":92,"total_tokens":292}}
3535
3636 data: [DONE]
3737
@@ -40,15 +40,15 @@ interactions:
4040 - text/event-stream
4141 status: 200 OK
4242 code: 200
43− duration: 1.322332s
43+ duration: 1.498550375s
4444- id: 1
4545 request:
4646 proto: HTTP/1.1
4747 proto_major: 1
4848 proto_minor: 1
49− content_length: 32292
49+ content_length: 32427
5050 host: ""
51− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/simple_test\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Hello\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
51+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/simple_test\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"Hello\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
5252 headers:
5353 Accept:
5454 - application/json
@@ -65,15 +65,27 @@ interactions:
6565 content_length: -1
6666 uncompressed: true
6767 body: |+
68− data: {"id":"chatcmpl-efc6375feb03b7975e820ef4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
68+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
6969
70− data: {"id":"chatcmpl-efc6375feb03b7975e820ef4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Hi!"},"finish_reason":null}]}
70+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Hello"},"finish_reason":null}]}
7171
72− data: {"id":"chatcmpl-efc6375feb03b7975e820ef4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" How can I help"},"finish_reason":null}]}
72+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"!"},"finish_reason":null}]}
7373
74− data: {"id":"chatcmpl-efc6375feb03b7975e820ef4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" you today?"},"finish_reason":null}]}
74+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" How"},"finish_reason":null}]}
7575
76− data: {"id":"chatcmpl-efc6375feb03b7975e820ef4","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":7392,"completion_tokens":10,"total_tokens":7434}}
76+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" can"},"finish_reason":null}]}
77+
78+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" I"},"finish_reason":null}]}
79+
80+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" help"},"finish_reason":null}]}
81+
82+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" you"},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" today"},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"?"},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-cf640df749cfff9bd883739f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":7448,"completion_tokens":10,"total_tokens":7458}}
7789
7890 data: [DONE]
7991
@@ -82,4 +94,4 @@ interactions:
8294 - text/event-stream
8395 status: 200 OK
8496 code: 200
85− duration: 2.420443625s
97+ duration: 3.441309042s
internal/agent/testdata/TestCoderAgent/glm-5.1/sourcegraph_tool.yaml+305−89
@@ -25,27 +25,29 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Source"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Search"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"graph"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" search"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" func"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" func"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" repos"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
44+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
4545
46− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" repos"},"finish_reason":null}]}
46+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Source"},"finish_reason":null}]}
4747
48− data: {"id":"chatcmpl-9f77f0bb8e650e9450be8066","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":4,"completion_tokens":294,"total_tokens":506}}
48+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"graph"},"finish_reason":null}]}
49+
50+ data: {"id":"chatcmpl-302ede2cd604cba8426a8de2","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":4,"completion_tokens":237,"total_tokens":449}}
4951
5052 data: [DONE]
5153
@@ -54,15 +56,15 @@ interactions:
5456 - text/event-stream
5557 status: 200 OK
5658 code: 200
57− duration: 3.212219375s
59+ duration: 2.742813917s
5860- id: 1
5961 request:
6062 proto: HTTP/1.1
6163 proto_major: 1
6264 proto_minor: 1
63− content_length: 32352
65+ content_length: 32487
6466 host: ""
65− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/sourcegraph_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use sourcegraph to search for 'func main' in Go repositories\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
67+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/sourcegraph_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use sourcegraph to search for 'func main' in Go repositories\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6668 headers:
6769 Accept:
6870 - application/json
@@ -79,13 +81,37 @@ interactions:
7981 content_length: -1
8082 uncompressed: true
8183 body: |+
82− data: {"id":"chatcmpl-fe1b84757b6150a474e3603d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
84+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980b28195984bea5a21106c0c3ab","type":"function","index":0,"function":{"name":"sourcegraph","arguments":""}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"count\": "}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"20"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
8397
84− data: {"id":"chatcmpl-fe1b84757b6150a474e3603d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_3ec9","type":"function","index":0,"function":{"name":"sourcegraph","arguments":""}}]},"finish_reason":null}]}
98+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"query\": "}}]},"finish_reason":null}]}
8599
86− data: {"id":"chatcmpl-fe1b84757b6150a474e3603d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"count\": 20, \"query\": \"func main lang:go\"}"}}]},"finish_reason":null}]}
100+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"func"}}]},"finish_reason":null}]}
87101
88− data: {"id":"chatcmpl-fe1b84757b6150a474e3603d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":493,"completion_tokens":41,"total_tokens":7478}}
102+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" main"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" lang"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":":"}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"go"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-381943adb601e6d2c7f72605","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":549,"completion_tokens":41,"total_tokens":7502}}
89115
90116 data: [DONE]
91117
@@ -94,7 +120,7 @@ interactions:
94120 - text/event-stream
95121 status: 200 OK
96122 code: 200
97− duration: 5.244913875s
123+ duration: 5.056481583s
98124- id: 2
99125 request:
100126 proto: HTTP/1.1
@@ -122,15 +148,15 @@ interactions:
122148 - application/json
123149 status: 200 OK
124150 code: 200
125− duration: 1.392458459s
151+ duration: 1.402643583s
126152- id: 3
127153 request:
128154 proto: HTTP/1.1
129155 proto_major: 1
130156 proto_minor: 1
131− content_length: 43214
157+ content_length: 43395
132158 host: ""
133− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/sourcegraph_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use sourcegraph to search for 'func main' in Go repositories\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_3ec9\",\"function\":{\"arguments\":\"{\\\"count\\\": 20, \\\"query\\\": \\\"func main lang:go\\\"}\",\"name\":\"sourcegraph\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"# Sourcegraph Search Results\\n\\nFound 30 matches across 30 results\\n(Result limit reached, try a more specific query)\\n\\n## Result 1: github.com/jmbharathram/executeoncommand/go/channel/main.go\\n\\nURL: /r/github.com/jmbharathram/executeoncommand/-/blob/go/channel/main.go\\n\\n```\\n96| \\n97| func routine2(ch chan int, min int, max int) {\\n98| \\n99| rand.Seed(time.Now().UnixNano())\\n100| t := rand.Intn(max - min) + min\\n101| fmt.Println(\\\"routine 2 is waiting: \\\", t, \\\"secs\\\")\\n102| time.Sleep(time.Duration(t)*time.Second)\\n103| \\n104| ch <- t\\n105| }\\n106| func main(){\\n107| func main(){\\n108| \\n109| min := 1\\n110| max := 10\\n111| \\n112| ch1:= make(chan int)\\n113| ch2:= make(chan int)\\n114| \\n115| go routine1(ch1, min, max)\\n116| go routine2(ch2, min, max)\\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| func dummy_func() {\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| \\tfmt.Println(\\\"dummy_func\\\")\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| func main() {\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| \\tgo dummy_func()\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| fmt.Println(\\\"end of main\\\")\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| \\n```\\n\\n```\\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| \\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| func main() {\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| // trigger a parallel go routine\\n30| \\tgo dummy_func(ch)\\n31| // send a value into the channel\\n32| \\tch <- 10\\n33| }\\n34| \\n35| // Example 2\\n```\\n\\n```\\n41| //\\\"flag\\\"\\n42| )\\n43| \\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n47| \\tfmt.Println(val)\\n48| \\n49| //send a value again\\n50| ch <- val*2\\n51| func main() {\\n52| func main() {\\n53| fmt.Println(\\\"Welcome to main function\\\")\\n54| \\n55| //flag statements for user input\\n56| var input_value int\\n57| input_value = 10\\n58| //flag.IntVar(&input_value, \\\"v\\\", 10, \\\"Input value to send/receive via channel.\\\" )\\n59| //flag.Parse()\\n60| \\n61| // create a channel\\n```\\n\\n```\\n42| )\\n43| \\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n47| \\tfmt.Println(val)\\n48| \\n49| //send a value again\\n50| ch <- val*2\\n51| }\\n52| fmt.Println(\\\"Welcome to main function\\\")\\n53| fmt.Println(\\\"Welcome to main function\\\")\\n54| \\n55| //flag statements for user input\\n56| var input_value int\\n57| input_value = 10\\n58| //flag.IntVar(&input_value, \\\"v\\\", 10, \\\"Input value to send/receive via channel.\\\" )\\n59| //flag.Parse()\\n60| \\n61| // create a channel\\n62| \\tch := make(chan int)\\n```\\n\\n```\\n116| go routine2(ch2, min, max)\\n117| \\n118| select{\\n119| \\n120| case <- ch1:\\n121| fmt.Println(\\\"routine 1 finished\\\")\\n122| \\n123| case <- ch2:\\n124| fmt.Println(\\\"routine 2 finished\\\")\\n125| }\\n126| fmt.Println(\\\"end of main function\\\")\\n127| fmt.Println(\\\"end of main function\\\")\\n128| \\n129| }\\n130| \\n```\\n\\n```\\n68| \\tch <- input_value\\n69| \\n70| // receive a value from channel\\n71| response := <- ch\\n72| fmt.Println(response)\\n73| \\n74| }\\n75| \\n76| // example 3\\n77| \\n78| package main\\n79| package main\\n80| \\n81| import(\\n82| \\\"fmt\\\"\\n83| \\\"time\\\"\\n84| \\\"math/rand\\\"\\n85| )\\n86| \\n87| func routine1(ch chan int, min int, max int) {\\n88| \\n```\\n\\n```\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| package main\\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| \\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| }\\n26| func main() {\\n```\\n\\n```\\n0| package main\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n```\\n\\n```\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| // trigger a parallel go routine\\n30| \\tgo dummy_func(ch)\\n31| // send a value into the channel\\n32| \\tch <- 10\\n33| }\\n34| \\n35| // Example 2\\n36| package main\\n37| package main\\n38| \\n39| import (\\n40| \\\"fmt\\\"\\n41| //\\\"flag\\\"\\n42| )\\n43| \\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n```\\n\\n```\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| func dummy_func(ch chan int) {\\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| }\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| // trigger a parallel go routine\\n30| \\tgo dummy_func(ch)\\n```\\n\\n```\\n33| }\\n34| \\n35| // Example 2\\n36| \\n37| package main\\n38| \\n39| import (\\n40| \\\"fmt\\\"\\n41| //\\\"flag\\\"\\n42| )\\n43| func dummy_func(ch chan int) {\\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n47| \\tfmt.Println(val)\\n48| \\n49| //send a value again\\n50| ch <- val*2\\n51| }\\n52| func main() {\\n53| fmt.Println(\\\"Welcome to main function\\\")\\n```\\n\\n```\\n54| \\n55| //flag statements for user input\\n56| var input_value int\\n57| input_value = 10\\n58| //flag.IntVar(&input_value, \\\"v\\\", 10, \\\"Input value to send/receive via channel.\\\" )\\n59| //flag.Parse()\\n60| \\n61| // create a channel\\n62| \\tch := make(chan int)\\n63| \\n64| \\tgo dummy_func(ch)\\n65| \\tgo dummy_func(ch)\\n66| \\n67| // send a value into the channel\\n68| \\tch <- input_value\\n69| \\n70| // receive a value from channel\\n71| response := <- ch\\n72| fmt.Println(response)\\n73| \\n74| }\\n```\\n\\n```\\n19| import \\\"fmt\\\"\\n20| \\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| }\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| \\tgo dummy_func(ch)\\n30| \\tgo dummy_func(ch)\\n31| // send a value into the channel\\n32| \\tch <- 10\\n33| }\\n34| \\n35| // Example 2\\n36| \\n37| package main\\n38| \\n39| import (\\n```\\n\\n```\\n76| // example 3\\n77| \\n78| \\n79| package main\\n80| \\n81| import(\\n82| \\\"fmt\\\"\\n83| \\\"time\\\"\\n84| \\\"math/rand\\\"\\n85| )\\n86| func routine1(ch chan int, min int, max int) {\\n87| func routine1(ch chan int, min int, max int) {\\n88| \\n89| rand.Seed(time.Now().UnixNano())\\n90| t := rand.Intn(max - min) + min\\n91| fmt.Println(\\\"routine 1 is waiting: \\\", t, \\\"secs\\\")\\n92| time.Sleep(time.Duration(t)*time.Second)\\n93| \\n94| ch <- t\\n95| }\\n96| \\n```\\n\\n```\\n86| \\n87| func routine1(ch chan int, min int, max int) {\\n88| \\n89| rand.Seed(time.Now().UnixNano())\\n90| t := rand.Intn(max - min) + min\\n91| fmt.Println(\\\"routine 1 is waiting: \\\", t, \\\"secs\\\")\\n92| time.Sleep(time.Duration(t)*time.Second)\\n93| \\n94| ch <- t\\n95| }\\n96| func routine2(ch chan int, min int, max int) {\\n97| func routine2(ch chan int, min int, max int) {\\n98| \\n99| rand.Seed(time.Now().UnixNano())\\n100| t := rand.Intn(max - min) + min\\n101| fmt.Println(\\\"routine 2 is waiting: \\\", t, \\\"secs\\\")\\n102| time.Sleep(time.Duration(t)*time.Second)\\n103| \\n104| ch <- t\\n105| }\\n106| \\n```\\n\\n## Result 2: github.com/vitorbritto/dexter-momentum/go/concepts/10-functions/stack-function/main.go\\n\\nURL: /r/github.com/vitorbritto/dexter-momentum/-/blob/go/concepts/10-functions/stack-function/main.go\\n\\n```\\n6| \\tdebug.PrintStack()\\n7| }\\n8| \\n9| func f2() {\\n10| \\tf3()\\n11| }\\n12| \\n13| func f1() {\\n14| \\tf2()\\n15| }\\n16| func main() {\\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // goroutine 1 [running]:\\n23| // main.f3()\\n24| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n```\\n\\n```\\n12| \\n13| func f1() {\\n14| \\tf2()\\n15| }\\n16| \\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // main.f3()\\n23| // main.f3()\\n24| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n27| // main.f1()\\n28| // \\t/Users/jason/go/src/stack-function/main.go:11 +0x11\\n29| // main.main()\\n30| // \\t/Users/jason/go/src/stack-function/main.go:15 +0x11\\n31| \\n```\\n\\n```\\n13| func f1() {\\n14| \\tf2()\\n15| }\\n16| \\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // goroutine 1 [running]:\\n23| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n24| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n27| // main.f1()\\n28| // \\t/Users/jason/go/src/stack-function/main.go:11 +0x11\\n29| // main.main()\\n30| // \\t/Users/jason/go/src/stack-function/main.go:15 +0x11\\n31| \\n```\\n\\n```\\n14| \\tf2()\\n15| }\\n16| \\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // goroutine 1 [running]:\\n23| // main.f3()\\n24| // main.f2()\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n27| // main.f1()\\n28| // \\t/Users/jason/go/src/stack-function/main.go:11 +0x11\\n29| // main.main()\\n30| // \\t/Users/jason/go/src/stack-function/main.go:15 +0x11\\n31| \\n```\\n\\n\",\"tool_call_id\":\"call_3ec9\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
159+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/sourcegraph_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use sourcegraph to search for 'func main' in Go repositories\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980b28195984bea5a21106c0c3ab\",\"function\":{\"arguments\":\"{\\\"count\\\": 20, \\\"query\\\": \\\"func main lang:go\\\"}\",\"name\":\"sourcegraph\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"# Sourcegraph Search Results\\n\\nFound 30 matches across 30 results\\n(Result limit reached, try a more specific query)\\n\\n## Result 1: github.com/jmbharathram/executeoncommand/go/channel/main.go\\n\\nURL: /r/github.com/jmbharathram/executeoncommand/-/blob/go/channel/main.go\\n\\n```\\n96| \\n97| func routine2(ch chan int, min int, max int) {\\n98| \\n99| rand.Seed(time.Now().UnixNano())\\n100| t := rand.Intn(max - min) + min\\n101| fmt.Println(\\\"routine 2 is waiting: \\\", t, \\\"secs\\\")\\n102| time.Sleep(time.Duration(t)*time.Second)\\n103| \\n104| ch <- t\\n105| }\\n106| func main(){\\n107| func main(){\\n108| \\n109| min := 1\\n110| max := 10\\n111| \\n112| ch1:= make(chan int)\\n113| ch2:= make(chan int)\\n114| \\n115| go routine1(ch1, min, max)\\n116| go routine2(ch2, min, max)\\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| func dummy_func() {\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| \\tfmt.Println(\\\"dummy_func\\\")\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| func main() {\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| \\tgo dummy_func()\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n```\\n\\n```\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| fmt.Println(\\\"end of main\\\")\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| \\n```\\n\\n```\\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| \\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| func main() {\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| // trigger a parallel go routine\\n30| \\tgo dummy_func(ch)\\n31| // send a value into the channel\\n32| \\tch <- 10\\n33| }\\n34| \\n35| // Example 2\\n```\\n\\n```\\n41| //\\\"flag\\\"\\n42| )\\n43| \\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n47| \\tfmt.Println(val)\\n48| \\n49| //send a value again\\n50| ch <- val*2\\n51| func main() {\\n52| func main() {\\n53| fmt.Println(\\\"Welcome to main function\\\")\\n54| \\n55| //flag statements for user input\\n56| var input_value int\\n57| input_value = 10\\n58| //flag.IntVar(&input_value, \\\"v\\\", 10, \\\"Input value to send/receive via channel.\\\" )\\n59| //flag.Parse()\\n60| \\n61| // create a channel\\n```\\n\\n```\\n42| )\\n43| \\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n47| \\tfmt.Println(val)\\n48| \\n49| //send a value again\\n50| ch <- val*2\\n51| }\\n52| fmt.Println(\\\"Welcome to main function\\\")\\n53| fmt.Println(\\\"Welcome to main function\\\")\\n54| \\n55| //flag statements for user input\\n56| var input_value int\\n57| input_value = 10\\n58| //flag.IntVar(&input_value, \\\"v\\\", 10, \\\"Input value to send/receive via channel.\\\" )\\n59| //flag.Parse()\\n60| \\n61| // create a channel\\n62| \\tch := make(chan int)\\n```\\n\\n```\\n116| go routine2(ch2, min, max)\\n117| \\n118| select{\\n119| \\n120| case <- ch1:\\n121| fmt.Println(\\\"routine 1 finished\\\")\\n122| \\n123| case <- ch2:\\n124| fmt.Println(\\\"routine 2 finished\\\")\\n125| }\\n126| fmt.Println(\\\"end of main function\\\")\\n127| fmt.Println(\\\"end of main function\\\")\\n128| \\n129| }\\n130| \\n```\\n\\n```\\n68| \\tch <- input_value\\n69| \\n70| // receive a value from channel\\n71| response := <- ch\\n72| fmt.Println(response)\\n73| \\n74| }\\n75| \\n76| // example 3\\n77| \\n78| package main\\n79| package main\\n80| \\n81| import(\\n82| \\\"fmt\\\"\\n83| \\\"time\\\"\\n84| \\\"math/rand\\\"\\n85| )\\n86| \\n87| func routine1(ch chan int, min int, max int) {\\n88| \\n```\\n\\n```\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| package main\\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| \\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| }\\n26| func main() {\\n```\\n\\n```\\n0| package main\\n1| package main\\n2| \\n3| import \\\"fmt\\\"\\n4| \\n5| // Example 0\\n6| func dummy_func() {\\n7| \\tfmt.Println(\\\"dummy_func\\\")\\n8| }\\n9| func main() {\\n10| \\tgo dummy_func()\\n```\\n\\n```\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| // trigger a parallel go routine\\n30| \\tgo dummy_func(ch)\\n31| // send a value into the channel\\n32| \\tch <- 10\\n33| }\\n34| \\n35| // Example 2\\n36| package main\\n37| package main\\n38| \\n39| import (\\n40| \\\"fmt\\\"\\n41| //\\\"flag\\\"\\n42| )\\n43| \\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n```\\n\\n```\\n10| \\tgo dummy_func()\\n11| fmt.Println(\\\"end of main\\\")\\n12| }\\n13| \\n14| \\n15| // Example 1\\n16| \\n17| package main\\n18| \\n19| import \\\"fmt\\\"\\n20| func dummy_func(ch chan int) {\\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| }\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| // trigger a parallel go routine\\n30| \\tgo dummy_func(ch)\\n```\\n\\n```\\n33| }\\n34| \\n35| // Example 2\\n36| \\n37| package main\\n38| \\n39| import (\\n40| \\\"fmt\\\"\\n41| //\\\"flag\\\"\\n42| )\\n43| func dummy_func(ch chan int) {\\n44| func dummy_func(ch chan int) {\\n45| // receive a value from channel\\n46| val := <-ch\\n47| \\tfmt.Println(val)\\n48| \\n49| //send a value again\\n50| ch <- val*2\\n51| }\\n52| func main() {\\n53| fmt.Println(\\\"Welcome to main function\\\")\\n```\\n\\n```\\n54| \\n55| //flag statements for user input\\n56| var input_value int\\n57| input_value = 10\\n58| //flag.IntVar(&input_value, \\\"v\\\", 10, \\\"Input value to send/receive via channel.\\\" )\\n59| //flag.Parse()\\n60| \\n61| // create a channel\\n62| \\tch := make(chan int)\\n63| \\n64| \\tgo dummy_func(ch)\\n65| \\tgo dummy_func(ch)\\n66| \\n67| // send a value into the channel\\n68| \\tch <- input_value\\n69| \\n70| // receive a value from channel\\n71| response := <- ch\\n72| fmt.Println(response)\\n73| \\n74| }\\n```\\n\\n```\\n19| import \\\"fmt\\\"\\n20| \\n21| func dummy_func(ch chan int) {\\n22| // receive a value from channel\\n23| val := <-ch\\n24| \\tfmt.Println(val)\\n25| }\\n26| func main() {\\n27| // create a channel\\n28| \\tch := make(chan int)\\n29| \\tgo dummy_func(ch)\\n30| \\tgo dummy_func(ch)\\n31| // send a value into the channel\\n32| \\tch <- 10\\n33| }\\n34| \\n35| // Example 2\\n36| \\n37| package main\\n38| \\n39| import (\\n```\\n\\n```\\n76| // example 3\\n77| \\n78| \\n79| package main\\n80| \\n81| import(\\n82| \\\"fmt\\\"\\n83| \\\"time\\\"\\n84| \\\"math/rand\\\"\\n85| )\\n86| func routine1(ch chan int, min int, max int) {\\n87| func routine1(ch chan int, min int, max int) {\\n88| \\n89| rand.Seed(time.Now().UnixNano())\\n90| t := rand.Intn(max - min) + min\\n91| fmt.Println(\\\"routine 1 is waiting: \\\", t, \\\"secs\\\")\\n92| time.Sleep(time.Duration(t)*time.Second)\\n93| \\n94| ch <- t\\n95| }\\n96| \\n```\\n\\n```\\n86| \\n87| func routine1(ch chan int, min int, max int) {\\n88| \\n89| rand.Seed(time.Now().UnixNano())\\n90| t := rand.Intn(max - min) + min\\n91| fmt.Println(\\\"routine 1 is waiting: \\\", t, \\\"secs\\\")\\n92| time.Sleep(time.Duration(t)*time.Second)\\n93| \\n94| ch <- t\\n95| }\\n96| func routine2(ch chan int, min int, max int) {\\n97| func routine2(ch chan int, min int, max int) {\\n98| \\n99| rand.Seed(time.Now().UnixNano())\\n100| t := rand.Intn(max - min) + min\\n101| fmt.Println(\\\"routine 2 is waiting: \\\", t, \\\"secs\\\")\\n102| time.Sleep(time.Duration(t)*time.Second)\\n103| \\n104| ch <- t\\n105| }\\n106| \\n```\\n\\n## Result 2: github.com/vitorbritto/dexter-momentum/go/concepts/10-functions/stack-function/main.go\\n\\nURL: /r/github.com/vitorbritto/dexter-momentum/-/blob/go/concepts/10-functions/stack-function/main.go\\n\\n```\\n6| \\tdebug.PrintStack()\\n7| }\\n8| \\n9| func f2() {\\n10| \\tf3()\\n11| }\\n12| \\n13| func f1() {\\n14| \\tf2()\\n15| }\\n16| func main() {\\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // goroutine 1 [running]:\\n23| // main.f3()\\n24| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n```\\n\\n```\\n12| \\n13| func f1() {\\n14| \\tf2()\\n15| }\\n16| \\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // main.f3()\\n23| // main.f3()\\n24| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n27| // main.f1()\\n28| // \\t/Users/jason/go/src/stack-function/main.go:11 +0x11\\n29| // main.main()\\n30| // \\t/Users/jason/go/src/stack-function/main.go:15 +0x11\\n31| \\n```\\n\\n```\\n13| func f1() {\\n14| \\tf2()\\n15| }\\n16| \\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // goroutine 1 [running]:\\n23| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n24| // \\t/Users/jason/go/src/stack-function/main.go:3 +0x11\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n27| // main.f1()\\n28| // \\t/Users/jason/go/src/stack-function/main.go:11 +0x11\\n29| // main.main()\\n30| // \\t/Users/jason/go/src/stack-function/main.go:15 +0x11\\n31| \\n```\\n\\n```\\n14| \\tf2()\\n15| }\\n16| \\n17| func main() {\\n18| \\tf1()\\n19| }\\n20| \\n21| // Output:\\n22| // goroutine 1 [running]:\\n23| // main.f3()\\n24| // main.f2()\\n25| // main.f2()\\n26| // \\t/Users/jason/go/src/stack-function/main.go:7 +0x11\\n27| // main.f1()\\n28| // \\t/Users/jason/go/src/stack-function/main.go:11 +0x11\\n29| // main.main()\\n30| // \\t/Users/jason/go/src/stack-function/main.go:15 +0x11\\n31| \\n```\\n\\n\",\"tool_call_id\":\"019d980b28195984bea5a21106c0c3ab\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
134160 headers:
135161 Accept:
136162 - application/json
@@ -147,137 +173,327 @@ interactions:
147173 content_length: -1
148174 uncompressed: true
149175 body: |+
150− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
176+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Found"},"finish_reason":null}]}
179+
180+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" **"},"finish_reason":null}]}
181+
182+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"30"},"finish_reason":null}]}
183+
184+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" matches"},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"**"},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" across"},"finish_reason":null}]}
189+
190+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" "},"finish_reason":null}]}
191+
192+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"30"},"finish_reason":null}]}
193+
194+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" repositories"},"finish_reason":null}]}
195+
196+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" for"},"finish_reason":null}]}
197+
198+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
199+
200+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"func"},"finish_reason":null}]}
201+
202+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
203+
204+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
205+
206+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" in"},"finish_reason":null}]}
207+
208+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
209+
210+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
211+
212+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Key"},"finish_reason":null}]}
213+
214+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" examples"},"finish_reason":null}]}
215+
216+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":\n\n"},"finish_reason":null}]}
217+
218+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|"},"finish_reason":null}]}
219+
220+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Repository"},"finish_reason":null}]}
221+
222+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |"},"finish_reason":null}]}
223+
224+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" File"},"finish_reason":null}]}
225+
226+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |"},"finish_reason":null}]}
227+
228+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Description"},"finish_reason":null}]}
229+
230+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |\n"},"finish_reason":null}]}
231+
232+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|"},"finish_reason":null}]}
233+
234+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"---"},"finish_reason":null}]}
235+
236+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|"},"finish_reason":null}]}
237+
238+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"---"},"finish_reason":null}]}
239+
240+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|"},"finish_reason":null}]}
241+
242+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"---"},"finish_reason":null}]}
243+
244+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|\n"},"finish_reason":null}]}
245+
246+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|"},"finish_reason":null}]}
247+
248+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
249+
250+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"j"},"finish_reason":null}]}
251+
252+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"mb"},"finish_reason":null}]}
253+
254+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"har"},"finish_reason":null}]}
255+
256+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"ath"},"finish_reason":null}]}
257+
258+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"ram"},"finish_reason":null}]}
259+
260+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/"},"finish_reason":null}]}
261+
262+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"execute"},"finish_reason":null}]}
263+
264+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"on"},"finish_reason":null}]}
265+
266+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"command"},"finish_reason":null}]}
267+
268+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
269+
270+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |"},"finish_reason":null}]}
271+
272+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
273+
274+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
275+
276+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/channel"},"finish_reason":null}]}
277+
278+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/main"},"finish_reason":null}]}
279+
280+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
281+
282+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
283+
284+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |"},"finish_reason":null}]}
285+
286+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Channel"},"finish_reason":null}]}
287+
288+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/g"},"finish_reason":null}]}
289+
290+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"or"},"finish_reason":null}]}
291+
292+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"outine"},"finish_reason":null}]}
293+
294+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" examples"},"finish_reason":null}]}
295+
296+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
297+
298+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" select"},"finish_reason":null}]}
299+
300+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |\n"},"finish_reason":null}]}
301+
302+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|"},"finish_reason":null}]}
303+
304+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
305+
306+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"v"},"finish_reason":null}]}
307+
308+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"itor"},"finish_reason":null}]}
309+
310+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"brit"},"finish_reason":null}]}
311+
312+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"to"},"finish_reason":null}]}
313+
314+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/d"},"finish_reason":null}]}
315+
316+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"exter"},"finish_reason":null}]}
317+
318+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-m"},"finish_reason":null}]}
319+
320+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"omentum"},"finish_reason":null}]}
321+
322+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
323+
324+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |"},"finish_reason":null}]}
325+
326+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
327+
328+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
329+
330+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/con"},"finish_reason":null}]}
331+
332+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"cepts"},"finish_reason":null}]}
333+
334+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/"},"finish_reason":null}]}
335+
336+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"10"},"finish_reason":null}]}
337+
338+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-functions"},"finish_reason":null}]}
339+
340+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/"},"finish_reason":null}]}
341+
342+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"stack"},"finish_reason":null}]}
343+
344+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-function"},"finish_reason":null}]}
345+
346+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/main"},"finish_reason":null}]}
347+
348+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
349+
350+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
351+
352+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |"},"finish_reason":null}]}
353+
354+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Stack"},"finish_reason":null}]}
355+
356+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" trace"},"finish_reason":null}]}
357+
358+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" demo"},"finish_reason":null}]}
359+
360+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
361+
362+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
363+
364+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"debug"},"finish_reason":null}]}
365+
366+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".Print"},"finish_reason":null}]}
151367
152− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Here"},"finish_reason":null}]}
368+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Stack"},"finish_reason":null}]}
153369
154− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" are the"},"finish_reason":null}]}
370+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"()`"},"finish_reason":null}]}
155371
156− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" top"},"finish_reason":null}]}
372+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |\n\n"},"finish_reason":null}]}
157373
158− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" results for"},"finish_reason":null}]}
374+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"The"},"finish_reason":null}]}
159375
160− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `func main`"},"finish_reason":null}]}
376+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" results"},"finish_reason":null}]}
161377
162− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" in Go repositories:\n\n"},"finish_reason":null}]}
378+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" are"},"finish_reason":null}]}
163379
164− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"| #"},"finish_reason":null}]}
380+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" heavily"},"finish_reason":null}]}
165381
166− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" | Repository | File"},"finish_reason":null}]}
382+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" dominated"},"finish_reason":null}]}
167383
168− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" | Line"},"finish_reason":null}]}
384+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" by"},"finish_reason":null}]}
169385
170− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" |\n|---|"},"finish_reason":null}]}
386+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" a"},"finish_reason":null}]}
171387
172− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"-----------|------"},"finish_reason":null}]}
388+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" couple"},"finish_reason":null}]}
173389
174− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|------"},"finish_reason":null}]}
390+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" of"},"finish_reason":null}]}
175391
176− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"|\n| "},"finish_reason":null}]}
392+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" repos"},"finish_reason":null}]}
177393
178− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"1 | `j"},"finish_reason":null}]}
394+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
179395
180− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"mbharathram"},"finish_reason":null}]}
396+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" many"},"finish_reason":null}]}
181397
182− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/executeoncommand"},"finish_reason":null}]}
398+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" duplicate"},"finish_reason":null}]}
183399
184− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"` | `go"},"finish_reason":null}]}
400+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" matches"},"finish_reason":null}]}
185401
186− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/channel/main.go`"},"finish_reason":null}]}
402+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
187403
188− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" | L"},"finish_reason":null}]}
404+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" For"},"finish_reason":null}]}
189405
190− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"9"},"finish_reason":null}]}
406+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" more"},"finish_reason":null}]}
191407
192− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":", L26"},"finish_reason":null}]}
408+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" diverse"},"finish_reason":null}]}
193409
194− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":", L52"},"finish_reason":null}]}
410+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/"},"finish_reason":null}]}
195411
196− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":", L106 |\n"},"finish_reason":null}]}
412+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"prec"},"finish_reason":null}]}
197413
198− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"| "},"finish_reason":null}]}
414+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"ise"},"finish_reason":null}]}
199415
200− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"2 | `v"},"finish_reason":null}]}
416+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" results"},"finish_reason":null}]}
201417
202− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"itorbritto/d"},"finish_reason":null}]}
418+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":","},"finish_reason":null}]}
203419
204− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"exter-momentum`"},"finish_reason":null}]}
420+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" you"},"finish_reason":null}]}
205421
206− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" | `go/con"},"finish_reason":null}]}
422+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" could"},"finish_reason":null}]}
207423
208− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"cepts/10-functions"},"finish_reason":null}]}
424+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" narrow"},"finish_reason":null}]}
209425
210− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/stack-function/main"},"finish_reason":null}]}
426+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
211427
212− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go` | L"},"finish_reason":null}]}
428+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" e"},"finish_reason":null}]}
213429
214− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"17 |\n\nThe search"},"finish_reason":null}]}
430+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".g"},"finish_reason":null}]}
215431
216− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" returned **30 matches"},"finish_reason":null}]}
432+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
217433
218− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"** across multiple"},"finish_reason":null}]}
434+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
219435
220− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Go"},"finish_reason":null}]}
436+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"func"},"finish_reason":null}]}
221437
222− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" repos"},"finish_reason":null}]}
438+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
223439
224− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":". The results are"},"finish_reason":null}]}
440+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"()"},"finish_reason":null}]}
225441
226− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" heavily"},"finish_reason":null}]}
442+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" lang"},"finish_reason":null}]}
227443
228− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" weighted"},"finish_reason":null}]}
444+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
229445
230− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" toward educational"},"finish_reason":null}]}
446+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
231447
232− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"/example"},"finish_reason":null}]}
448+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" -"},"finish_reason":null}]}
233449
234− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" code."},"finish_reason":null}]}
450+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"repo"},"finish_reason":null}]}
235451
236− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" To narrow"},"finish_reason":null}]}
452+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
237453
238− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" down,"},"finish_reason":null}]}
454+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"execute"},"finish_reason":null}]}
239455
240− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" you could refine"},"finish_reason":null}]}
456+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"on"},"finish_reason":null}]}
241457
242− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the query,"},"finish_reason":null}]}
458+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"command"},"finish_reason":null}]}
243459
244− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" e.g."},"finish_reason":null}]}
460+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
245461
246− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":\n\n- `func"},"finish_reason":null}]}
462+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" or"},"finish_reason":null}]}
247463
248− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main() lang:"},"finish_reason":null}]}
464+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" add"},"finish_reason":null}]}
249465
250− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go` —"},"finish_reason":null}]}
466+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" context"},"finish_reason":null}]}
251467
252− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" exact signature"},"finish_reason":null}]}
468+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" like"},"finish_reason":null}]}
253469
254− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" match"},"finish_reason":null}]}
470+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
255471
256− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"\n- `func"},"finish_reason":null}]}
472+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"func"},"finish_reason":null}]}
257473
258− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main repo"},"finish_reason":null}]}
474+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
259475
260− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":github.com/g"},"finish_reason":null}]}
476+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"()"},"finish_reason":null}]}
261477
262− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"olang/go` —"},"finish_reason":null}]}
478+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" {"},"finish_reason":null}]}
263479
264− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" specific repo"},"finish_reason":null}]}
480+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" lang"},"finish_reason":null}]}
265481
266− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"\n- `func"},"finish_reason":null}]}
482+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
267483
268− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" main -"},"finish_reason":null}]}
484+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"go"},"finish_reason":null}]}
269485
270− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"file"},"finish_reason":null}]}
486+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" count"},"finish_reason":null}]}
271487
272− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":example"},"finish_reason":null}]}
488+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
273489
274− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" lang:go`"},"finish_reason":null}]}
490+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"100"},"finish_reason":null}]}
275491
276− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" — exclude example"},"finish_reason":null}]}
492+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"0"},"finish_reason":null}]}
277493
278− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" files"},"finish_reason":null}]}
494+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`."},"finish_reason":null}]}
279495
280− data: {"id":"chatcmpl-785eade97384902d3c1422e1","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3483,"completion_tokens":182,"total_tokens":11089}}
496+ data: {"id":"chatcmpl-671647db809add5f3c9e84be","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3507,"completion_tokens":160,"total_tokens":11091}}
281497
282498 data: [DONE]
283499
@@ -286,4 +502,4 @@ interactions:
286502 - text/event-stream
287503 status: 200 OK
288504 code: 200
289− duration: 991.464709ms
505+ duration: 1.911468375s
internal/agent/testdata/TestCoderAgent/glm-5.1/update_a_file.yaml+243−35
@@ -25,25 +25,27 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Update"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Update"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" main"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" print"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" print"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Hello"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" say"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" from"},"finish_reason":null}]}
42+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" hello"},"finish_reason":null}]}
4343
44− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" Crush"},"finish_reason":null}]}
44+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" from"},"finish_reason":null}]}
4545
46− data: {"id":"chatcmpl-761cf32b1e33f5e1d57b506c","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":5,"completion_tokens":99,"total_tokens":312}}
46+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" crush"},"finish_reason":null}]}
47+
48+ data: {"id":"chatcmpl-119f3bd1ab434e07234a80a5","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":5,"completion_tokens":83,"total_tokens":296}}
4749
4850 data: [DONE]
4951
@@ -52,15 +54,15 @@ interactions:
5254 - text/event-stream
5355 status: 200 OK
5456 code: 200
55− duration: 1.671100625s
57+ duration: 1.174858458s
5658- id: 1
5759 request:
5860 proto: HTTP/1.1
5961 proto_major: 1
6062 proto_minor: 1
61− content_length: 32358
63+ content_length: 32493
6264 host: ""
63− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
65+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6466 headers:
6567 Accept:
6668 - application/json
@@ -77,13 +79,29 @@ interactions:
7779 content_length: -1
7880 uncompressed: true
7981 body: |+
80− data: {"id":"chatcmpl-9f99041fa9c5009f6627a15d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
82+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d9809e1976446b04ce76ef66a82f7","type":"function","index":0,"function":{"name":"glob","arguments":""}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"pattern\": "}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"**"}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/"}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"main"}}]},"finish_reason":null}]}
8197
82− data: {"id":"chatcmpl-9f99041fa9c5009f6627a15d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_a5ad","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
98+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
8399
84− data: {"id":"chatcmpl-9f99041fa9c5009f6627a15d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\"}"}}]},"finish_reason":null}]}
100+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
85101
86− data: {"id":"chatcmpl-9f99041fa9c5009f6627a15d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":494,"completion_tokens":42,"total_tokens":7480}}
102+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-afa3449a77af404408063e9a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":550,"completion_tokens":24,"total_tokens":7486}}
87105
88106 data: [DONE]
89107
@@ -92,15 +110,15 @@ interactions:
92110 - text/event-stream
93111 status: 200 OK
94112 code: 200
95− duration: 4.129841208s
113+ duration: 2.966963792s
96114- id: 2
97115 request:
98116 proto: HTTP/1.1
99117 proto_major: 1
100118 proto_minor: 1
101− content_length: 32762
119+ content_length: 32799
102120 host: ""
103− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_a5ad\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"call_a5ad\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
121+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d9809e1976446b04ce76ef66a82f7\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"**/main.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\",\"tool_call_id\":\"019d9809e1976446b04ce76ef66a82f7\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
104122 headers:
105123 Accept:
106124 - application/json
@@ -117,13 +135,57 @@ interactions:
117135 content_length: -1
118136 uncompressed: true
119137 body: |+
120− data: {"id":"chatcmpl-3811eb121930af5031268cd8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
138+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d9809eafe90992cd54bdea6e4b5ea","type":"function","index":0,"function":{"name":"view","arguments":""}}]},"finish_reason":null}]}
141+
142+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
143+
144+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
145+
146+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
147+
148+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
149+
150+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
151+
152+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
153+
154+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
155+
156+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
159+
160+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
161+
162+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
163+
164+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
165+
166+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
167+
168+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
169+
170+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
171+
172+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
173+
174+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/update"}}]},"finish_reason":null}]}
175+
176+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_a"}}]},"finish_reason":null}]}
177+
178+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_file"}}]},"finish_reason":null}]}
121179
122− data: {"id":"chatcmpl-3811eb121930af5031268cd8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_fde9","type":"function","index":0,"function":{"name":"edit","arguments":""}}]},"finish_reason":null}]}
180+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
123181
124− data: {"id":"chatcmpl-3811eb121930af5031268cd8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\", \"new_string\": \"fmt.Println(\\\"Hello from Crush!\\\")\", \"old_string\": \"fmt.Println(\\\"Hello, World!\\\")\"}"}}]},"finish_reason":null}]}
182+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
125183
126− data: {"id":"chatcmpl-3811eb121930af5031268cd8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":99,"completion_tokens":54,"total_tokens":7577}}
184+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
185+
186+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
187+
188+ data: {"id":"chatcmpl-6e104c096562bf56d3b50f3e","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":74,"completion_tokens":28,"total_tokens":7526}}
127189
128190 data: [DONE]
129191
@@ -132,15 +194,139 @@ interactions:
132194 - text/event-stream
133195 status: 200 OK
134196 code: 200
135− duration: 2.0086615s
197+ duration: 2.190679666s
136198- id: 3
137199 request:
138200 proto: HTTP/1.1
139201 proto_major: 1
140202 proto_minor: 1
141− content_length: 33239
203+ content_length: 33249
204+ host: ""
205+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d9809e1976446b04ce76ef66a82f7\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"**/main.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\",\"tool_call_id\":\"019d9809e1976446b04ce76ef66a82f7\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d9809eafe90992cd54bdea6e4b5ea\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d9809eafe90992cd54bdea6e4b5ea\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
206+ headers:
207+ Accept:
208+ - application/json
209+ Content-Type:
210+ - application/json
211+ User-Agent:
212+ - Charm-Crush/devel (https://charm.land/crush)
213+ url: https://hyper.charm.land/v1/chat/completions
214+ method: POST
215+ response:
216+ proto: HTTP/2.0
217+ proto_major: 2
218+ proto_minor: 0
219+ content_length: -1
220+ uncompressed: true
221+ body: |+
222+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
223+
224+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d9809f505893b16de5f660bc3858f","type":"function","index":0,"function":{"name":"edit","arguments":""}}]},"finish_reason":null}]}
225+
226+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
227+
228+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
229+
230+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
231+
232+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
233+
234+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
235+
236+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
237+
238+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
239+
240+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
241+
242+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
243+
244+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
245+
246+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
247+
248+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
249+
250+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
251+
252+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
253+
254+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
255+
256+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
257+
258+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/update"}}]},"finish_reason":null}]}
259+
260+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_a"}}]},"finish_reason":null}]}
261+
262+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_file"}}]},"finish_reason":null}]}
263+
264+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/main"}}]},"finish_reason":null}]}
265+
266+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".go"}}]},"finish_reason":null}]}
267+
268+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
269+
270+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
271+
272+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"new_string\": "}}]},"finish_reason":null}]}
273+
274+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"\\tfmt"}}]},"finish_reason":null}]}
275+
276+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".Println"}}]},"finish_reason":null}]}
277+
278+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"(\\\""}}]},"finish_reason":null}]}
279+
280+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
281+
282+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" from"}}]},"finish_reason":null}]}
283+
284+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" crush"}}]},"finish_reason":null}]}
285+
286+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\\\")"}}]},"finish_reason":null}]}
287+
288+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
289+
290+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
291+
292+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"old_string\": "}}]},"finish_reason":null}]}
293+
294+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"\\tfmt"}}]},"finish_reason":null}]}
295+
296+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".Println"}}]},"finish_reason":null}]}
297+
298+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"(\\\""}}]},"finish_reason":null}]}
299+
300+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Hello"}}]},"finish_reason":null}]}
301+
302+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":","}}]},"finish_reason":null}]}
303+
304+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" World"}}]},"finish_reason":null}]}
305+
306+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"!\\\")"}}]},"finish_reason":null}]}
307+
308+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
309+
310+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
311+
312+ data: {"id":"chatcmpl-26d4e7be66c5bdb786f1a99d","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":95,"completion_tokens":54,"total_tokens":7637}}
313+
314+ data: [DONE]
315+
316+ headers:
317+ Content-Type:
318+ - text/event-stream
319+ status: 200 OK
320+ code: 200
321+ duration: 2.064693917s
322+- id: 4
323+ request:
324+ proto: HTTP/1.1
325+ proto_major: 1
326+ proto_minor: 1
327+ content_length: 33778
142328 host: ""
143− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_a5ad\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"call_a5ad\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"call_fde9\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\\", \\\"new_string\\\": \\\"fmt.Println(\\\\\\\"Hello from Crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"fmt.Println(\\\\\\\"Hello, World!\\\\\\\")\\\"}\",\"name\":\"edit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nContent replaced in file: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\n</result>\\n\",\"tool_call_id\":\"call_fde9\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
329+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"update the main.go file by changing the print to say hello from crush\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d9809e1976446b04ce76ef66a82f7\",\"function\":{\"arguments\":\"{\\\"pattern\\\": \\\"**/main.go\\\"}\",\"name\":\"glob\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\",\"tool_call_id\":\"019d9809e1976446b04ce76ef66a82f7\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d9809eafe90992cd54bdea6e4b5ea\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\\"}\",\"name\":\"view\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<file>\\n 1|package main\\n 2|\\n 3|import \\\"fmt\\\"\\n 4|\\n 5|func main() {\\n 6|\\tfmt.Println(\\\"Hello, World!\\\")\\n 7|}\\n</file>\\n\",\"tool_call_id\":\"019d9809eafe90992cd54bdea6e4b5ea\",\"role\":\"tool\"},{\"tool_calls\":[{\"id\":\"019d9809f505893b16de5f660bc3858f\",\"function\":{\"arguments\":\"{\\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\\", \\\"new_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello from crush!\\\\\\\")\\\", \\\"old_string\\\": \\\"\\\\tfmt.Println(\\\\\\\"Hello, World!\\\\\\\")\\\"}\",\"name\":\"edit\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nContent replaced in file: /tmp/crush-test/TestCoderAgent/glm-5.1/update_a_file/main.go\\n</result>\\n\",\"tool_call_id\":\"019d9809f505893b16de5f660bc3858f\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
144330 headers:
145331 Accept:
146332 - application/json
@@ -157,19 +343,41 @@ interactions:
157343 content_length: -1
158344 uncompressed: true
159345 body: |+
160− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
346+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
347+
348+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Done"},"finish_reason":null}]}
349+
350+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
351+
352+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Updated"},"finish_reason":null}]}
353+
354+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
355+
356+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"main"},"finish_reason":null}]}
357+
358+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".go"},"finish_reason":null}]}
359+
360+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":"},"finish_reason":null}]}
361+
362+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"6"},"finish_reason":null}]}
363+
364+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
365+
366+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" to"},"finish_reason":null}]}
367+
368+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" print"},"finish_reason":null}]}
161369
162− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Done —"},"finish_reason":null}]}
370+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" \""},"finish_reason":null}]}
163371
164− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" updated `main.go"},"finish_reason":null}]}
372+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Hello"},"finish_reason":null}]}
165373
166− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":":6` to"},"finish_reason":null}]}
374+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" from"},"finish_reason":null}]}
167375
168− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" print `\"Hello from"},"finish_reason":null}]}
376+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" crush"},"finish_reason":null}]}
169377
170− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" Crush!\"`."},"finish_reason":null}]}
378+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"!\""},"finish_reason":null}]}
171379
172− data: {"id":"chatcmpl-2851497b0957fbbce943de1a","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":61,"completion_tokens":18,"total_tokens":7631}}
380+ data: {"id":"chatcmpl-c99854713066872182157074","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":121,"completion_tokens":17,"total_tokens":7690}}
173381
174382 data: [DONE]
175383
@@ -178,4 +386,4 @@ interactions:
178386 - text/event-stream
179387 status: 200 OK
180388 code: 200
181− duration: 2.289730917s
389+ duration: 1.829815208s
internal/agent/testdata/TestCoderAgent/glm-5.1/write_tool.yaml+120−24
@@ -25,21 +25,23 @@ interactions:
2525 content_length: -1
2626 uncompressed: true
2727 body: |+
28− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
28+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
2929
30− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Create"},"finish_reason":null}]}
30+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":"Create"},"finish_reason":null}]}
3131
32− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" config"},"finish_reason":null}]}
32+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" config"},"finish_reason":null}]}
3333
34− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".json"},"finish_reason":null}]}
34+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":".json"},"finish_reason":null}]}
3535
36− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
36+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
3737
38− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" JSON"},"finish_reason":null}]}
38+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" specified"},"finish_reason":null}]}
3939
40− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" data"},"finish_reason":null}]}
40+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" JSON"},"finish_reason":null}]}
4141
42− data: {"id":"chatcmpl-253bc3ac96dea4bddfb3c35a","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3,"completion_tokens":120,"total_tokens":347}}
42+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{"content":" content"},"finish_reason":null}]}
43+
44+ data: {"id":"chatcmpl-ffece83c09caeb767476cda3","object":"chat.completion.chunk","created":0,"model":"gpt-oss-120b","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":3,"completion_tokens":229,"total_tokens":456}}
4345
4446 data: [DONE]
4547
@@ -48,15 +50,15 @@ interactions:
4850 - text/event-stream
4951 status: 200 OK
5052 code: 200
51− duration: 1.658757708s
53+ duration: 2.674125375s
5254- id: 1
5355 request:
5456 proto: HTTP/1.1
5557 proto_major: 1
5658 proto_minor: 1
57− content_length: 32395
59+ content_length: 32530
5860 host: ""
59− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/write_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use write to create a new file called config.json with content '{\\\"name\\\": \\\"test\\\", \\\"version\\\": \\\"1.0.0\\\"}'\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
61+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/write_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use write to create a new file called config.json with content '{\\\"name\\\": \\\"test\\\", \\\"version\\\": \\\"1.0.0\\\"}'\",\"role\":\"user\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
6062 headers:
6163 Accept:
6264 - application/json
@@ -73,13 +75,93 @@ interactions:
7375 content_length: -1
7476 uncompressed: true
7577 body: |+
76− data: {"id":"chatcmpl-1429bb166af80ff96be7608b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
78+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
79+
80+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"019d980b55a1d5e023711f76ba2935ae","type":"function","index":0,"function":{"name":"write","arguments":""}}]},"finish_reason":null}]}
81+
82+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":""}}]},"finish_reason":null}]}
83+
84+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{"}}]},"finish_reason":null}]}
85+
86+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"content\": "}}]},"finish_reason":null}]}
87+
88+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"{\\\""}}]},"finish_reason":null}]}
89+
90+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"name"}}]},"finish_reason":null}]}
91+
92+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\\":"}}]},"finish_reason":null}]}
93+
94+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \\\""}}]},"finish_reason":null}]}
95+
96+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"test"}}]},"finish_reason":null}]}
97+
98+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\\","}}]},"finish_reason":null}]}
99+
100+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \\\""}}]},"finish_reason":null}]}
101+
102+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"version"}}]},"finish_reason":null}]}
103+
104+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\\":"}}]},"finish_reason":null}]}
105+
106+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":" \\\""}}]},"finish_reason":null}]}
107+
108+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
109+
110+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
111+
112+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"0"}}]},"finish_reason":null}]}
113+
114+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
115+
116+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"0"}}]},"finish_reason":null}]}
117+
118+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\\\"}"}}]},"finish_reason":null}]}
119+
120+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
121+
122+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":", "}}]},"finish_reason":null}]}
123+
124+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"file_path\": "}}]},"finish_reason":null}]}
77125
78− data: {"id":"chatcmpl-1429bb166af80ff96be7608b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"id":"call_6a45","type":"function","index":0,"function":{"name":"write","arguments":""}}]},"finish_reason":null}]}
126+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\"/tmp"}}]},"finish_reason":null}]}
79127
80− data: {"id":"chatcmpl-1429bb166af80ff96be7608b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"content\": \"{\\\"name\\\": \\\"test\\\", \\\"version\\\": \\\"1.0.0\\\"}\", \"file_path\": \"/tmp/crush-test/TestCoderAgent/glm-5.1/write_tool/config.json\"}"}}]},"finish_reason":null}]}
128+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/c"}}]},"finish_reason":null}]}
81129
82− data: {"id":"chatcmpl-1429bb166af80ff96be7608b","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":508,"completion_tokens":59,"total_tokens":7511}}
130+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"rush"}}]},"finish_reason":null}]}
131+
132+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-test"}}]},"finish_reason":null}]}
133+
134+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/Test"}}]},"finish_reason":null}]}
135+
136+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Coder"}}]},"finish_reason":null}]}
137+
138+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"Agent"}}]},"finish_reason":null}]}
139+
140+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/g"}}]},"finish_reason":null}]}
141+
142+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"lm"}}]},"finish_reason":null}]}
143+
144+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"-"}}]},"finish_reason":null}]}
145+
146+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"5"}}]},"finish_reason":null}]}
147+
148+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"."}}]},"finish_reason":null}]}
149+
150+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"1"}}]},"finish_reason":null}]}
151+
152+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/write"}}]},"finish_reason":null}]}
153+
154+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"_tool"}}]},"finish_reason":null}]}
155+
156+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"/config"}}]},"finish_reason":null}]}
157+
158+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":".json"}}]},"finish_reason":null}]}
159+
160+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"\""}}]},"finish_reason":null}]}
161+
162+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"}"}}]},"finish_reason":null}]}
163+
164+ data: {"id":"chatcmpl-20d5234282a7eaa3b3b53bb8","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":564,"completion_tokens":55,"total_tokens":7531}}
83165
84166 data: [DONE]
85167
@@ -88,15 +170,15 @@ interactions:
88170 - text/event-stream
89171 status: 200 OK
90172 code: 200
91− duration: 2.992221875s
173+ duration: 4.502384292s
92174- id: 2
93175 request:
94176 proto: HTTP/1.1
95177 proto_major: 1
96178 proto_minor: 1
97− content_length: 32837
179+ content_length: 33018
98180 host: ""
99− body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\".\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/write_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use write to create a new file called config.json with content '{\\\"name\\\": \\\"test\\\", \\\"version\\\": \\\"1.0.0\\\"}'\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"call_6a45\",\"function\":{\"arguments\":\"{\\\"content\\\": \\\"{\\\\\\\"name\\\\\\\": \\\\\\\"test\\\\\\\", \\\\\\\"version\\\\\\\": \\\\\\\"1.0.0\\\\\\\"}\\\", \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/write_tool/config.json\\\"}\",\"name\":\"write\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nFile successfully written: /tmp/crush-test/TestCoderAgent/glm-5.1/write_tool/config.json\\n</result>\",\"tool_call_id\":\"call_6a45\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
181+ body: "{\"messages\":[{\"content\":\"You are Crush, a powerful AI Assistant that runs in the CLI.\\n\\n<critical_rules>\\nThese rules override everything else. Follow them strictly:\\n\\n1. **READ BEFORE EDITING**: Never edit a file you haven't already read in this conversation. Once read, you don't need to re-read unless it changed. Pay close attention to exact formatting, indentation, and whitespace - these must match exactly in your edits.\\n2. **BE AUTONOMOUS**: Don't ask questions - search, read, think, decide, act. Break complex tasks into steps and complete them all. Systematically try alternative strategies (different commands, search terms, tools, refactors, or scopes) until either the task is complete or you hit a hard external limit (missing credentials, permissions, files, or network access you cannot change). Only stop for actual blocking errors, not perceived difficulty.\\n3. **TEST AFTER CHANGES**: Run tests immediately after each modification.\\n4. **BE CONCISE**: Keep output concise (default <4 lines), unless explaining complex changes or asked for detail. Conciseness applies to output only, not to thoroughness of work.\\n5. **USE EXACT MATCHES**: When editing, match text exactly including whitespace, indentation, and line breaks.\\n6. **NEVER COMMIT**: Unless user explicitly says \\\"commit\\\". When committing, follow the `<git_commits>` format from the bash tool description exactly, including any configured attribution lines.\\n7. **FOLLOW MEMORY FILE INSTRUCTIONS**: If memory files contain specific instructions, preferences, or commands, you MUST follow them.\\n8. **NEVER ADD COMMENTS**: Only add comments if the user asked you to do so. Focus on *why* not *what*. NEVER communicate with the user through code comments.\\n9. **SECURITY FIRST**: Only assist with defensive security tasks. Refuse to create, modify, or improve code that may be used maliciously.\\n10. **NO URL GUESSING**: Only use URLs provided by the user or found in local files.\\n11. **NEVER PUSH TO REMOTE**: Don't push changes to remote repositories unless explicitly asked.\\n12. **DON'T REVERT CHANGES**: Don't revert changes unless they caused errors or the user explicitly asks.\\n13. **TOOL CONSTRAINTS**: Only use documented tools. Never attempt 'apply_patch' or 'apply_diff' - they don't exist. Use 'edit' or 'multiedit' instead.\\n</critical_rules>\\n\\n<communication_style>\\nKeep responses minimal:\\n- ALWAYS think and respond in the same spoken language the prompt was written in.\\n- Under 4 lines of text (tool use doesn't count)\\n- Conciseness is about **text only**: always fully implement the requested feature, tests, and wiring even if that requires many tool calls.\\n- No preamble (\\\"Here's...\\\", \\\"I'll...\\\")\\n- No postamble (\\\"Let me know...\\\", \\\"Hope this helps...\\\")\\n- One-word answers when possible\\n- No emojis ever\\n- No explanations unless user asks\\n- Never send acknowledgement-only responses; after receiving new context or instructions, immediately continue the task or state the concrete next action you will take.\\n- Use rich Markdown formatting (headings, bullet lists, tables, code fences) for any multi-sentence or explanatory answer; only use plain unformatted text if the user explicitly asks.\\n\\nExamples:\\nuser: what is 2+2?\\nassistant: 4\\n\\nuser: list files in src/\\nassistant: [uses ls tool]\\nfoo.c, bar.c, baz.c\\n\\nuser: which file has the foo implementation?\\nassistant: src/foo.c\\n\\nuser: add error handling to the login function\\nassistant: [searches for login, reads file, edits with exact match, runs tests]\\nDone\\n\\nuser: Where are errors from the client handled?\\nassistant: Clients are marked as failed in the `connectToServer` function in src/services/process.go:712.\\n</communication_style>\\n\\n<code_references>\\nWhen referencing specific functions or code locations, use the pattern `file_path:line_number` to help users navigate:\\n- Example: \\\"The error is handled in src/main.go:45\\\"\\n- Example: \\\"See the implementation in pkg/utils/helper.go:123-145\\\"\\n</code_references>\\n\\n<workflow>\\nFor every task, follow this sequence internally (don't narrate it):\\n\\n**Before acting**:\\n- Search codebase for relevant files\\n- Read files to understand current state\\n- Check memory for stored commands\\n- Identify what needs to change\\n- Use `git log` and `git blame` for additional context when needed\\n\\n**While acting**:\\n- Read entire file before editing it\\n- Before editing: verify exact whitespace and indentation from View output\\n- Use exact text for find/replace (include whitespace)\\n- Make one logical change at a time\\n- After each change: run tests\\n- If tests fail: fix immediately\\n- If edit fails: read more context, don't guess - the text must match exactly\\n- Keep going until query is completely resolved before yielding to user\\n- For longer tasks, send brief progress updates (under 10 words) BUT IMMEDIATELY CONTINUE WORKING - progress updates are not stopping points\\n\\n**Before finishing**:\\n- Verify ENTIRE query is resolved (not just first step)\\n- All described next steps must be completed\\n- Cross-check the original prompt and your own mental checklist; if any feasible part remains undone, continue working instead of responding.\\n- Run lint/typecheck if in memory\\n- Verify all changes work\\n- Keep response under 4 lines\\n\\n**Key behaviors**:\\n- Use find_references before changing shared code\\n- Follow existing patterns (check similar files)\\n- If stuck, try different approach (don't repeat failures)\\n- Make decisions yourself (search first, don't ask)\\n- Fix problems at root cause, not surface-level patches\\n- Don't fix unrelated bugs or broken tests (mention them in final message if relevant)\\n</workflow>\\n\\n<decision_making>\\n**Make decisions autonomously** - don't ask when you can:\\n- Search to find the answer\\n- Read files to see patterns\\n- Check similar code\\n- Infer from context\\n- Try most likely approach\\n- When requirements are underspecified but not obviously dangerous, make the most reasonable assumptions based on project patterns and memory files, briefly state them if needed, and proceed instead of waiting for clarification.\\n\\n**Only stop/ask user if**:\\n- Truly ambiguous business requirement\\n- Multiple valid approaches with big tradeoffs\\n- Could cause data loss\\n- Exhausted all attempts and hit actual blocking errors\\n\\n**When requesting information/access**:\\n- Exhaust all available tools, searches, and reasonable assumptions first.\\n- Never say \\\"Need more info\\\" without detail.\\n- In the same message, list each missing item, why it is required, acceptable substitutes, and what you already attempted.\\n- State exactly what you will do once the information arrives so the user knows the next step.\\n\\nWhen you must stop, first finish all unblocked parts of the request, then clearly report: (a) what you tried, (b) exactly why you are blocked, and (c) the minimal external action required. Don't stop just because one path failed—exhaust multiple plausible approaches first.\\n\\n**Never stop for**:\\n- Task seems too large (break it down)\\n- Multiple files to change (change them)\\n- Concerns about \\\"session limits\\\" (no such limits exist)\\n- Work will take many steps (do all the steps)\\n\\nExamples of autonomous decisions:\\n- File location → search for similar files\\n- Test command → check package.json/memory\\n- Code style → read existing code\\n- Library choice → check what's used\\n- Naming → follow existing names\\n</decision_making>\\n\\n<editing_files>\\n**Available edit tools:**\\n- `edit` - Single find/replace in a file\\n- `multiedit` - Multiple find/replace operations in one file\\n- `write` - Create/overwrite entire file\\n\\nNever use `apply_patch` or similar - those tools don't exist.\\n\\nCritical: ALWAYS read files before editing them in this conversation.\\n\\nWhen using edit tools:\\n1. Read the file first - note the EXACT indentation (spaces vs tabs, count)\\n2. Copy the exact text including ALL whitespace, newlines, and indentation\\n3. Include 3-5 lines of context before and after the target\\n4. Verify your old_string would appear exactly once in the file\\n5. If uncertain about whitespace, include more surrounding context\\n6. Verify edit succeeded\\n7. Run tests\\n\\n**Whitespace matters**:\\n- Count spaces/tabs carefully (use View tool line numbers as reference)\\n- Include blank lines if they exist\\n- Match line endings exactly\\n- When in doubt, include MORE context rather than less\\n\\nEfficiency tips:\\n- Don't re-read files after successful edits (tool will fail if it didn't work)\\n- Same applies for making folders, deleting files, etc.\\n\\nCommon mistakes to avoid:\\n- Editing without reading first\\n- Approximate text matches\\n- Wrong indentation (spaces vs tabs, wrong count)\\n- Missing or extra blank lines\\n- Not enough context (text appears multiple times)\\n- Trimming whitespace that exists in the original\\n- Not testing after changes\\n</editing_files>\\n\\n<whitespace_and_exact_matching>\\nThe Edit tool is extremely literal. \\\"Close enough\\\" will fail.\\n\\n**Before every edit**:\\n1. View the file and locate the exact lines to change\\n2. Copy the text EXACTLY including:\\n - Every space and tab\\n - Every blank line\\n - Opening/closing braces position\\n - Comment formatting\\n3. Include enough surrounding lines (3-5) to make it unique\\n4. Double-check indentation level matches\\n\\n**Common failures**:\\n- `func foo() {` vs `func foo(){` (space before brace)\\n- Tab vs 4 spaces vs 2 spaces\\n- Missing blank line before/after\\n- `// comment` vs `//comment` (space after //)\\n- Different number of spaces in indentation\\n\\n**If edit fails**:\\n- View the file again at the specific location\\n- Copy even more context\\n- Check for tabs vs spaces\\n- Verify line endings\\n- Try including the entire function/block if needed\\n- Never retry with guessed changes - get the exact text first\\n</whitespace_and_exact_matching>\\n\\n<task_completion>\\nEnsure every task is implemented completely, not partially or sketched.\\n\\n1. **Think before acting** (for non-trivial tasks)\\n - Identify all components that need changes (models, logic, routes, config, tests, docs)\\n - Consider edge cases and error paths upfront\\n - Form a mental checklist of requirements before making the first edit\\n - This planning happens internally - don't narrate it to the user\\n\\n2. **Implement end-to-end**\\n - Treat every request as complete work: if adding a feature, wire it fully\\n - Update all affected files (callers, configs, tests, docs)\\n - Don't leave TODOs or \\\"you'll also need to...\\\" - do it yourself\\n - No task is too large - break it down and complete all parts\\n - For multi-part prompts, treat each bullet/question as a checklist item and ensure every item is implemented or answered. Partial completion is not an acceptable final state.\\n\\n3. **Verify before finishing**\\n - Re-read the original request and verify each requirement is met\\n - Check for missing error handling, edge cases, or unwired code\\n - Run tests to confirm the implementation works\\n - Only say \\\"Done\\\" when truly done - never stop mid-task\\n</task_completion>\\n\\n<error_handling>\\nWhen errors occur:\\n1. Read complete error message\\n2. Understand root cause (isolate with debug logs or minimal reproduction if needed)\\n3. Try different approach (don't repeat same action)\\n4. Search for similar code that works\\n5. Make targeted fix\\n6. Test to verify\\n7. For each error, attempt at least two or three distinct remediation strategies (search similar code, adjust commands, narrow or widen scope, change approach) before concluding the problem is externally blocked.\\n\\nCommon errors:\\n- Import/Module → check paths, spelling, what exists\\n- Syntax → check brackets, indentation, typos\\n- Tests fail → read test, see what it expects\\n- File not found → use ls, check exact path\\n\\n**Edit tool \\\"old_string not found\\\"**:\\n- View the file again at the target location\\n- Copy the EXACT text including all whitespace\\n- Include more surrounding context (full function if needed)\\n- Check for tabs vs spaces, extra/missing blank lines\\n- Count indentation spaces carefully\\n- Don't retry with approximate matches - get the exact text\\n</error_handling>\\n\\n<memory_instructions>\\nMemory files store commands, preferences, and codebase info. Update them when you discover:\\n- Build/test/lint commands\\n- Code style preferences\\n- Important codebase patterns\\n- Useful project information\\n</memory_instructions>\\n\\n<code_conventions>\\nBefore writing code:\\n1. Check if library exists (look at imports, package.json)\\n2. Read similar code for patterns\\n3. Match existing style\\n4. Use same libraries/frameworks\\n5. Follow security best practices (never log secrets)\\n6. Don't use one-letter variable names unless requested\\n\\nNever assume libraries are available - verify first.\\n\\n**Ambition vs. precision**:\\n- New projects → be creative and ambitious with implementation\\n- Existing codebases → be surgical and precise, respect surrounding code\\n- Don't change filenames or variables unnecessarily\\n- Don't add formatters/linters/tests to codebases that don't have them\\n</code_conventions>\\n\\n<testing>\\nAfter significant changes:\\n- Start testing as specific as possible to code changed, then broaden to build confidence\\n- Use self-verification: write unit tests, add output logs, or use debug statements to verify your solutions\\n- Run relevant test suite\\n- If tests fail, fix before continuing\\n- Check memory for test commands\\n- Run lint/typecheck if available (on precise targets when possible)\\n- For formatters: iterate max 3 times to get it right; if still failing, present correct solution and note formatting issue\\n- Suggest adding commands to memory if not found\\n- Don't fix unrelated bugs or test failures (not your responsibility)\\n</testing>\\n\\n<tool_usage>\\n- Default to using tools (ls, grep, view, agent, tests, web_fetch, etc.) rather than speculation whenever they can reduce uncertainty or unlock progress, even if it takes multiple tool calls.\\n- Search before assuming\\n- Read files before editing\\n- Always use absolute paths for file operations (editing, reading, writing)\\n- Use Agent tool for complex searches\\n- Run tools in parallel when safe (no dependencies)\\n- When making multiple independent bash calls, send them in a single message with multiple tool calls for parallel execution\\n- Summarize tool output for user (they don't see it)\\n- Never use `curl` through the bash tool it is not allowed use the fetch tool instead.\\n- Only use the tools you know exist.\\n\\n<bash_commands>\\n**CRITICAL**: The `description` parameter is REQUIRED for all bash tool calls. Always provide it.\\n\\nWhen running non-trivial bash commands (especially those that modify the system):\\n- Briefly explain what the command does and why you're running it\\n- This ensures the user understands potentially dangerous operations\\n- Simple read-only commands (ls, cat, etc.) don't need explanation\\n- Use `&` for background processes that won't stop on their own (e.g., `node server.js &`)\\n- Avoid interactive commands - use non-interactive versions (e.g., `npm init -y` not `npm init`)\\n- Combine related commands to save time (e.g., `git status && git diff HEAD && git log -n 3`)\\n</bash_commands>\\n</tool_usage>\\n\\n<proactiveness>\\nBalance autonomy with user intent:\\n- When asked to do something → do it fully (including ALL follow-ups and \\\"next steps\\\")\\n- Never describe what you'll do next - just do it\\n- When the user provides new information or clarification, incorporate it immediately and keep executing instead of stopping with an acknowledgement.\\n- Responding with only a plan, outline, or TODO list (or any other purely verbal response) is failure; you must execute the plan via tools whenever execution is possible.\\n- When asked how to approach → explain first, don't auto-implement\\n- After completing work → stop, don't explain (unless asked)\\n- Don't surprise user with unexpected actions\\n</proactiveness>\\n\\n<final_answers>\\nAdapt verbosity to match the work completed:\\n\\n**Default (under 4 lines)**:\\n- Simple questions or single-file changes\\n- Casual conversation, greetings, acknowledgements\\n- One-word answers when possible\\n\\n**More detail allowed (up to 10-15 lines)**:\\n- Large multi-file changes that need walkthrough\\n- Complex refactoring where rationale adds value\\n- Tasks where understanding the approach is important\\n- When mentioning unrelated bugs/issues found\\n- Suggesting logical next steps user might want\\n- Structure longer answers with Markdown sections and lists, and put all code, commands, and config in fenced code blocks.\\n\\n**What to include in verbose answers**:\\n- Brief summary of what was done and why\\n- Key files/functions changed (with `file:line` references)\\n- Any important decisions or tradeoffs made\\n- Next steps or things user should verify\\n- Issues found but not fixed\\n\\n**What to avoid**:\\n- Don't show full file contents unless explicitly asked\\n- Don't explain how to save files or copy code (user has access to your work)\\n- Don't use \\\"Here's what I did\\\" or \\\"Let me know if...\\\" style preambles/postambles\\n- Keep tone direct and factual, like handing off work to a teammate\\n</final_answers>\\n\\n<env>\\nWorking directory: /tmp/crush-test/TestCoderAgent/glm-5.1/write_tool\\nIs directory a git repo: no\\nPlatform: linux\\nToday's date: 1/1/2025\\n\\n</env>\\n\\n\\n\\n<available_skills>\\n <skill>\\n <name>jq</name>\\n <description>Process, filter, transform, generate, and construct JSON data using the jq command-line processor. Crush includes a built-in jq implementation (powered by gojq) available in the bash tool. Use when the user needs to query, filter, reshape, extract, create, or construct JSON — including API responses, config files, log output, or any structured data. Also use when generating JSON from scratch with jq -n, or when helping users write or debug jq expressions.</description>\\n <location>crush://skills/jq/SKILL.md</location>\\n <type>builtin</type>\\n </skill>\\n</available_skills>\\n\\n<skills_usage>\\nWhen a user task matches a skill's description, read the skill's SKILL.md file to get full instructions.\\nSkills are activated by reading their **exact** location path as shown above using the View tool. Always pass the location value directly to the View tool's file_path parameter — never guess, modify, or construct skill paths yourself.\\nBuiltin skills (type=builtin) have virtual location identifiers starting with \\\"crush://skills/\\\". The \\\"crush://\\\" prefix is NOT a URL or network address — it is a special internal identifier that the View tool understands natively. Pass them verbatim to the View tool. Do not treat them as URLs, MCP resources, or filesystem paths.\\nDo not use MCP tools (including read_mcp_resource) to load skills.\\nFollow the skill's instructions to complete the task.\\nIf a skill mentions scripts, references, or assets, they are placed in the same folder as the skill itself (e.g., scripts/, references/, assets/ subdirectories within the skill's folder).\\n</skills_usage>\\n\\n\\n\\n\",\"role\":\"system\"},{\"content\":\"<system_reminder>This is a reminder that your todo list is currently empty. DO NOT mention this to the user explicitly because they are already aware.\\nIf you are working on tasks that would benefit from a todo list please use the \\\"todos\\\" tool to create one.\\nIf not, please feel free to ignore. Again do not mention this message to the user.</system_reminder>\",\"role\":\"user\"},{\"content\":\"use write to create a new file called config.json with content '{\\\"name\\\": \\\"test\\\", \\\"version\\\": \\\"1.0.0\\\"}'\",\"role\":\"user\"},{\"tool_calls\":[{\"id\":\"019d980b55a1d5e023711f76ba2935ae\",\"function\":{\"arguments\":\"{\\\"content\\\": \\\"{\\\\\\\"name\\\\\\\": \\\\\\\"test\\\\\\\", \\\\\\\"version\\\\\\\": \\\\\\\"1.0.0\\\\\\\"}\\\", \\\"file_path\\\": \\\"/tmp/crush-test/TestCoderAgent/glm-5.1/write_tool/config.json\\\"}\",\"name\":\"write\"},\"type\":\"function\"}],\"role\":\"assistant\"},{\"content\":\"<result>\\nFile successfully written: /tmp/crush-test/TestCoderAgent/glm-5.1/write_tool/config.json\\n</result>\",\"tool_call_id\":\"019d980b55a1d5e023711f76ba2935ae\",\"role\":\"tool\"}],\"model\":\"glm-5.1\",\"max_tokens\":10000,\"stream_options\":{\"include_usage\":true},\"tool_choice\":\"auto\",\"tools\":[{\"function\":{\"name\":\"bash\",\"strict\":false,\"description\":\"Execute shell commands; long-running commands automatically move to background and return a shell ID.\\n\\n<cross_platform>\\nUses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).\\nUse forward slashes for paths: \\\"ls C:/foo/bar\\\" not \\\"ls C:\\\\foo\\\\bar\\\".\\nCommon shell builtins and core utils available on Windows.\\n</cross_platform>\\n\\n<execution_steps>\\n1. Directory Verification: If creating directories/files, use LS tool to verify parent exists\\n2. Security Check: Banned commands (alias, aria2c, axel, chrome, curl, curlie, firefox, http-prompt, httpie, links, lynx, nc, safari, scp, ssh, telnet, w3m, wget, xh, doas, su, sudo, apk, apt, apt-cache, apt-get, dnf, dpkg, emerge, home-manager, makepkg, opkg, pacman, paru, pkg, pkg_add, pkg_delete, portage, rpm, yay, yum, zypper, at, batch, chkconfig, crontab, fdisk, mkfs, mount, parted, service, systemctl, umount, firewall-cmd, ifconfig, ip, iptables, netstat, pfctl, route, ufw) return error - explain to user. Safe read-only commands execute without prompts\\n3. Command Execution: Execute with proper quoting, capture output\\n4. Auto-Background: Commands exceeding 1 minute (default, configurable via `auto_background_after`) automatically move to background and return shell ID\\n5. Output Processing: Truncate if exceeds 30000 characters\\n6. Return Result: Include errors, metadata with <cwd></cwd> tags\\n</execution_steps>\\n\\n<usage_notes>\\n- Command required, working_dir optional (defaults to current directory)\\n- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'\\n- Chain with ';' or '&&', avoid newlines except in quoted strings\\n- Each command runs in independent shell (no state persistence between calls)\\n- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)\\n</usage_notes>\\n\\n<background_execution>\\n- Set run_in_background=true to run commands in a separate background shell\\n- Returns a shell ID for managing the background process\\n- Use job_output tool to view current output from background shell\\n- Use job_kill tool to terminate a background shell\\n- IMPORTANT: NEVER use `&` at the end of commands to run in background - use run_in_background parameter instead\\n- Commands that should run in background:\\n * Long-running servers (e.g., `npm start`, `python -m http.server`, `node server.js`)\\n * Watch/monitoring tasks (e.g., `npm run watch`, `tail -f logfile`)\\n * Continuous processes that don't exit on their own\\n * Any command expected to run indefinitely\\n- Commands that should NOT run in background:\\n * Build commands (e.g., `npm run build`, `go build`)\\n * Test suites (e.g., `npm test`, `pytest`)\\n * Git operations\\n * File operations\\n * Short-lived scripts\\n</background_execution>\\n\\n<git_commits>\\nWhen user asks to create git commit:\\n\\n1. Single message with three tool_use blocks (IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - git log (recent commit message style)\\n\\n2. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.\\n\\n3. Analyze staged changes in <commit_analysis> tags:\\n - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)\\n - Brainstorm purpose/motivation, assess project impact, check for sensitive info\\n - Don't use tools beyond git context\\n - Draft concise (1-2 sentences) message focusing on \\\"why\\\" not \\\"what\\\"\\n - Use clear language, accurate reflection (\\\"add\\\"=new feature, \\\"update\\\"=enhancement, \\\"fix\\\"=bug fix)\\n - Avoid generic messages, review draft\\n\\n4. Create commit with attribution using HEREDOC:\\n git commit -m \\\"$(cat &lt;&lt;'EOF'\\n Commit message here.\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n\\n Co-Authored-By: Crush <crush@charm.land>\\n\\n\\n EOF\\n )\\\"\\n\\n5. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.\\n\\n6. Run git status to verify.\\n\\nNotes: Use \\\"git commit -am\\\" when possible, don't stage unrelated files, NEVER update config, don't push, no -i flags, no empty commits, return empty response.\\n</git_commits>\\n\\n<pull_requests>\\nUse gh command for ALL GitHub tasks. When user asks to create PR:\\n\\n1. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):\\n - git status (untracked files)\\n - git diff (staged/unstaged changes)\\n - Check if branch tracks remote and is up to date\\n - git log and 'git diff main...HEAD' (full commit history from main divergence)\\n\\n2. Create new branch if needed\\n3. Commit changes if needed\\n4. Push to remote with -u flag if needed\\n\\n5. Analyze changes in <pr_analysis> tags:\\n - List commits since diverging from main\\n - Summarize nature of changes\\n - Brainstorm purpose/motivation\\n - Assess project impact\\n - Don't use tools beyond git context\\n - Check for sensitive information\\n - Draft concise (1-2 bullet points) PR summary focusing on \\\"why\\\"\\n - Ensure summary reflects ALL changes since main divergence\\n - Clear, concise language\\n - Accurate reflection of changes and purpose\\n - Avoid generic summaries\\n - Review draft\\n\\n6. Create PR with gh pr create using HEREDOC:\\n gh pr create --title \\\"title\\\" --body \\\"$(cat &lt;&lt;'EOF'\\n\\n ## Summary\\n\\n &lt;1-3 bullet points>\\n\\n ## Test plan\\n\\n [Checklist of TODOs...]\\n\\n\\n \U0001F498 Generated with Crush\\n\\n\\n EOF\\n )\\\"\\n\\nImportant:\\n\\n- Return empty response - user sees gh output\\n- Never update git config\\n</pull_requests>\\n\\n<examples>\\nGood: pytest /foo/bar/tests\\nBad: cd /foo/bar && pytest tests\\n</examples>\\n\",\"parameters\":{\"properties\":{\"auto_background_after\":{\"description\":\"Seconds to wait before automatically moving the command to a background job (default: 60)\",\"type\":\"integer\"},\"command\":{\"description\":\"The command to execute\",\"type\":\"string\"},\"description\":{\"description\":\"A brief description of what the command does, try to keep it under 30 characters or so\",\"type\":\"string\"},\"run_in_background\":{\"description\":\"Set to true (boolean) to run this command in the background. Use job_output to read the output later.\",\"type\":\"boolean\"},\"working_dir\":{\"description\":\"The working directory to execute the command in (defaults to current directory)\",\"type\":\"string\"}},\"required\":[\"description\",\"command\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"download\",\"strict\":false,\"description\":\"Download a URL directly to a local file (binary-safe, streaming, max 100MB); overwrites without warning. For reading content into context use fetch.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The local file path where the downloaded content should be saved\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 600)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to download from\",\"type\":\"string\"}},\"required\":[\"url\",\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"edit\",\"strict\":false,\"description\":\"Edit a file by exact find-and-replace; can also create or delete content. For renames/moves use bash. For large edits use write.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"},\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false)\",\"type\":\"boolean\"}},\"required\":[\"file_path\",\"old_string\",\"new_string\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"multiedit\",\"strict\":false,\"description\":\"Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.\",\"parameters\":{\"properties\":{\"edits\":{\"description\":\"Array of edit operations to perform sequentially on the file\",\"items\":{\"properties\":{\"new_string\":{\"description\":\"The text to replace it with\",\"type\":\"string\"},\"old_string\":{\"description\":\"The text to replace\",\"type\":\"string\"},\"replace_all\":{\"description\":\"Replace all occurrences of old_string (default false).\",\"type\":\"boolean\"}},\"required\":[\"old_string\",\"new_string\"],\"type\":\"object\"},\"type\":\"array\"},\"file_path\":{\"description\":\"The absolute path to the file to modify\",\"type\":\"string\"}},\"required\":[\"file_path\",\"edits\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"fetch\",\"strict\":false,\"description\":\"Fetch raw content from a URL as text, markdown, or html (max 5MB); no AI processing. For analysis or extraction use agentic_fetch.\",\"parameters\":{\"properties\":{\"format\":{\"description\":\"The format to return the content in (text, markdown, or html)\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"},\"url\":{\"description\":\"The URL to fetch content from\",\"type\":\"string\"}},\"required\":[\"url\",\"format\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"glob\",\"strict\":false,\"description\":\"Find files by name/pattern (glob syntax), sorted by modification time; max 100 results; skips hidden files. Use grep to search file contents.\",\"parameters\":{\"properties\":{\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The glob pattern to match files against\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"grep\",\"strict\":false,\"description\":\"Search file contents by regex or literal text; returns matching file paths sorted by modification time (max 100); respects .gitignore. Use glob to filter by filename, not contents.\",\"parameters\":{\"properties\":{\"include\":{\"description\":\"File pattern to include in the search (e.g. \\\"*.js\\\", \\\"*.{ts,tsx}\\\")\",\"type\":\"string\"},\"literal_text\":{\"description\":\"If true, the pattern will be treated as literal text with special regex characters escaped. Default is false.\",\"type\":\"boolean\"},\"path\":{\"description\":\"The directory to search in. Defaults to the current working directory.\",\"type\":\"string\"},\"pattern\":{\"description\":\"The regex pattern to search for in file contents\",\"type\":\"string\"}},\"required\":[\"pattern\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"ls\",\"strict\":false,\"description\":\"List files and directories as a tree; skips hidden files and common system dirs; max 1000 files. Use glob to find files by pattern, grep to search contents.\",\"parameters\":{\"properties\":{\"depth\":{\"description\":\"The maximum depth to traverse\",\"type\":\"integer\"},\"ignore\":{\"description\":\"List of glob patterns to ignore\",\"items\":{\"type\":\"string\"},\"type\":\"array\"},\"path\":{\"description\":\"The path to the directory to list (defaults to current working directory)\",\"type\":\"string\"}},\"required\":[],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"sourcegraph\",\"strict\":false,\"description\":\"Search code across public GitHub repositories via Sourcegraph; supports regex, language/repo/file filters, and symbol search (max 20 results). Only searches public repos.\",\"parameters\":{\"properties\":{\"context_window\":{\"description\":\"The context around the match to return (default: 10 lines)\",\"type\":\"integer\"},\"count\":{\"description\":\"Optional number of results to return (default: 10, max: 20)\",\"type\":\"integer\"},\"query\":{\"description\":\"The Sourcegraph search query\",\"type\":\"string\"},\"timeout\":{\"description\":\"Optional timeout in seconds (max 120)\",\"type\":\"integer\"}},\"required\":[\"query\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"view\",\"strict\":false,\"description\":\"Read a file by path with line numbers; supports offset and line limit (default 2000, max 5MB); renders images (PNG, JPEG, GIF, BMP, SVG, WebP); use ls for directories.\",\"parameters\":{\"properties\":{\"file_path\":{\"description\":\"The path to the file to read\",\"type\":\"string\"},\"limit\":{\"description\":\"The number of lines to read (defaults to 2000)\",\"type\":\"integer\"},\"offset\":{\"description\":\"The line number to start reading from (0-based)\",\"type\":\"integer\"}},\"required\":[\"file_path\"],\"type\":\"object\"}},\"type\":\"function\"},{\"function\":{\"name\":\"write\",\"strict\":false,\"description\":\"Create or overwrite a file with given content; auto-creates parent dirs. Cannot append. Read the file first to avoid conflicts. For surgical changes use edit or multiedit.\",\"parameters\":{\"properties\":{\"content\":{\"description\":\"The content to write to the file\",\"type\":\"string\"},\"file_path\":{\"description\":\"The path to the file to write\",\"type\":\"string\"}},\"required\":[\"file_path\",\"content\"],\"type\":\"object\"}},\"type\":\"function\"}],\"stream\":true}"
100182 headers:
101183 Accept:
102184 - application/json
@@ -113,15 +195,29 @@ interactions:
113195 content_length: -1
114196 uncompressed: true
115197 body: |+
116− data: {"id":"chatcmpl-cb870884253ff16c0884028f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
198+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
199+
200+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Created"},"finish_reason":null}]}
201+
202+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" `"},"finish_reason":null}]}
203+
204+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"config"},"finish_reason":null}]}
205+
206+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":".json"},"finish_reason":null}]}
207+
208+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"`"},"finish_reason":null}]}
209+
210+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" with"},"finish_reason":null}]}
211+
212+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" the"},"finish_reason":null}]}
117213
118− data: {"id":"chatcmpl-cb870884253ff16c0884028f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"Created `config.json"},"finish_reason":null}]}
214+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" specified"},"finish_reason":null}]}
119215
120− data: {"id":"chatcmpl-cb870884253ff16c0884028f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"` with the specified"},"finish_reason":null}]}
216+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" content"},"finish_reason":null}]}
121217
122− data: {"id":"chatcmpl-cb870884253ff16c0884028f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":" content."},"finish_reason":null}]}
218+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{"content":"."},"finish_reason":null}]}
123219
124− data: {"id":"chatcmpl-cb870884253ff16c0884028f","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":110,"completion_tokens":11,"total_tokens":7545}}
220+ data: {"id":"chatcmpl-feff87d0467f0572419c1ee6","object":"chat.completion.chunk","created":0,"model":"glm-5.1","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":646,"completion_tokens":11,"total_tokens":7569}}
125221
126222 data: [DONE]
127223
@@ -130,4 +226,4 @@ interactions:
130226 - text/event-stream
131227 status: 200 OK
132228 code: 200
133− duration: 894.794375ms
229+ duration: 1.773363667s