1Executes bash commands with automatic background conversion for long-running tasks.
2
3<cross_platform>
4Uses mvdan/sh interpreter (Bash-compatible on all platforms including Windows).
5Use forward slashes for paths: "ls C:/foo/bar" not "ls C:\foo\bar".
6Common shell builtins and core utils available on Windows.
7</cross_platform>
8
9<execution_steps>
101. Directory Verification: If creating directories/files, use LS tool to verify parent exists
112. Security Check: Banned commands ({{ .BannedCommands }}) return error - explain to user. Safe read-only commands execute without prompts
123. Command Execution: Execute with proper quoting, capture output
134. Auto-Background: Commands exceeding 1 minute automatically move to background and return shell ID
145. Output Processing: Truncate if exceeds {{ .MaxOutputLength }} characters
156. Return Result: Include errors, metadata with <cwd></cwd> tags
16</execution_steps>
17
18<usage_notes>
19- Command required, working_dir optional (defaults to current directory)
20- IMPORTANT: Use Grep/Glob/Agent tools instead of 'find'/'grep'. Use View/LS tools instead of 'cat'/'head'/'tail'/'ls'
21- Chain with ';' or '&&', avoid newlines except in quoted strings
22- Each command runs in independent shell (no state persistence between calls)
23- Prefer absolute paths over 'cd' (use 'cd' only if user explicitly requests)
24</usage_notes>
25
26<background_execution>
27- Set run_in_background=true to run commands in a separate background shell
28- Returns a shell ID for managing the background process
29- Use bash_output tool to view current output from background shell
30- Use bash_kill tool to terminate a background shell
31- IMPORTANT: NEVER use '&' at the end of commands to run in background - use run_in_background parameter instead
32- Commands that should run in background:
33 * Long-running servers (e.g., 'npm start', 'python -m http.server', 'node server.js')
34 * Watch/monitoring tasks (e.g., 'npm run watch', 'tail -f logfile')
35 * Continuous processes that don't exit on their own
36 * Any command expected to run indefinitely
37- Commands that should NOT run in background:
38 * Build commands (e.g., 'npm run build', 'go build')
39 * Test suites (e.g., 'npm test', 'pytest')
40 * Git operations
41 * File operations
42 * Short-lived scripts
43</background_execution>
44
45<git_commits>
46When user asks to create git commit:
47
481. Single message with three tool_use blocks (IMPORTANT for speed):
49 - git status (untracked files)
50 - git diff (staged/unstaged changes)
51 - git log (recent commit message style)
52
532. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.
54
553. Analyze staged changes in <commit_analysis> tags:
56 - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)
57 - Brainstorm purpose/motivation, assess project impact, check for sensitive info
58 - Don't use tools beyond git context
59 - Draft concise (1-2 sentences) message focusing on "why" not "what"
60 - Use clear language, accurate reflection ("add"=new feature, "update"=enhancement, "fix"=bug fix)
61 - Avoid generic messages, review draft
62
634. Create commit with Crush signature using HEREDOC:
64 git commit -m "$(cat <<'EOF'
65 Commit message here.
66{{ if .Attribution.GeneratedWith}}
67 💘 Generated with Crush
68{{ end }}
69{{ if .Attribution.CoAuthoredBy}}
70 Co-Authored-By: Crush <crush@charm.land>
71{{ end }}
72 EOF
73 )"
74
755. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.
76
776. Run git status to verify.
78
79Notes: 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.
80</git_commits>
81
82<pull_requests>
83Use gh command for ALL GitHub tasks. When user asks to create PR:
84
851. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):
86 - git status (untracked files)
87 - git diff (staged/unstaged changes)
88 - Check if branch tracks remote and is up to date
89 - git log and 'git diff main...HEAD' (full commit history from main divergence)
90
912. Create new branch if needed
923. Commit changes if needed
934. Push to remote with -u flag if needed
94
955. Analyze changes in <pr_analysis> tags:
96 - List commits since diverging from main
97 - Summarize nature of changes
98 - Brainstorm purpose/motivation
99 - Assess project impact
100 - Don't use tools beyond git context
101 - Check for sensitive information
102 - Draft concise (1-2 bullet points) PR summary focusing on "why"
103 - Ensure summary reflects ALL changes since main divergence
104 - Clear, concise language
105 - Accurate reflection of changes and purpose
106 - Avoid generic summaries
107 - Review draft
108
1096. Create PR with gh pr create using HEREDOC:
110 gh pr create --title "title" --body "$(cat <<'EOF'
111
112 ## Summary
113
114 <1-3 bullet points>
115
116 ## Test plan
117
118 [Checklist of TODOs...]
119
120{{ if .Attribution.GeneratedWith}}
121 💘 Generated with Crush
122{{ end }}
123
124 EOF
125 )"
126
127Important:
128
129- Return empty response - user sees gh output
130- Never update git config
131</pull_requests>
132
133<examples>
134Good: pytest /foo/bar/tests
135Bad: cd /foo/bar && pytest tests
136</examples>