[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S61VAFC58WA1NPRR8DYSN":3,"skill-same:01M71S61VAFC58WA1NPRR8DYSN":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71S61VAFC58WA1NPRR8DYSN","resolve-conflicts",null,"Use this skill immediately when the user mentions merge conflicts that need to be resolved. Do not attempt to resolve conflicts directly - invoke this skill first. This skill specializes in providing a structured framework for merging imports, tests, lock files (regeneration), configuration files, and handling deleted-but-modified files with backup and analysis.","justrach\u002Fcodegraff2","justrach","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54503978?v=4","01M71S58M9PP0QSMVY7GB4CYHR","Rach","01M71S58N3CYPB4BKRR47Q9KAF",28,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fresolve-conflicts\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"resolve conflicts","conflicts","configuration","first","backup","with","merge conflicts","use","tests","for","do","framework","but","merge","imports","lock","analysis","when","invoke","files","2026-11-10 13:02:02",false,"---\nname: resolve-conflicts\ndescription: Use this skill immediately when the user mentions merge conflicts that need to be resolved. Do not attempt to resolve conflicts directly - invoke this skill first. This skill specializes in providing a structured framework for merging imports, tests, lock files (regeneration), configuration files, and handling deleted-but-modified files with backup and analysis.\n---\n\n# Git Conflict Resolution\n\nResolve Git merge conflicts by intelligently combining changes from both branches while preserving the intent of both changes. This skill follows a plan-first approach: assess conflicts, create a detailed resolution plan, get approval, then execute.\n\n## Core Principles\n\n1. **Plan Before Executing**: Always create a structured resolution plan and get user approval before making changes\n2. **Prefer Both Changes**: Default to keeping both changes unless they directly contradict\n3. **Merge, Don't Choose**: Especially for imports, tests, and configuration\n4. **Regenerate Generated Files**: Never manually merge generated files - always regenerate them from their sources\n5. **Backup Before Resolving**: For deleted-modified files, create backups first\n6. **Validate with Tests**: Always run tests after resolution\n7. **Explain All Resolutions**: For each conflict resolved, provide a one-line explanation of the resolution strategy\n8. **Ask When Unclear**: When the correct resolution isn't clear from the diff, present options to the user and ask for their choice\n\n## Workflow\n\n### Step 1: Assess the Conflict Situation\n\nRun initial checks to understand the conflict scope:\n\n```bash\ngit status\n```\n\nIdentify and categorize all conflicted files:\n\n- Regular file conflicts (both modified)\n- Deleted-modified conflicts (one deleted, one modified)\n- Generated file conflicts (lock files, build artifacts, generated code)\n- Test file conflicts\n- Import\u002Fconfiguration conflicts\n- Binary file conflicts\n\nFor each conflicted file, gather information:\n\n- File type and purpose\n- Nature of the conflict (content, deletion, type change)\n- Scope of changes (lines changed, sections affected)\n- Whether the file is generated or hand-written\n\n### Step 2: Create Merge Resolution Plan\n\nBased on the assessment, create a structured plan before resolving any conflicts. Present the plan in the following markdown format:\n\n```markdown\n## Merge Resolution Plan\n\n### Conflict Summary\n\n- **Total conflicted files**: [N]\n- **Deleted-modified conflicts**: [N]\n- **Generated files**: [N]\n- **Regular conflicts**: [N]\n\n### Resolution Strategy by File\n\n#### 1. [File Path]\n\n**Conflict Type**: [deleted-modified \u002F generated \u002F imports \u002F tests \u002F code logic \u002F config \u002F struct \u002F binary]\n**Strategy**: [Brief description of resolution approach]\n**Rationale**: [Why this strategy is appropriate]\n**Risk**: [Low\u002FMedium\u002FHigh] - [Brief risk description]\n**Action Items**:\n\n- [ ] [Specific action 1]\n- [ ] [Specific action 2]\n\n#### 2. [File Path]\n\n...\n\n### Execution Order\n\n1. **Phase 1: Deleted-Modified Files** - Handle deletions and backups first\n2. **Phase 2: Generated Files** - Regenerate from source\n3. **Phase 3: Low-Risk Merges** - Imports, tests, documentation\n4. **Phase 4: High-Risk Merges** - Code logic, configuration, structs\n5. **Phase 5: Validation** - Compile, test, verify\n\n### Questions\u002FDecisions Needed\n\n- [ ] **[File\u002FDecision]**: [Question for user] (Options: 1, 2, 3)\n\n### Validation Steps\n\n- [ ] Run conflict validation script\n- [ ] Compile project\n- [ ] Run test suite\n- [ ] Manual verification of high-risk changes\n```\n\n**Present this plan to the user** and wait for their approval before proceeding with resolution. If there are any unclear conflicts where you need user input, list them in the \"Questions\u002FDecisions Needed\" section.\n\n**For a complete example plan**, see `references\u002Fsample-plan.md`.\n\n### Step 3: Handle Deleted-Modified Files\n\n**Execute this phase only after the plan is approved.**\n\nIf there are deleted-but-modified files (status: DU, UD, DD, UA, AU):\n\n```bash\n.forge\u002Fskills\u002Fresolve-conflicts\u002Fscripts\u002Fhandle-deleted-modified.sh\n```\n\nThis script will:\n\n- Create timestamped backups of modified content\n- Analyze potential relocation targets\n- Generate analysis reports for each file\n- Automatically resolve the deletion status\n\nReview the backup directory and analysis files to understand where changes should be applied.\n\n### Step 4: Execute Resolution Plan\n\n**Follow the execution order defined in your plan.** For each conflicted file, apply the appropriate resolution pattern according to your plan. **For every conflict you resolve, provide a one-line explanation** of how you're resolving it.\n\nAs you complete each action item in your plan, mark it as done and report progress to the user.\n\n#### When Resolution is Unclear\n\nWhen you cannot determine the correct resolution from the diff alone (these should already be listed in your plan's \"Questions\u002FDecisions Needed\" section):\n\n1. **Present the conflict** to the user with the conflicting code from both sides\n2. **Provide numbered options** for resolution (Option 1, Option 2, etc.)\n3. **Explain each option** clearly with what it would do\n4. **Ask the user to choose** an option number or provide additional information\n5. **Remember their choice** and apply similar reasoning to subsequent related conflicts\n\n**Example interaction:**\n\n```\nI found a conflict in src\u002Fmain.rs where both branches modify the `calculate_price` function:\n\n\u003C\u003C\u003C\u003C\u003C\u003C\u003C HEAD (Current Branch)\nfn calculate_price(item: &Item) -> f64 {\n    item.base_price * (1.0 + item.tax_rate)\n}\n=======\nfn calculate_price(item: &Item) -> f64 {\n    item.base_price + item.tax_amount\n}\n>>>>>>> feature-branch (Incoming Branch)\n\nI'm not sure which calculation is correct. Please select an option:\n\n**Option 1**: Keep current branch (multiplies base_price by tax_rate)\n**Option 2**: Keep incoming branch (adds tax_amount to base_price)\n**Option 3**: Keep both approaches with a new parameter\n**Option 4**: Provide more context to help me decide\n\nPlease respond with \"Option 1\", \"Option 2\", \"Option 3\", or \"Option 4\", or provide additional information.\n```\n\nOnce the user responds, apply their decision and similar logic to related conflicts.\n\n#### Resolution Patterns\n\nFor each conflicted file, apply the appropriate resolution pattern:\n\n#### Imports\u002FDependencies\n\n**Goal**: Merge all unique imports from both branches.\n\n**One-line explanation**: \"Merging imports by combining unique imports from both branches, removing duplicates, and grouping by module.\"\n\nRead `references\u002Fpatterns.md` section \"Import Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Extract all imports from both sides\n2. Remove duplicates\n3. Group by module\u002Fpackage\n4. Follow language-specific style (alphabetize, group std\u002Fexternal\u002Finternal)\n\n#### Tests\n\n**Goal**: Include all test cases and test data from both branches.\n\n**One-line explanation**: \"Merging tests by including all test cases from both branches, combining fixtures, and renaming if necessary to avoid conflicts.\"\n\nRead `references\u002Fpatterns.md` section \"Test Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Keep all test functions unless they test the exact same thing\n2. Merge test fixtures and setup functions\n3. Combine assertions from both sides\n4. If test names conflict but test different behaviors, rename to clarify\n\n#### Generated Files\n\n**Goal**: Regenerate any generated files to include changes from both branches.\n\n**One-line explanation**: \"Resolving generated file by regenerating it from source files to incorporate changes from both branches.\"\n\n**Recognition**: A file is generated if it:\n\n- Is produced by a build tool, compiler, or code generator\n- Has a source file or configuration that defines it\n- Contains headers\u002Fcomments indicating it's auto-generated\n- Is listed in `.gitattributes` as generated\n- Common examples: lock files, protobuf outputs, GraphQL schema files, compiled assets, auto-generated docs\n\n**Approach:**\n\n1. **Identify the generation source**: Determine what command or tool generates the file\n2. **Choose either version** temporarily (doesn't matter which):\n\n   ```bash\n   git checkout --ours \u003Cgenerated-file>    # or --theirs\n   ```\n\n3. **Regenerate from source**: Run the appropriate generation command:\n\n   ```bash\n   # Package manager lock files\n   cargo update                       # for Cargo.lock\n   npm install                        # for package-lock.json\n   yarn install                       # for yarn.lock\n   bundle install                     # for Gemfile.lock\n   poetry lock --no-update            # for poetry.lock\n\n   # Code generation\n   protoc ...                         # for protobuf files\n   graphql-codegen                    # for GraphQL generated code\n   make generate                      # for Makefile-based generation\n   npm run generate                   # for npm script-based generation\n\n   # Build artifacts\n   npm run build                      # for compiled\u002Fbundled assets\n   cargo build                        # for Rust build artifacts\n   ```\n\n4. **Stage the regenerated file**:\n   ```bash\n   git add \u003Cgenerated-file>\n   ```\n\n**When unsure if a file is generated**: Check for auto-generation markers in the file header, or ask the user if you should regenerate or manually merge the file.\n\n#### Configuration Files\n\n**Goal**: Merge configuration values from both branches.\n\n**One-line explanation**: \"Merging configuration by including all keys from both branches and choosing appropriate values for conflicts.\"\n\nRead `references\u002Fpatterns.md` section \"Configuration File Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Include all keys from both sides\n2. For conflicting values, choose based on:\n   - Newer\u002Fmore recent value\n   - Safer\u002Fmore conservative value\n   - Production requirements\n3. Document choice in commit message\n\n**When unclear**: Ask the user which configuration value to prefer (current vs incoming)\n\n#### Code Logic\n\n**Goal**: Understand intent of both changes and combine if possible.\n\n**One-line explanation**: \"Resolving code logic by analyzing intent: merging if changes are orthogonal, or choosing one approach if they conflict.\"\n\nRead `references\u002Fpatterns.md` section \"Code Logic Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Analyze what each branch is trying to achieve\n2. If changes are orthogonal (different concerns), merge both\n3. If changes conflict (same concern, different approach):\n   - Review commit messages\u002FPRs for context\n   - Choose the approach that matches requirements\n   - Test both approaches if unclear\n   - Document the decision\n\n**When unclear**: Present both approaches as options to the user with context about what each does\n\n#### Struct\u002FType Definitions\n\n**Goal**: Include all fields from both branches.\n\n**One-line explanation**: \"Merging struct by including all fields from both branches and choosing appropriate types for any conflicting field definitions.\"\n\n**Quick approach:**\n\n1. Merge all fields\n2. If field types conflict, analyze which is more appropriate\n3. Fix all compilation errors from updated struct\n4. Update tests to use new fields\n\n**When unclear**: Ask the user which type definition is correct if field types conflict\n\n### Step 5: Validate Resolution\n\nAfter completing all resolution phases in your plan, validate that all conflicts are resolved:\n\n```bash\n.forge\u002Fskills\u002Fresolve-conflicts\u002Fscripts\u002Fvalidate-conflicts.sh\n```\n\nThis script checks for:\n\n- Remaining conflict markers (\u003C\u003C\u003C\u003C\u003C\u003C\u003C, =======, >>>>>>>)\n- Unmerged paths in git status\n- Deleted-modified conflicts\n- Merge state files\n\n### Step 6: Compile and Test\n\nBuild and test to ensure the resolution is correct (as defined in your plan's validation steps):\n\n```bash\n# For Rust projects\ncargo test\n\n# For other projects, use appropriate test command\n# npm test\n# pytest\n# etc.\n```\n\nIf tests fail:\n\n1. Review the failure - is it from merged code or conflict resolution?\n2. Check if both branches' tests pass individually\n3. Fix integration issues between the merged changes\n4. Re-run tests until all pass\n\n### Step 7: Finalize\n\nOnce all conflicts are resolved and tests pass, review your completed plan and commit:\n\n```bash\n# Review the changes\ngit diff --cached\n\n# Commit with descriptive message that references the plan\ngit commit -m \"Resolve merge conflicts: [describe key decisions]\n\nExecuted merge resolution plan:\n- [Phase 1 summary]\n- [Phase 2 summary]\n- [Phase 3+ summaries]\n\nKey decisions:\n- Merged imports from both branches\n- Combined test cases\n- Regenerated lock files\n- [other significant decisions from plan]\n\nCo-Authored-By: ForgeCode \u003Cnoreply@forgecode.dev>\"\n```\n\n## Decision Tracking\n\nWhen you ask the user to choose between options, track their decision and apply similar reasoning to subsequent conflicts:\n\n**Example scenario:**\n\n1. First conflict: User chooses Option 1 (prefer current branch's validation logic)\n2. Second similar conflict: Apply the same reasoning (prefer current branch's validation approach)\n3. Mention: \"Resolving by keeping current branch's approach (consistent with your earlier choice)\"\n\n**Key principles:**\n\n- Remember user preferences within the same conflict resolution session\n- Apply consistent patterns when conflicts are similar\n- Mention the consistency: \"Following the same pattern as before...\"\n- Ask again if a new conflict is sufficiently different from previous ones\n\n## Common Patterns Reference\n\nFor detailed resolution patterns, read:\n\n- `references\u002Fpatterns.md` - Comprehensive examples for all conflict types\n\n**Quick pattern lookup:**\n\n- **Imports**: Combine all unique imports, group by module\n- **Tests**: Keep all tests unless identical, merge fixtures\n- **Generated files**: Choose either version, regenerate from source\n- **Config**: Merge all keys, choose newer\u002Fsafer values for conflicts\n- **Code**: Analyze intent, merge if orthogonal, choose one if conflicting\n- **Structs**: Include all fields from both branches\n- **Docs**: Combine all documentation sections\n\n## Special Scenarios\n\n### Binary Files in Conflict\n\nBinary files cannot be merged. Choose one version:\n\n```bash\ngit checkout --ours path\u002Fto\u002Fbinary    # keep our version\n# or\ngit checkout --theirs path\u002Fto\u002Fbinary  # keep their version\n```\n\n### Mass Rename\u002FRefactoring Conflicts\n\nIf one branch renamed\u002Frefactored many files while another modified them:\n\n1. Accept the rename\u002Frefactoring (structural change)\n2. Apply the modifications to the new structure\n3. Use backups from `handle-deleted-modified.sh` to guide the application\n\n### Submodule Conflicts\n\n```bash\n# Check submodule status\ngit submodule status\n\n# Update to the correct commit\ncd path\u002Fto\u002Fsubmodule\ngit checkout \u003Cdesired-commit>\ncd ..\u002F..\ngit add path\u002Fto\u002Fsubmodule\n```\n\n## Troubleshooting\n\n### \"Both Added\" Conflicts (AA)\n\nBoth branches added a new file with the same name but different content:\n\n1. Review both versions\n2. If they serve the same purpose, merge their content\n3. If they serve different purposes, rename one\n\n### Whitespace-Only Conflicts\n\nIf conflicts are only whitespace differences:\n\n```bash\ngit merge -Xignore-space-change \u003Cbranch>\n```\n\n### Persistent Conflict Markers\n\nIf validation shows conflict markers but you think you resolved them:\n\n1. Search for the exact marker strings: `git grep -n \"\u003C\u003C\u003C\u003C\u003C\u003C\u003C HEAD\"`\n2. Some markers might be in strings or comments - resolve those too\n3. Check for hidden characters or encoding issues\n\n### Tests Fail After Resolution\n\n1. Test each branch individually to confirm they pass\n2. The failure is likely from interaction between the merged changes\n3. Debug the interaction issue, not the individual changes\n4. Update code to make both changes work together\n\n## Quick Reference Card\n\n| Conflict Type    | Strategy                                | One-line Explanation Template                                                                                    |\n| ---------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |\n| Imports          | Merge all, deduplicate, group by module | \"Merging imports by combining unique imports from both branches and grouping by module\"                          |\n| Tests            | Keep all, merge fixtures                | \"Including all test cases from both branches and combining test fixtures\"                                        |\n| Generated files  | Regenerate from source                  | \"Regenerating [file] from source to include changes from both branches\"                                          |\n| Config           | Merge keys, choose newer values         | \"Merging all config keys and choosing [current\u002Fincoming] value for [key]\"                                        |\n| Code logic       | Analyze intent, merge if orthogonal     | \"Merging both changes as they address different concerns\" OR \"Choosing [current\u002Fincoming] approach for [reason]\" |\n| Structs          | Include all fields                      | \"Including all fields from both branches in struct definition\"                                                   |\n| Docs             | Combine all sections                    | \"Combining documentation from both branches\"                                                                     |\n| Deleted-modified | Backup, analyze, apply to new location  | \"Applying modifications to new location after file was moved\u002Frenamed\"                                            |\n| Binary files     | Choose one version                      | \"Keeping [current\u002Fincoming] version of binary file\"                                                              |\n\n**Remember:**\n\n- Always provide a one-line explanation for each conflict resolution\n- When unclear, present numbered options to the user\n- Track user decisions and apply consistently to similar conflicts\n- The goal is to preserve the intent and functionality of both branches while creating a cohesive merged result\n","# Git Conflict Resolution\n\nResolve Git merge conflicts by intelligently combining changes from both branches while preserving the intent of both changes. This skill follows a plan-first approach: assess conflicts, create a detailed resolution plan, get approval, then execute.\n\n## Core Principles\n\n1. **Plan Before Executing**: Always create a structured resolution plan and get user approval before making changes\n2. **Prefer Both Changes**: Default to keeping both changes unless they directly contradict\n3. **Merge, Don't Choose**: Especially for imports, tests, and configuration\n4. **Regenerate Generated Files**: Never manually merge generated files - always regenerate them from their sources\n5. **Backup Before Resolving**: For deleted-modified files, create backups first\n6. **Validate with Tests**: Always run tests after resolution\n7. **Explain All Resolutions**: For each conflict resolved, provide a one-line explanation of the resolution strategy\n8. **Ask When Unclear**: When the correct resolution isn't clear from the diff, present options to the user and ask for their choice\n\n## Workflow\n\n### Step 1: Assess the Conflict Situation\n\nRun initial checks to understand the conflict scope:\n\n```bash\ngit status\n```\n\nIdentify and categorize all conflicted files:\n\n- Regular file conflicts (both modified)\n- Deleted-modified conflicts (one deleted, one modified)\n- Generated file conflicts (lock files, build artifacts, generated code)\n- Test file conflicts\n- Import\u002Fconfiguration conflicts\n- Binary file conflicts\n\nFor each conflicted file, gather information:\n\n- File type and purpose\n- Nature of the conflict (content, deletion, type change)\n- Scope of changes (lines changed, sections affected)\n- Whether the file is generated or hand-written\n\n### Step 2: Create Merge Resolution Plan\n\nBased on the assessment, create a structured plan before resolving any conflicts. Present the plan in the following markdown format:\n\n```markdown\n## Merge Resolution Plan\n\n### Conflict Summary\n\n- **Total conflicted files**: [N]\n- **Deleted-modified conflicts**: [N]\n- **Generated files**: [N]\n- **Regular conflicts**: [N]\n\n### Resolution Strategy by File\n\n#### 1. [File Path]\n\n**Conflict Type**: [deleted-modified \u002F generated \u002F imports \u002F tests \u002F code logic \u002F config \u002F struct \u002F binary]\n**Strategy**: [Brief description of resolution approach]\n**Rationale**: [Why this strategy is appropriate]\n**Risk**: [Low\u002FMedium\u002FHigh] - [Brief risk description]\n**Action Items**:\n\n- [ ] [Specific action 1]\n- [ ] [Specific action 2]\n\n#### 2. [File Path]\n\n...\n\n### Execution Order\n\n1. **Phase 1: Deleted-Modified Files** - Handle deletions and backups first\n2. **Phase 2: Generated Files** - Regenerate from source\n3. **Phase 3: Low-Risk Merges** - Imports, tests, documentation\n4. **Phase 4: High-Risk Merges** - Code logic, configuration, structs\n5. **Phase 5: Validation** - Compile, test, verify\n\n### Questions\u002FDecisions Needed\n\n- [ ] **[File\u002FDecision]**: [Question for user] (Options: 1, 2, 3)\n\n### Validation Steps\n\n- [ ] Run conflict validation script\n- [ ] Compile project\n- [ ] Run test suite\n- [ ] Manual verification of high-risk changes\n```\n\n**Present this plan to the user** and wait for their approval before proceeding with resolution. If there are any unclear conflicts where you need user input, list them in the \"Questions\u002FDecisions Needed\" section.\n\n**For a complete example plan**, see `references\u002Fsample-plan.md`.\n\n### Step 3: Handle Deleted-Modified Files\n\n**Execute this phase only after the plan is approved.**\n\nIf there are deleted-but-modified files (status: DU, UD, DD, UA, AU):\n\n```bash\n.forge\u002Fskills\u002Fresolve-conflicts\u002Fscripts\u002Fhandle-deleted-modified.sh\n```\n\nThis script will:\n\n- Create timestamped backups of modified content\n- Analyze potential relocation targets\n- Generate analysis reports for each file\n- Automatically resolve the deletion status\n\nReview the backup directory and analysis files to understand where changes should be applied.\n\n### Step 4: Execute Resolution Plan\n\n**Follow the execution order defined in your plan.** For each conflicted file, apply the appropriate resolution pattern according to your plan. **For every conflict you resolve, provide a one-line explanation** of how you're resolving it.\n\nAs you complete each action item in your plan, mark it as done and report progress to the user.\n\n#### When Resolution is Unclear\n\nWhen you cannot determine the correct resolution from the diff alone (these should already be listed in your plan's \"Questions\u002FDecisions Needed\" section):\n\n1. **Present the conflict** to the user with the conflicting code from both sides\n2. **Provide numbered options** for resolution (Option 1, Option 2, etc.)\n3. **Explain each option** clearly with what it would do\n4. **Ask the user to choose** an option number or provide additional information\n5. **Remember their choice** and apply similar reasoning to subsequent related conflicts\n\n**Example interaction:**\n\n```\nI found a conflict in src\u002Fmain.rs where both branches modify the `calculate_price` function:\n\n\u003C\u003C\u003C\u003C\u003C\u003C\u003C HEAD (Current Branch)\nfn calculate_price(item: &Item) -> f64 {\n    item.base_price * (1.0 + item.tax_rate)\n}\n=======\nfn calculate_price(item: &Item) -> f64 {\n    item.base_price + item.tax_amount\n}\n>>>>>>> feature-branch (Incoming Branch)\n\nI'm not sure which calculation is correct. Please select an option:\n\n**Option 1**: Keep current branch (multiplies base_price by tax_rate)\n**Option 2**: Keep incoming branch (adds tax_amount to base_price)\n**Option 3**: Keep both approaches with a new parameter\n**Option 4**: Provide more context to help me decide\n\nPlease respond with \"Option 1\", \"Option 2\", \"Option 3\", or \"Option 4\", or provide additional information.\n```\n\nOnce the user responds, apply their decision and similar logic to related conflicts.\n\n#### Resolution Patterns\n\nFor each conflicted file, apply the appropriate resolution pattern:\n\n#### Imports\u002FDependencies\n\n**Goal**: Merge all unique imports from both branches.\n\n**One-line explanation**: \"Merging imports by combining unique imports from both branches, removing duplicates, and grouping by module.\"\n\nRead `references\u002Fpatterns.md` section \"Import Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Extract all imports from both sides\n2. Remove duplicates\n3. Group by module\u002Fpackage\n4. Follow language-specific style (alphabetize, group std\u002Fexternal\u002Finternal)\n\n#### Tests\n\n**Goal**: Include all test cases and test data from both branches.\n\n**One-line explanation**: \"Merging tests by including all test cases from both branches, combining fixtures, and renaming if necessary to avoid conflicts.\"\n\nRead `references\u002Fpatterns.md` section \"Test Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Keep all test functions unless they test the exact same thing\n2. Merge test fixtures and setup functions\n3. Combine assertions from both sides\n4. If test names conflict but test different behaviors, rename to clarify\n\n#### Generated Files\n\n**Goal**: Regenerate any generated files to include changes from both branches.\n\n**One-line explanation**: \"Resolving generated file by regenerating it from source files to incorporate changes from both branches.\"\n\n**Recognition**: A file is generated if it:\n\n- Is produced by a build tool, compiler, or code generator\n- Has a source file or configuration that defines it\n- Contains headers\u002Fcomments indicating it's auto-generated\n- Is listed in `.gitattributes` as generated\n- Common examples: lock files, protobuf outputs, GraphQL schema files, compiled assets, auto-generated docs\n\n**Approach:**\n\n1. **Identify the generation source**: Determine what command or tool generates the file\n2. **Choose either version** temporarily (doesn't matter which):\n\n   ```bash\n   git checkout --ours \u003Cgenerated-file>    # or --theirs\n   ```\n\n3. **Regenerate from source**: Run the appropriate generation command:\n\n   ```bash\n   # Package manager lock files\n   cargo update                       # for Cargo.lock\n   npm install                        # for package-lock.json\n   yarn install                       # for yarn.lock\n   bundle install                     # for Gemfile.lock\n   poetry lock --no-update            # for poetry.lock\n\n   # Code generation\n   protoc ...                         # for protobuf files\n   graphql-codegen                    # for GraphQL generated code\n   make generate                      # for Makefile-based generation\n   npm run generate                   # for npm script-based generation\n\n   # Build artifacts\n   npm run build                      # for compiled\u002Fbundled assets\n   cargo build                        # for Rust build artifacts\n   ```\n\n4. **Stage the regenerated file**:\n   ```bash\n   git add \u003Cgenerated-file>\n   ```\n\n**When unsure if a file is generated**: Check for auto-generation markers in the file header, or ask the user if you should regenerate or manually merge the file.\n\n#### Configuration Files\n\n**Goal**: Merge configuration values from both branches.\n\n**One-line explanation**: \"Merging configuration by including all keys from both branches and choosing appropriate values for conflicts.\"\n\nRead `references\u002Fpatterns.md` section \"Configuration File Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Include all keys from both sides\n2. For conflicting values, choose based on:\n   - Newer\u002Fmore recent value\n   - Safer\u002Fmore conservative value\n   - Production requirements\n3. Document choice in commit message\n\n**When unclear**: Ask the user which configuration value to prefer (current vs incoming)\n\n#### Code Logic\n\n**Goal**: Understand intent of both changes and combine if possible.\n\n**One-line explanation**: \"Resolving code logic by analyzing intent: merging if changes are orthogonal, or choosing one approach if they conflict.\"\n\nRead `references\u002Fpatterns.md` section \"Code Logic Conflicts\" for detailed examples.\n\n**Quick approach:**\n\n1. Analyze what each branch is trying to achieve\n2. If changes are orthogonal (different concerns), merge both\n3. If changes conflict (same concern, different approach):\n   - Review commit messages\u002FPRs for context\n   - Choose the approach that matches requirements\n   - Test both approaches if unclear\n   - Document the decision\n\n**When unclear**: Present both approaches as options to the user with context about what each does\n\n#### Struct\u002FType Definitions\n\n**Goal**: Include all fields from both branches.\n\n**One-line explanation**: \"Merging struct by including all fields from both branches and choosing appropriate types for any conflicting field definitions.\"\n\n**Quick approach:**\n\n1. Merge all fields\n2. If field types conflict, analyze which is more appropriate\n3. Fix all compilation errors from updated struct\n4. Update tests to use new fields\n\n**When unclear**: Ask the user which type definition is correct if field types conflict\n\n### Step 5: Validate Resolution\n\nAfter completing all resolution phases in your plan, validate that all conflicts are resolved:\n\n```bash\n.forge\u002Fskills\u002Fresolve-conflicts\u002Fscripts\u002Fvalidate-conflicts.sh\n```\n\nThis script checks for:\n\n- Remaining conflict markers (\u003C\u003C\u003C\u003C\u003C\u003C\u003C, =======, >>>>>>>)\n- Unmerged paths in git status\n- Deleted-modified conflicts\n- Merge state files\n\n### Step 6: Compile and Test\n\nBuild and test to ensure the resolution is correct (as defined in your plan's validation steps):\n\n```bash\n# For Rust projects\ncargo test\n\n# For other projects, use appropriate test command\n# npm test\n# pytest\n# etc.\n```\n\nIf tests fail:\n\n1. Review the failure - is it from merged code or conflict resolution?\n2. Check if both branches' tests pass individually\n3. Fix integration issues between the merged changes\n4. Re-run tests until all pass\n\n### Step 7: Finalize\n\nOnce all conflicts are resolved and tests pass, review your completed plan and commit:\n\n```bash\n# Review the changes\ngit diff --cached\n\n# Commit with descriptive message that references the plan\ngit commit -m \"Resolve merge conflicts: [describe key decisions]\n\nExecuted merge resolution plan:\n- [Phase 1 summary]\n- [Phase 2 summary]\n- [Phase 3+ summaries]\n\nKey decisions:\n- Merged imports from both branches\n- Combined test cases\n- Regenerated lock files\n- [other significant decisions from plan]\n\nCo-Authored-By: ForgeCode \u003Cnoreply@forgecode.dev>\"\n```\n\n## Decision Tracking\n\nWhen you ask the user to choose between options, track their decision and apply similar reasoning to subsequent conflicts:\n\n**Example scenario:**\n\n1. First conflict: User chooses Option 1 (prefer current branch's validation logic)\n2. Second similar conflict: Apply the same reasoning (prefer current branch's validation approach)\n3. Mention: \"Resolving by keeping current branch's approach (consistent with your earlier choice)\"\n\n**Key principles:**\n\n- Remember user preferences within the same conflict resolution session\n- Apply consistent patterns when conflicts are similar\n- Mention the consistency: \"Following the same pattern as before...\"\n- Ask again if a new conflict is sufficiently different from previous ones\n\n## Common Patterns Reference\n\nFor detailed resolution patterns, read:\n\n- `references\u002Fpatterns.md` - Comprehensive examples for all conflict types\n\n**Quick pattern lookup:**\n\n- **Imports**: Combine all unique imports, group by module\n- **Tests**: Keep all tests unless identical, merge fixtures\n- **Generated files**: Choose either version, regenerate from source\n- **Config**: Merge all keys, choose newer\u002Fsafer values for conflicts\n- **Code**: Analyze intent, merge if orthogonal, choose one if conflicting\n- **Structs**: Include all fields from both branches\n- **Docs**: Combine all documentation sections\n\n## Special Scenarios\n\n### Binary Files in Conflict\n\nBinary files cannot be merged. Choose one version:\n\n```bash\ngit checkout --ours path\u002Fto\u002Fbinary    # keep our version\n# or\ngit checkout --theirs path\u002Fto\u002Fbinary  # keep their version\n```\n\n### Mass Rename\u002FRefactoring Conflicts\n\nIf one branch renamed\u002Frefactored many files while another modified them:\n\n1. Accept the rename\u002Frefactoring (structural change)\n2. Apply the modifications to the new structure\n3. Use backups from `handle-deleted-modified.sh` to guide the application\n\n### Submodule Conflicts\n\n```bash\n# Check submodule status\ngit submodule status\n\n# Update to the correct commit\ncd path\u002Fto\u002Fsubmodule\ngit checkout \u003Cdesired-commit>\ncd ..\u002F..\ngit add path\u002Fto\u002Fsubmodule\n```\n\n## Troubleshooting\n\n### \"Both Added\" Conflicts (AA)\n\nBoth branches added a new file with the same name but different content:\n\n1. Review both versions\n2. If they serve the same purpose, merge their content\n3. If they serve different purposes, rename one\n\n### Whitespace-Only Conflicts\n\nIf conflicts are only whitespace differences:\n\n```bash\ngit merge -Xignore-space-change \u003Cbranch>\n```\n\n### Persistent Conflict Markers\n\nIf validation shows conflict markers but you think you resolved them:\n\n1. Search for the exact marker strings: `git grep -n \"\u003C\u003C\u003C\u003C\u003C\u003C\u003C HEAD\"`\n2. Some markers might be in strings or comments - resolve those too\n3. Check for hidden characters or encoding issues\n\n### Tests Fail After Resolution\n\n1. Test each branch individually to confirm they pass\n2. The failure is likely from interaction between the merged changes\n3. Debug the interaction issue, not the individual changes\n4. Update code to make both changes work together\n\n## Quick Reference Card\n\n| Conflict Type    | Strategy                                | One-line Explanation Template                                                                                    |\n| ---------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |\n| Imports          | Merge all, deduplicate, group by module | \"Merging imports by combining unique imports from both branches and grouping by module\"                          |\n| Tests            | Keep all, merge fixtures                | \"Including all test cases from both branches and combining test fixtures\"                                        |\n| Generated files  | Regenerate from source                  | \"Regenerating [file] from source to include changes from both branches\"                                          |\n| Config           | Merge keys, choose newer values         | \"Merging all config keys and choosing [current\u002Fincoming] value for [key]\"                                        |\n| Code logic       | Analyze intent, merge if orthogonal     | \"Merging both changes as they address different concerns\" OR \"Choosing [current\u002Fincoming] approach for [reason]\" |\n| Structs          | Include all fields                      | \"Including all fields from both branches in struct definition\"                                                   |\n| Docs             | Combine all sections                    | \"Combining documentation from both branches\"                                                                     |\n| Deleted-modified | Backup, analyze, apply to new location  | \"Applying modifications to new location after file was moved\u002Frenamed\"                                            |\n| Binary files     | Choose one version                      | \"Keeping [current\u002Fincoming] version of binary file\"                                                              |\n\n**Remember:**\n\n- Always provide a one-line explanation for each conflict resolution\n- When unclear, present numbered options to the user\n- Track user decisions and apply consistently to similar conflicts\n- The goal is to preserve the intent and functionality of both branches while creating a cohesive merged result\n",{"name":5,"description":7},"main","e5610ede9cf38ac3bd71d5f984fa8936f21539d3",".forge\u002Fskills\u002Fresolve-conflicts",3,"https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff","https:\u002F\u002Fgithub.com\u002Fjustrach","https:\u002F\u002Fjustrach.com","2026-06-12 16:28:22",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add justrach\u002Fcodegraff2 --skill resolve-conflicts",{"tool":59,"command":60},"bunx","bunx skills add justrach\u002Fcodegraff2 --skill resolve-conflicts",{"tool":62,"command":63},"pnpm","pnpm dlx skills add justrach\u002Fcodegraff2 --skill resolve-conflicts","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fresolve-conflicts\u002FSKILL.md",true,[67,73,77,83],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fpatterns.md","REFERENCE","参考文档",10070,"https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fresolve-conflicts\u002Freferences\u002Fpatterns.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fsample-plan.md",3273,"https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fresolve-conflicts\u002Freferences\u002Fsample-plan.md",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"scripts\u002Fhandle-deleted-modified.sh","SCRIPT","脚本",5786,"https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fresolve-conflicts\u002Fscripts\u002Fhandle-deleted-modified.sh",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"scripts\u002Fvalidate-conflicts.sh",3102,"https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fresolve-conflicts\u002Fscripts\u002Fvalidate-conflicts.sh",[88,114,136,162,176,186],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":39},"01M71S6QW9FHPKR0VMCG0B9W4A","github-pr-description","Generate and create pull request descriptions automatically using GitHub CLI. Use when the user asks to create a PR, generate a PR description, make a pull request, or submit changes for review. Analyzes git diff and commit history to create comprehensive, meaningful PR descriptions that explain what changed, why it matters, and how to test it.","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002Fcrates\u002Fforge_repo\u002Fsrc\u002Fskills\u002Fgithub-pr-description\u002FSKILL.md",[],[95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,36,113],"github pr description","pr","pr description","github pr","github","review","git","request","why","how","make","generate","cli","github cli","create","submit","using github","how to","commit",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":39},"01M71S6P2MSFVC7HXGBW96MZYN","execute-plan","Execute structured task plans with status tracking. Use when the user provides a plan file path in the format `plans\u002F{current-date}-{task-name}-{version}.md` or explicitly asks you to execute a plan file.","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002Fcrates\u002Fforge_repo\u002Fsrc\u002Fskills\u002Fexecute-plan\u002FSKILL.md",[],[121,122,123,124,125,126,127,128,129,36,130,26,131,132,133,134,24,135],"execute","execute plan","plan","task","structured","user","file","version","you","tracking","plans","status","format","name","path",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":147,"publishedAt":39},"01M71S6J9VMWAHRD34KY0324DD","create-skill","Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends your capabilities with specialized knowledge, workflows, or tool integrations.","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002Fcrates\u002Fforge_repo\u002Fsrc\u002Fskills\u002Fcreate-skill\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[109,148,149,150,151,152,28,153,154,155,156,24,157,158,36,159,160,161],"create skill","update","users","Existing","tool","integrations","existing skill","guide","new skill","capabilities","specialized","workflows","new","knowledge",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":39},"01M71S6GG2QN728FSQQ0QB6HQ5","test-skill","A test skill with resources","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002Fcrates\u002Fforge_repo\u002Fsrc\u002Ffixtures\u002Fskills_with_resources\u002Ftest-skill\u002FSKILL.md",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},[173,174,24,175],"test","Test Skill","resources",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":183,"publishedAt":39},"01M71S6FMADGSKZTNRSWFKJSSG","minimal-skill","A minimal skill with no resources","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002Fcrates\u002Fforge_repo\u002Fsrc\u002Ffixtures\u002Fskills_with_resources\u002Fminimal-skill\u002FSKILL.md",[182],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},[184,185,175,24],"minimal skill","minimal",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":39},"01M71S6CGWXEWRQR5C0P6J1WE4","write-release-notes","Generate engaging, high-energy release notes for a given version tag. Fetches the release from GitHub, retrieves every linked PR's title and description, then synthesizes all changes into a polished, user-facing release note with an enthusiastic tone. Use when the user asks to write, generate, or create release notes for a version (e.g. \"write release notes for v1.32.0\", \"generate release notes for the latest release\", \"create changelog for v2.0\").","https:\u002F\u002Fgithub.com\u002Fjustrach\u002Fcodegraff2\u002Fblob\u002Fmain\u002F.forge\u002Fskills\u002Fwrite-release-notes\u002FSKILL.md",[],[193,194,195,196,197,198,199,200,201,202,109,24,128,203,36,26,204,28,96,205],"release notes","notes","release","write","write release notes","tone","changes","energy","title","changelog","v1","high-energy","create release"]