Add prompt for git workflow

Author: shivangag

src/core/prompts/sections/rules.ts

@@ -44,6 +44,25 @@ function getEditingInstructions(diffStrategy?: DiffStrategy): string {
 	return instructions.join("\n")
 }
 
+function getGitWorkflowInstructions(): string {
+	return `- **GIT WORKFLOW REQUIREMENTS**: For all code-related tasks, you MUST follow proper git workflow:
+  * **Before Starting Task**: Always pull latest changes before beginning work:
+    - Pull latest changes: \`git pull\`
+  * **Initial Task Completion**: Before using attempt_completion, commit changes and create a PR:
+    - Check git status: \`git status\`
+    - Stage changes: \`git add .\`
+    - Commit with descriptive message: \`git commit -m "feat: [brief description]"\`
+    - Create and push to feature branch: \`git checkout -b otto/[task-name] && git push -u origin otto/[task-name]\`
+    - Create PR: \`gh pr create --title "[PR Title]" --body "[Description]"\` (if GitHub CLI available)
+  * **Subsequent Changes**: If user requests changes after PR creation:
+    - Make requested changes
+    - Commit: \`git add . && git commit -m "fix: [description of changes]"\`
+    - Push to existing branch: \`git push\`
+  * **Edge Cases**: Handle missing git repo (\`git init\`), missing remote, existing branches (\`git checkout [branch]\`), merge conflicts, and missing GitHub CLI
+  * **Branch Naming**: Use descriptive names like \`otto/feat/add-authentication\`, \`otto/fix/resolve-login-bug\`, \`otto/refactor/update-api\`
+  * **Commit Messages**: Use conventional format: \`type: description\` (feat, fix, docs, style, refactor, test, chore)`
+}
+
 export function getRulesSection(cwd: string, supportsComputerUse: boolean, diffStrategy?: DiffStrategy): string {
 	return `====
 
@@ -57,6 +76,7 @@ RULES
 - When using the search_files tool, craft your regex patterns carefully to balance specificity and flexibility. Based on the user's task you may use it to find code patterns, TODO comments, function definitions, or any text-based information across the project. The results include context, so analyze the surrounding code to better understand the matches. Leverage the search_files tool in combination with other tools for more comprehensive analysis. For example, use it to find specific code patterns, then use read_file to examine the full context of interesting matches before using ${diffStrategy ? "apply_diff or write_to_file" : "write_to_file"} to make informed changes.
 - When creating a new project (such as an app, website, or any software project), organize all new files within a dedicated project directory unless the user specifies otherwise. Use appropriate file paths when writing files, as the write_to_file tool will automatically create any necessary directories. Structure the project logically, adhering to best practices for the specific type of project being created. Unless otherwise specified, new projects should be easily run without additional setup, for example most projects can be built in HTML, CSS, and JavaScript - which you can open in a browser.
 ${getEditingInstructions(diffStrategy)}
+${getGitWorkflowInstructions()}
 - Some modes have restrictions on which files they can edit. If you attempt to edit a restricted file, the operation will be rejected with a FileRestrictionError that will specify which file patterns are allowed for the current mode.
 - Be sure to consider the type of project (e.g. Python, JavaScript, web application) when determining the appropriate structure and files to include. Also consider what files may be most relevant to accomplishing the task, for example looking at a project's manifest file would help you understand the project's dependencies, which you could incorporate into any code you write.
   * For example, in architect mode trying to edit app.js would be rejected because architect mode can only edit files matching "\\.md$"

src/core/prompts/tools/attempt-completion.ts

@@ -1,10 +1,48 @@
 export function getAttemptCompletionDescription(): string {
 	return `## attempt_completion
 Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
+
+GIT WORKFLOW REQUIREMENTS:
+When completing a task that involves code changes, you MUST follow this git workflow:
+
+0. **Before Starting Task**: Always pull latest changes before beginning work:
+   - Pull latest changes: \`git pull\`
+
+1. **Initial Task Completion**: After making all necessary changes and before using attempt_completion, commit your changes and create a pull request:
+   - Stage all changes: \`git add .\`
+   - Commit with a descriptive message: \`git commit -m "feat: [brief description of changes]"\`
+   - Push to a new feature branch: \`git push -u origin otto/feature/[task-description]\`
+   - Create a pull request: \`gh pr create --title "[PR Title]" --body "[PR Description]"\`
+
+2. **Subsequent Changes After PR**: If the user requests additional changes after the PR has been created:
+   - Make the requested changes
+   - Stage and commit: \`git add . && git commit -m "fix: [description of additional changes]"\`
+   - Push to the existing branch: \`git push\`
+   - Do NOT create a new PR - the existing PR will be updated automatically
+
+3. **Edge Cases to Handle**:
+   - If the branch already exists, switch to it: \`git checkout [branch-name]\`
+   - If there are merge conflicts, resolve them before proceeding
+   - If GitHub CLI is not available, provide manual instructions for creating PR
+   - If working on an existing PR branch, continue using that branch
+
+4. **Branch Naming Convention**:
+   - Use descriptive branch names: \`otto/feature/add-user-authentication\`, \`otto/fix/resolve-login-bug\`, \`otto/refactor/update-api-endpoints\`
+   - Keep branch names concise but meaningful
+
+5. **Commit Message Format**:
+   - Use conventional commit format: \`type: description\`
+   - Types: feat, fix, docs, style, refactor, test, chore
+   - Example: \`feat: add user authentication system\`
+
+IMPORTANT: Always execute the git commands using the execute_command tool before using attempt_completion. The git workflow is mandatory for all code-related tasks.
+
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
 - command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use \`open index.html\` to display a created html website, or \`open localhost:3000\` to display a locally running development server. But DO NOT use commands like \`echo\` or \`cat\` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
+
 Usage:
 <attempt_completion>
 <result>
@@ -16,7 +54,7 @@ Your final result description here
 Example: Requesting to attempt completion with a result and command
 <attempt_completion>
 <result>
-I've updated the CSS
+I've updated the CSS and committed the changes to a new feature branch. Created PR #123 for review.
 </result>
 <command>open index.html</command>
 </attempt_completion>`