feat: Add pre-commit review and PR template to issue-fixer-orchestrator (#5405)

* feat: Add pre-commit review and PR template to issue-fixer-orchestrator

- Add user confirmation step before committing changes
- Handle large diffs (>2000 lines) with summary generation
- Save PR message to temp directory instead of creating PR directly
- Implement exact Roo Code PR template format
- Add post-commit options for flexible PR creation
- Update best practices and communication guidelines
- Document new commit and PR workflow patterns

* removed files that were added accidently

.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml

@@ -0,0 +1,213 @@
+<pr_template_format>
+  <overview>
+    This document defines the format for PR messages that are saved to the temp folder
+    before creating a pull request. The PR message is saved in two formats:
+    1. JSON format in pr_summary.json (for programmatic use)
+    2. Markdown format in pr_message.md (for manual PR creation)
+    
+    The PR message must follow the exact Roo Code contribution template.
+  </overview>
+
+  <json_format>
+    <description>
+      The pr_summary.json file contains the PR title and body in a structured format
+      that can be easily parsed by scripts and the GitHub CLI.
+    </description>
+    <structure>
+      {
+        "title": "fix: [description] (#[issue-number])",
+        "body": "[Full markdown body as described below]",
+        "issue_number": 123,
+        "repo_owner": "owner",
+        "repo_name": "repo",
+        "base_branch": "main",
+        "head_branch": "fix/issue-123-description"
+      }
+    </structure>
+  </json_format>
+
+  <markdown_format>
+    <description>
+      The pr_message.md file contains the complete PR message in a format that can be
+      directly copied and pasted when creating a PR manually.
+    </description>
+    <structure>
+      PR Title: [title from JSON]
+      
+      ---
+      
+      [Full PR body from JSON]
+    </structure>
+  </markdown_format>
+
+  <pr_body_template>
+    <description>
+      The PR body must follow this exact Roo Code PR template with all required sections.
+    </description>
+    <template><![CDATA[
+<!--
+Thank you for contributing to Roo Code!
+
+Before submitting your PR, please ensure:
+- It's linked to an approved GitHub Issue.
+- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
+-->
+
+### Related GitHub Issue
+
+<!-- Every PR MUST be linked to an approved issue. -->
+
+Closes: #[ISSUE_NUMBER] <!-- Replace with the issue number, e.g., Closes: #123 -->
+
+### Roo Code Task Context (Optional)
+
+<!--
+If you used Roo Code to help create this PR, you can share public task links here.
+This helps reviewers understand your development process and provides additional context.
+Example: https://app.roocode.com/share/task-id
+-->
+
+[TASK_CONTEXT]
+
+### Description
+
+<!--
+Briefly summarize the changes in this PR and how they address the linked issue.
+The issue should cover the "what" and "why"; this section should focus on:
+- The "how": key implementation details, design choices, or trade-offs made.
+- Anything specific reviewers should pay attention to in this PR.
+-->
+
+[DESCRIPTION_CONTENT]
+
+### Test Procedure
+
+<!--
+Detail the steps to test your changes. This helps reviewers verify your work.
+- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
+- How can reviewers reproduce your tests or verify the fix/feature?
+- Include relevant testing environment details if applicable.
+-->
+
+[TEST_PROCEDURE_CONTENT]
+
+### Pre-Submission Checklist
+
+<!-- Go through this checklist before marking your PR as ready for review. -->
+
+- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
+- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
+- [x] **Self-Review**: I have performed a thorough self-review of my code.
+- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
+- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
+- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
+
+### Screenshots / Videos
+
+<!--
+For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
+This greatly helps in understanding the visual impact of your changes.
+-->
+
+[SCREENSHOTS_CONTENT]
+
+### Documentation Updates
+
+<!--
+Does this PR necessitate updates to user-facing documentation?
+- [ ] No documentation updates are required.
+- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
+-->
+
+[DOCUMENTATION_UPDATES_CONTENT]
+
+### Additional Notes
+
+<!-- Add any other context, questions, or information for reviewers here. -->
+
+[ADDITIONAL_NOTES_CONTENT]
+
+### Get in Touch
+
+<!--
+Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
+-->
+
+[DISCORD_USERNAME]
+    ]]></template>
+  </pr_body_template>
+
+  <template_placeholders>
+    <placeholder name="[ISSUE_NUMBER]">The GitHub issue number being fixed</placeholder>
+    <placeholder name="[TASK_CONTEXT]">Optional Roo Code task links (remove section if not applicable)</placeholder>
+    <placeholder name="[DESCRIPTION_CONTENT]">
+      Summary of changes and implementation details. Should include:
+      - Key implementation details
+      - Design choices or trade-offs made
+      - Specific areas reviewers should focus on
+    </placeholder>
+    <placeholder name="[TEST_PROCEDURE_CONTENT]">
+      Detailed testing steps including:
+      - Unit tests added/modified
+      - Manual testing steps performed
+      - How reviewers can reproduce tests
+      - Testing environment details
+    </placeholder>
+    <placeholder name="[SCREENSHOTS_CONTENT]">
+      For UI changes: before/after screenshots or video
+      For non-UI changes: "N/A - No UI changes"
+    </placeholder>
+    <placeholder name="[DOCUMENTATION_UPDATES_CONTENT]">
+      Check appropriate box:
+      - "- [x] No documentation updates are required." OR
+      - "- [x] Yes, documentation updates are required. [describe updates]"
+    </placeholder>
+    <placeholder name="[ADDITIONAL_NOTES_CONTENT]">
+      Any additional context, or remove entire section if not needed
+    </placeholder>
+    <placeholder name="[DISCORD_USERNAME]">User's Discord username for contact</placeholder>
+  </template_placeholders>
+
+  <file_locations>
+    <file>
+      <name>pr_summary.json</name>
+      <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json</path>
+      <purpose>Structured data for programmatic PR creation</purpose>
+    </file>
+    <file>
+      <name>pr_message.md</name>
+      <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
+      <purpose>Human-readable format for manual PR creation</purpose>
+    </file>
+  </file_locations>
+
+  <usage_guidelines>
+    <guideline>
+      Always save both formats when preparing a PR to give users flexibility
+      in how they create the pull request.
+    </guideline>
+    <guideline>
+      The pr_message.md file should be self-contained and ready to copy/paste
+      without any additional formatting needed.
+    </guideline>
+    <guideline>
+      Include all sections in the template, maintaining the exact format
+      and HTML comments as shown.
+    </guideline>
+    <guideline>
+      Pre-check all checklist items that can be verified programmatically.
+      Leave documentation checkbox unchecked for user to decide.
+    </guideline>
+    <guideline>
+      For sections that don't apply, use appropriate placeholder text
+      rather than removing the section entirely.
+    </guideline>
+  </usage_guidelines>
+
+  <translation_handling>
+    <note>
+      If translations were added during the issue fix, include details in the
+      Description section about which languages were updated.
+    </note>
+  </translation_handling>
+</pr_template_format>

.roo/rules-issue-fixer-orchestrator/1_Workflow.xml

@@ -347,32 +347,59 @@
         <message>
           **Task: Prepare Pull Request Title and Body**
 
-          You are an expert at writing clear and concise pull request summaries.
+          You are an expert at writing clear and concise pull request summaries following the Roo Code contribution guidelines.
 
           **Context Files:**
           - **Issue**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
           - **Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
           - **Verification**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`
           - **Translation Summary** (if exists): `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`
+          - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
 
           **Your Task:**
           1.  **Read all context files.** Check if translation_summary.md exists to know if translations were done.
+          
           2.  **Generate a PR Title**: Create a conventional commit style title (e.g., "fix: ...", "feat: ...") that references the issue number.
-          3.  **Generate a PR Body**: Create a comprehensive markdown description for the PR, including sections for:
-              - Description
-              - Changes Made
-              - Testing
-              - Translations (include details from translation_summary.md if it exists)
-              - Verification of Acceptance Criteria
-              - Checklist
-          4.  **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format: `{"title": "...", "body": "..."}`.
-
-          **Important**: If translations were done (translation_summary.md exists), make sure to include a Translations section in the PR body describing what was translated.
+              Format: `fix: Brief description (#issue-number)`
+          
+          3.  **Generate a PR Body**: You MUST use the exact PR template from `.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml`.
+              Read this file to get the template and fill it in with appropriate content from the context files.
+          
+          4.  **Fill in the template** with information from the context files:
+              - Replace [ISSUE_NUMBER] with the actual issue number
+              - Fill in Description with implementation details from the plan and verification
+              - Fill in Test Procedure with testing details from verification_results.md
+              - If translations were done, mention them in the Description section
+              - For UI changes, note that screenshots should be added manually
+              - Pre-check all applicable checklist items
+              - Leave Documentation Updates unchecked for user to decide
+              - For Discord username, use a placeholder like "[Your Discord username]"
+
+          5.  **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format:
+              ```json
+              {
+                "title": "fix: Brief description (#123)",
+                "body": "[The complete filled PR body template]",
+                "issue_number": 123,
+                "repo_owner": "owner",
+                "repo_name": "repo",
+                "base_branch": "main",
+                "head_branch": "fix/issue-123-description"
+              }
+              ```
+
+          6.  **Also save as Markdown**: Save just the PR body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md` for easy copying.
+
+          **Important Notes:**
+          - Use the EXACT template format from 10_pr_template_format.xml
+          - Keep all HTML comments in the template
+          - Pre-check items that can be verified programmatically
+          - Fill in all sections appropriately based on the context files
 
           **Completion Protocol:**
           - This is your only task. Do not deviate.
-          - Upon successfully saving `pr_summary.json`, you MUST use the `attempt_completion` tool.
-          - The `result` MUST be a concise confirmation, e.g., "PR summary created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json."
+          - Upon successfully saving both `pr_summary.json` and `pr_message.md`, you MUST use the `attempt_completion` tool.
+          - The `result` MUST be a concise confirmation, e.g., "PR summary and message created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/"
           - These instructions override any conflicting mode-specific guidelines.
         </message>
       </new_task>
@@ -560,53 +587,287 @@
   </step>
 
   <step number="10">
-    <name>Prepare Branch and Present PR Template</name>
+    <name>Prepare Branch and Review Changes</name>
     <instructions>
-      This step prepares the branch and commits, then presents the PR template to the user for confirmation before creating the actual pull request.
-
-      1. Read Issue Context for Issue Number:
-         Use read_file to get the issue context from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json
+      This step prepares the branch, reviews the changes, and gets user confirmation before committing.
+
+      1. Read Issue Context and PR Summary:
+         - Read issue context from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json
+         - Read PR summary from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json
+
+      2. Create Branch:
+         Extract issue number from context and create appropriate branch:
+         <execute_command>
+         <command>
+         # Extract issue number from context
+         ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
+         # Determine branch type based on labels or title
+         BRANCH_NAME="fix/issue-${ISSUE_NUM}-solution"
+         git checkout -b $BRANCH_NAME
+         </command>
+         </execute_command>
+
+      3. Review Files to be Committed:
+         a. Read the modified files list:
+            <read_file>
+            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json</path>
+            </read_file>
+         
+         b. Check git status to ensure only intended files are staged:
+            <execute_command>
+            <command>git status --porcelain</command>
+            </execute_command>
+         
+         c. Stage only the files from modified_files.json:
+            <execute_command>
+            <command>
+            # Stage only the files we actually modified
+            cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | while read file; do
+              if [ -f "$file" ]; then
+                git add "$file"
+              fi
+            done
+            # Show what will be committed
+            git status --short
+            </command>
+            </execute_command>
+
+      4. Generate and Save Merge Diff:
+         <execute_command>
+         <command>
+         # Generate diff of staged changes
+         git diff --cached > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff
+         # Count lines in diff
+         LINE_COUNT=$(wc -l < .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff)
+         echo "Diff contains $LINE_COUNT lines"
+         
+         # If diff is too large, create a summary instead
+         if [ $LINE_COUNT -gt 2000 ]; then
+           echo "Creating summary due to large diff size..."
+           git diff --cached --stat > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
+           git diff --cached --name-status >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
+           echo -e "\n\nNote: Full diff exceeds 2000 lines. Showing summary only." >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
+         fi
+         </command>
+         </execute_command>
+
+      5. Save PR Message to File:
+         Read the PR summary and save the formatted PR message:
+         <execute_command>
+         <command>
+         # Extract title and body from pr_summary.json
+         PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
+         PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
+         
+         # Save PR message to file
+         echo "PR Title: $PR_TITLE" > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
+         echo -e "\n---\n" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
+         echo "$PR_BODY" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
+         
+         echo "PR message saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
+         </command>
+         </execute_command>
 
-      2. Git Operations - Create branch and commit changes:
-         - Create a new branch: feat/issue-[number] or fix/issue-[number]
-         - Selectively add only the applicable files to the git stage
-         - Commit the staged changes
-         - Push the new branch to the remote repository
+      6. Present Changes for User Confirmation:
+         Read the diff (or summary) and PR message, then ask for confirmation:
          
-         Use execute_command with:
-         BRANCH_NAME="fix/issue-[issue_number]-solution"
-         git checkout -b $BRANCH_NAME
-         cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | xargs git add
-         git commit -m "[PR Title]"
-         git push -u origin $BRANCH_NAME
+         a. Read the appropriate diff file:
+            <read_file>
+            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff</path>
+            </read_file>
+            OR (if summary exists):
+            <read_file>
+            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt</path>
+            </read_file>
+         
+         b. Read the PR message:
+            <read_file>
+            <path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
+            </read_file>
+         
+         c. Ask for user confirmation:
+            <ask_followup_question>
+            <question>
+              I've prepared the changes for commit. Here's what will be included:
+
+              **Files to be committed:**
+              [List files from modified_files.json]
+
+              **Changes summary:**
+              [Include diff or summary content]
+
+              **Proposed PR message:**
+              [Include PR message content]
+
+              How would you like to proceed?
+            </question>
+            <follow_up>
+              <suggest>Looks good, go ahead and commit the changes</suggest>
+              <suggest>I tested the changes, and something is wrong - let me explain...</suggest>
+              <suggest>I still need to test the changes manually before committing</suggest>
+              <suggest>I want to modify the PR message before proceeding</suggest>
+              <suggest>Cancel this task</suggest>
+            </follow_up>
+            </ask_followup_question>
 
-      3. Present PR Template - Instead of creating the PR automatically, present the standardized PR template to the user:
-         Use ask_followup_question to ask: "The branch has been created and changes have been committed. I have prepared a standardized PR template for this issue. Would you like me to create the pull request using the standard Roo Code PR template, or would you prefer to make changes first?"
+      7. Handle User Decision:
+         Based on user response:
          
-         Provide these options:
-         - Yes, create the pull request with the standard template
-         - No, I want to make changes to the implementation first
-         - No, I want to customize the PR template before creating it
-         - Cancel the task
-
-      4. Handle User Decision:
-         If user chooses to create the PR: Use gh CLI to create the pull request with the standard template
-         If user chooses to make changes: Launch a rework subtask using new_task with code mode
-         If user wants to customize the template: Ask for their preferred PR title and body
-
-      5. Link to Issue - After PR creation, comment on the original issue with the PR link using gh issue comment
+         **If "Looks good, go ahead and commit":**
+         - Proceed to commit and push:
+           <execute_command>
+           <command>
+           # Get PR title for commit message
+           PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
+           git commit -m "$PR_TITLE"
+           git push -u origin $(git branch --show-current)
+           </command>
+           </execute_command>
+         - Continue to next step
+         
+         **If "something is wrong":**
+         - Ask for details about the issue
+         - Launch a fix subtask in code mode to address the problems
+         - Return to Step 5 (Verify and Test) after fixes
+         
+         **If "need to test manually":**
+         - Inform user that changes are staged but not committed
+         - Provide instructions for testing
+         - Wait for user to confirm testing is complete
+         
+         **If "modify PR message":**
+         - Ask for the new PR title and body
+         - Update pr_summary.json with new content
+         - Return to step 5 of this workflow
+         
+         **If "cancel":**
+         - Clean up staged changes and branch
+         - End workflow
     </instructions>
   </step>
 
   <step number="11">
-    <name>Monitor PR Checks and Cleanup</name>
+    <name>Finalize and Create PR</name>
     <instructions>
-      After creating the PR (if created), monitor the CI checks and then clean up the temporary files.
+      After user confirmation and successful commit, finalize the process.
+
+      1. Verify Push Success:
+         <execute_command>
+         <command>
+         # Verify the branch was pushed
+         git branch -r | grep $(git branch --show-current)
+         # Get the remote URL for PR creation
+         git remote get-url origin
+         </command>
+         </execute_command>
+
+      2. Present Final PR Creation Options:
+         <ask_followup_question>
+         <question>
+           The changes have been committed and pushed to the branch. The PR message has been saved to:
+           `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md`
+
+           You can now:
+           1. Create the PR manually using the saved message
+           2. Let me create the PR automatically
+           3. Make additional changes before creating the PR
+
+           What would you like to do?
+         </question>
+         <follow_up>
+           <suggest>Create the PR automatically using the saved message</suggest>
+           <suggest>I'll create the PR manually - just show me the branch name</suggest>
+           <suggest>I want to make more changes first</suggest>
+         </follow_up>
+         </ask_followup_question>
+
+      3. Handle Final Decision:
+         
+         **If "Create PR automatically":**
+         - Read PR details and create:
+           <execute_command>
+           <command>
+           # Extract PR details
+           PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
+           PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
+           ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
+           
+           # Create PR
+           gh pr create --title "$PR_TITLE" --body "$PR_BODY" --base main
+           
+           # Get PR number and link to issue
+           PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
+           gh issue comment $ISSUE_NUM --body "PR #$PR_NUM has been created to address this issue."
+           </command>
+           </execute_command>
+         
+         **If "Create manually":**
+         - Show branch name and location of PR message:
+           <execute_command>
+           <command>
+           echo "Branch name: $(git branch --show-current)"
+           echo "PR message saved at: .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
+           echo "You can copy the PR message from the file above when creating the PR."
+           </command>
+           </execute_command>
+         
+         **If "Make more changes":**
+         - Inform user they can continue working on the branch
+         - Provide the task directory location for reference
+
+      4. Cleanup:
+         Ask if user wants to clean up the temporary files:
+         <ask_followup_question>
+         <question>
+           Would you like me to clean up the temporary task files now, or keep them for reference?
+         </question>
+         <follow_up>
+           <suggest>Yes, clean up the temporary files</suggest>
+           <suggest>No, keep the files for now</suggest>
+         </follow_up>
+         </ask_followup_question>
+         
+         If yes, clean up:
+         <execute_command>
+         <command>rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]</command>
+         </execute_command>
+    </instructions>
+  </step>
+
+  <step number="12">
+    <name>Monitor PR (Optional)</name>
+    <instructions>
+      If a PR was created automatically, offer to monitor its status.
+
+      1. Check if PR exists:
+         <execute_command>
+         <command>
+         # Check if there's a PR for the current branch
+         BRANCH=$(git branch --show-current)
+         gh pr list --head $BRANCH --json number,state,checks
+         </command>
+         </execute_command>
+
+      2. If PR exists, offer monitoring:
+         <ask_followup_question>
+         <question>
+           Would you like me to monitor the PR checks and CI status?
+         </question>
+         <follow_up>
+           <suggest>Yes, monitor the PR checks</suggest>
+           <suggest>No, I'll check it myself</suggest>
+         </follow_up>
+         </ask_followup_question>
+
+      3. If user wants monitoring:
+         <execute_command>
+         <command>
+         PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
+         echo "Monitoring PR #$PR_NUM checks..."
+         gh pr checks $PR_NUM --watch
+         </command>
+         </execute_command>
 
-      1. Monitor Checks - Use gh pr checks with --watch to monitor CI status in real-time
-      2. Report Status - Inform the user of the final status of the checks
-      3. Cleanup - Remove the temporary task directory using rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]
-      
       This concludes the orchestration workflow.
     </instructions>
   </step>

.roo/rules-issue-fixer-orchestrator/2_best_practices.xml

@@ -24,6 +24,46 @@
     - Adding translations to all supported language files
     - Ensuring consistency with existing terminology
     - Maintaining sync across all language resources
+  
+  <commit_and_pr_best_practices>
+    <principle>Always verify files before committing</principle>
+    <guidelines>
+      - Review git status to ensure only intended files are staged
+      - Stage only files listed in modified_files.json
+      - Never commit unrelated changes or temporary files
+      - Always get user confirmation before committing
+    </guidelines>
+    
+    <diff_management>
+      - Save full diff to staged_changes.diff for review
+      - If diff exceeds 2000 lines, create a summary instead
+      - Summary should include file stats and change types
+      - Always inform user when showing summary vs full diff
+    </diff_management>
+    
+    <pr_message_handling>
+      - Save PR message in both JSON and Markdown formats
+      - pr_summary.json for programmatic use
+      - pr_message.md for manual PR creation
+      - Include all standard template sections
+      - Make PR message self-contained and ready to use
+    </pr_message_handling>
+    
+    <user_confirmation_flow>
+      - Always ask for confirmation with clear options
+      - First option should be "Looks good, go ahead"
+      - Provide options for testing and issue reporting
+      - Allow PR message modification before proceeding
+      - Handle each user response appropriately
+    </user_confirmation_flow>
+    
+    <temp_file_management>
+      - All delegated tasks must save outputs to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/
+      - Keep all context files until user confirms cleanup
+      - Offer cleanup option after PR creation
+      - Never delete files without user permission
+    </temp_file_management>
+  </commit_and_pr_best_practices>
   <codebase_exploration_guidelines>
     <principle>Always use `codebase_search` FIRST to understand the codebase structure and find all related files before using other tools like `read_file`.</principle>
     

.roo/rules-issue-fixer-orchestrator/3_common_patterns.xml

@@ -18,4 +18,21 @@
     7. Add comprehensive tests
     8. Update documentation
   </feature_implementation_pattern>
+  
+  <commit_and_pr_pattern>
+    1. Review git status to identify all changes
+    2. Stage only files from modified_files.json
+    3. Generate diff for review (full or summary based on size)
+    4. Create PR message and save to temp directory
+    5. Present changes to user for confirmation
+    6. Handle user response:
+       - If approved: commit and proceed to PR options
+       - If issues found: return to implementation
+       - If manual testing needed: wait for user
+    7. After commit, offer PR creation options:
+       - Create PR automatically
+       - Save PR message for manual creation
+       - Skip PR creation
+    8. Optionally monitor PR and offer cleanup
+  </commit_and_pr_pattern>
 </common_patterns>

.roo/rules-issue-fixer-orchestrator/7_communication_style.xml

@@ -8,4 +8,20 @@
   - Inform the user when delegating to translate mode
   - Include translation status in progress updates
   - Mention in PR description if translations were added
+  
+  <pre_commit_communication>
+    - Clearly list all files that will be committed
+    - Explain when showing a summary vs full diff (>2000 lines)
+    - Provide file statistics for large diffs
+    - Mention that PR message has been saved to temp directory
+    - Offer clear options for user to proceed or report issues
+  </pre_commit_communication>
+  
+  <post_commit_communication>
+    - Confirm successful commit with commit hash
+    - Explain PR creation options clearly
+    - Mention that PR message is saved and ready to use
+    - Provide path to PR message file for manual creation
+    - Offer cleanup option after PR is created
+  </post_commit_communication>
 </communication_style>