bash.tpl

  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 background=true to run commands in a separate background shell
 28- Commands taking longer than 1 minute automatically convert to background
 29- Returns a shell ID for managing the background process
 30- Use bash_output tool to view current output from background shell
 31- Use bash_kill tool to terminate a background shell
 32- Useful for long-running processes, servers, or monitoring tasks
 33</background_execution>
 34
 35<git_commits>
 36When user asks to create git commit:
 37
 381. Single message with three tool_use blocks (IMPORTANT for speed):
 39   - git status (untracked files)
 40   - git diff (staged/unstaged changes)
 41   - git log (recent commit message style)
 42
 432. Add relevant untracked files to staging. Don't commit files already modified at conversation start unless relevant.
 44
 453. Analyze staged changes in <commit_analysis> tags:
 46   - List changed/added files, summarize nature (feature/enhancement/bug fix/refactoring/test/docs)
 47   - Brainstorm purpose/motivation, assess project impact, check for sensitive info
 48   - Don't use tools beyond git context
 49   - Draft concise (1-2 sentences) message focusing on "why" not "what"
 50   - Use clear language, accurate reflection ("add"=new feature, "update"=enhancement, "fix"=bug fix)
 51   - Avoid generic messages, review draft
 52
 534. Create commit with Crush signature using HEREDOC:
 54   git commit -m "$(cat <<'EOF'
 55   Commit message here.
 56{{ if .Attribution.GeneratedWith}}
 57   💘 Generated with Crush
 58{{ end }}
 59{{ if .Attribution.CoAuthoredBy}}
 60   Co-Authored-By: Crush <crush@charm.land>
 61{{ end }}
 62   EOF
 63   )"
 64
 655. If pre-commit hook fails, retry ONCE. If fails again, hook preventing commit. If succeeds but files modified, MUST amend.
 66
 676. Run git status to verify.
 68
 69Notes: 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.
 70</git_commits>
 71
 72<pull_requests>
 73Use gh command for ALL GitHub tasks. When user asks to create PR:
 74
 751. Single message with multiple tool_use blocks (VERY IMPORTANT for speed):
 76   - git status (untracked files)
 77   - git diff (staged/unstaged changes)
 78   - Check if branch tracks remote and is up to date
 79   - git log and 'git diff main...HEAD' (full commit history from main divergence)
 80
 812. Create new branch if needed
 823. Commit changes if needed
 834. Push to remote with -u flag if needed
 84
 855. Analyze changes in <pr_analysis> tags:
 86   - List commits since diverging from main
 87   - Summarize nature of changes
 88   - Brainstorm purpose/motivation
 89   - Assess project impact
 90   - Don't use tools beyond git context
 91   - Check for sensitive information
 92   - Draft concise (1-2 bullet points) PR summary focusing on "why"
 93   - Ensure summary reflects ALL changes since main divergence
 94   - Clear, concise language
 95   - Accurate reflection of changes and purpose
 96   - Avoid generic summaries
 97   - Review draft
 98
 996. Create PR with gh pr create using HEREDOC:
100   gh pr create --title "title" --body "$(cat <<'EOF'
101
102   ## Summary
103
104   <1-3 bullet points>
105
106   ## Test plan
107
108   [Checklist of TODOs...]
109
110{{ if .Attribution.GeneratedWith}}
111   💘 Generated with Crush
112{{ end }}
113
114   EOF
115   )"
116
117Important:
118
119- Return empty response - user sees gh output
120- Never update git config
121</pull_requests>
122
123<examples>
124Good: pytest /foo/bar/tests
125Bad: cd /foo/bar && pytest tests
126</examples>