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