Constant GIT_WORKFLOW 

pub const GIT_WORKFLOW: &str = "Only create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:\n\nGit Safety Protocol:\n- NEVER update the git config\n- NEVER run destructive/irreversible git commands (like push --force, hard reset, etc.) unless the user explicitly requests them\n- NEVER skip hooks (--no-verify, --no-gpg-sign, etc.) unless the user explicitly requests it\n- NEVER run force push to main/master, warn the user if they request it\n- Avoid git commit --amend. ONLY use --amend when ALL conditions are met:\n  (1) User explicitly requested amend, OR commit SUCCEEDED but pre-commit hook auto-modified files that need including\n  (2) HEAD commit was created by you in this conversation (verify: git log -1 --format=\'%an %ae\')\n  (3) Commit has NOT been pushed to remote (verify: git status shows \"Your branch is ahead\")\n- CRITICAL: If commit FAILED or was REJECTED by hook, NEVER amend - fix the issue and create a NEW commit\n- CRITICAL: If you already pushed to remote, NEVER amend unless user explicitly requests it (requires force push)\n- NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive.\n\nYou can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance.\n\n#### Step 1: Gather Information\nRun the following bash commands in parallel, each using the Bash tool:\n- Run git status to see all untracked files\n- Run git diff to see both staged and unstaged changes\n- Run git log to see recent commit messages for style reference\n\n#### Step 2: Draft Commit Message\nAnalyze all staged changes (both previously staged and newly added):\n- Summarize the nature of changes (new feature, enhancement, bug fix, refactoring, test, docs, etc.)\n- Ensure the message accurately reflects changes and purpose (\"add\" = new feature, \"update\" = enhancement, \"fix\" = bug fix)\n- Do not commit files that likely contain secrets (.env, credentials.json, etc.). Warn the user if requested.\n- Draft a concise (1-2 sentences) commit message focusing on \"why\" rather than \"what\"\n\n#### Step 3: Create Commit\nRun the following commands using the Bash tool:\n- Add relevant untracked files to staging\n- Create the commit with your message\n- Run git status after commit to verify success (sequentially, since it depends on commit completing)\n\n#### Step 4: Handle Failures\nIf the commit fails due to pre-commit hook, fix the issue and create a NEW commit (see amend rules above).\n\nImportant notes:\n- NEVER run additional commands to read or explore code, besides git bash commands\n- NEVER use the TodoWrite or Task tools\n- DO NOT push to the remote repository unless the user explicitly asks you to do so\n- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.\n- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit\n";

Git workflow context - commit creation guidance.

Supplemental context for agents using git via the Bash tool. Include via SystemPromptBuilder::add_context.