[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EKGVVJHPXAR0PC0R8SS8Y8":3,"skill-same:01M6EKGVVJHPXAR0PC0R8SS8Y8":61},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":44,"ownerHtmlUrl":45,"ownerBlogUrl":6,"ownerDescription":46,"updatedAt":47,"install":48,"resources":60},"01M6EKGVVJHPXAR0PC0R8SS8Y8","resolve-backport-conflicts",null,"Resolve merge conflicts in a Mergify backport pull request. When a cherry-pick fails, Mergify commits the conflict markers as they are. This skill takes a pull request link or number as an argument.","Venkateshvenki404224\u002Fbenchpress","Venkateshvenki404224","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F75518037?v=4","01M6EKFVM5P6HRTJBSR8BABRJ2","Venkatesh","01M6EKFVRVS346Q492S7SASWTV",6,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002F.claude\u002Fskills\u002Fresolve-backport-conflicts\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"backport","conflicts","resolve backport conflicts","merge","pull request","pull","resolve merge conflicts","commits","pick","merge conflicts","conflict","as","link","markers","2026-11-10 10:12:30",false,"---\nname: resolve-backport-conflicts\ndescription: Resolve merge conflicts in a Mergify backport pull request. When a cherry-pick fails, Mergify commits the conflict markers as they are. This skill takes a pull request link or number as an argument.\ndisable-model-invocation: true\n---\n\n## How Mergify leaves the branch\n\nMergify backports a pull request with a cherry-pick. When the cherry-pick conflicts, Mergify runs `git add` on the conflicted files and commits them unresolved. The branch then holds raw conflict markers:\n\n```\n\u003C\u003C\u003C\u003C\u003C\u003C\u003C HEAD\ncontent of the target branch, such as version-16-hotfix\n=======\ncontent of the commit under backport\n>>>>>>> \u003Csha> (commit subject)\n```\n\nThe `HEAD` side is the target branch. The `>>>>>>>` side is the pull request under backport. Neither side wins by default.\n\n## Steps\n\n### 1. Check out the pull request\n\nWork inside the repository that owns the pull request. If the current directory is a different repository, clone the correct one into the scratchpad directory.\n\n```bash\ngh pr view \u003Cpr-url> --json number,title,body,baseRefName,headRefName,headRepositoryOwner,url\ngh pr checkout \u003Cpr-url> --force\n```\n\nThe `--force` flag resets a stale local branch to the pull request head. If the working tree is dirty, stop and tell the user. Do not discard the work of the user.\n\n### 2. Read the original pull request\n\nThe Mergify description holds the line `This is an automatic backport of pull request #\u003CN>`. Read the number from that line. If the line is absent, read the number from the branch name `mergify\u002Fbp\u002F\u003Cbranch>\u002Fpr-\u003CN>`.\n\n```bash\ngh pr view \u003CN> --json title,body,url\ngh pr diff \u003CN>\n```\n\nThis diff states the intent of the backport. Read all of it before you edit a file.\n\n### 3. Find every marker\n\n```bash\ngit grep -nE '^(\u003C{7}|={7}|>{7})' -- . || echo \"no markers\"\ngit diff HEAD~1 --stat\ngit log -1 --format=%s\n```\n\nThe last command confirms that `HEAD` is the conflict commit of Mergify. Look also for leftover `.rej` and `.orig` files.\n\n### 4. Resolve each conflict\n\n1. Read the code around the conflict until you know what it does on this branch.\n2. Start from the target branch side. It shows what the release branch holds today.\n3. Apply the change of the original pull request on top of that side.\n4. Drop every line that the diff of the original pull request does not contain.\n5. Delete the three marker lines.\n\nStep 4 matters most. A conflict hunk drags in unrelated work from later commits on the source branch. Renamed helpers, new APIs, and unrelated refactors arrive this way. None of them belong in a release branch.\n\nIf the backport needs a function or a module that the target branch does not have, do not write a replacement. Report the gap and ask the user how to continue.\n\nMergify also stages clean hunks that belong to other commits. To catch these, compare the whole conflict commit against the diff of the original pull request. Revert the hunks that do not match.\n\n### 5. Verify\n\n```bash\ngit grep -nE '^(\u003C{7}|={7}|>{7})' -- .\ngit diff HEAD\n```\n\nThe first command must print nothing. Read every line that the second command prints. Compare `git diff HEAD~1` against `gh pr diff \u003CN>`. Apart from branch differences, the two diffs must match.\n\nIf the repository has a linter or a formatter, run it on the files you changed.\n\n### 6. Commit and push\n\n```bash\ngit add \u003Cmodified files>\ngit commit -m \"chore: resolve conflict\"\ngit push \u003Cremote> HEAD:\u003CheadRefName>\n```\n\nTo choose the remote, match `headRepositoryOwner` from step 1 against the output of `git remote -v`. A Mergify branch lives on the upstream repository, not on a fork. Never force-push.\n\n### 7. Remove the `conflicts` label\n\nMergify adds a `conflicts` label when the cherry-pick fails. The label stays until someone removes it. After the push succeeds, and only if no marker remains, remove it:\n\n```bash\ngh pr edit \u003Cpr-url> --remove-label conflicts\n```\n\nThe command fails if the pull request does not carry the label. That failure is harmless. If you could not resolve every conflict, leave the label in place.\n\n### 8. Summarize\n\nReport these points to the user:\n\n1. The backport pull request and the original pull request.\n2. Each file that held a conflict, with one line on how you resolved it.\n3. Each change you dropped as unrelated, with the reason.\n4. Each conflict you could not resolve.\n5. The sha of the pushed commit.\n\nState the facts. If a resolution is a judgment call, say so.\n","## How Mergify leaves the branch\n\nMergify backports a pull request with a cherry-pick. When the cherry-pick conflicts, Mergify runs `git add` on the conflicted files and commits them unresolved. The branch then holds raw conflict markers:\n\n```\n\u003C\u003C\u003C\u003C\u003C\u003C\u003C HEAD\ncontent of the target branch, such as version-16-hotfix\n=======\ncontent of the commit under backport\n>>>>>>> \u003Csha> (commit subject)\n```\n\nThe `HEAD` side is the target branch. The `>>>>>>>` side is the pull request under backport. Neither side wins by default.\n\n## Steps\n\n### 1. Check out the pull request\n\nWork inside the repository that owns the pull request. If the current directory is a different repository, clone the correct one into the scratchpad directory.\n\n```bash\ngh pr view \u003Cpr-url> --json number,title,body,baseRefName,headRefName,headRepositoryOwner,url\ngh pr checkout \u003Cpr-url> --force\n```\n\nThe `--force` flag resets a stale local branch to the pull request head. If the working tree is dirty, stop and tell the user. Do not discard the work of the user.\n\n### 2. Read the original pull request\n\nThe Mergify description holds the line `This is an automatic backport of pull request #\u003CN>`. Read the number from that line. If the line is absent, read the number from the branch name `mergify\u002Fbp\u002F\u003Cbranch>\u002Fpr-\u003CN>`.\n\n```bash\ngh pr view \u003CN> --json title,body,url\ngh pr diff \u003CN>\n```\n\nThis diff states the intent of the backport. Read all of it before you edit a file.\n\n### 3. Find every marker\n\n```bash\ngit grep -nE '^(\u003C{7}|={7}|>{7})' -- . || echo \"no markers\"\ngit diff HEAD~1 --stat\ngit log -1 --format=%s\n```\n\nThe last command confirms that `HEAD` is the conflict commit of Mergify. Look also for leftover `.rej` and `.orig` files.\n\n### 4. Resolve each conflict\n\n1. Read the code around the conflict until you know what it does on this branch.\n2. Start from the target branch side. It shows what the release branch holds today.\n3. Apply the change of the original pull request on top of that side.\n4. Drop every line that the diff of the original pull request does not contain.\n5. Delete the three marker lines.\n\nStep 4 matters most. A conflict hunk drags in unrelated work from later commits on the source branch. Renamed helpers, new APIs, and unrelated refactors arrive this way. None of them belong in a release branch.\n\nIf the backport needs a function or a module that the target branch does not have, do not write a replacement. Report the gap and ask the user how to continue.\n\nMergify also stages clean hunks that belong to other commits. To catch these, compare the whole conflict commit against the diff of the original pull request. Revert the hunks that do not match.\n\n### 5. Verify\n\n```bash\ngit grep -nE '^(\u003C{7}|={7}|>{7})' -- .\ngit diff HEAD\n```\n\nThe first command must print nothing. Read every line that the second command prints. Compare `git diff HEAD~1` against `gh pr diff \u003CN>`. Apart from branch differences, the two diffs must match.\n\nIf the repository has a linter or a formatter, run it on the files you changed.\n\n### 6. Commit and push\n\n```bash\ngit add \u003Cmodified files>\ngit commit -m \"chore: resolve conflict\"\ngit push \u003Cremote> HEAD:\u003CheadRefName>\n```\n\nTo choose the remote, match `headRepositoryOwner` from step 1 against the output of `git remote -v`. A Mergify branch lives on the upstream repository, not on a fork. Never force-push.\n\n### 7. Remove the `conflicts` label\n\nMergify adds a `conflicts` label when the cherry-pick fails. The label stays until someone removes it. After the push succeeds, and only if no marker remains, remove it:\n\n```bash\ngh pr edit \u003Cpr-url> --remove-label conflicts\n```\n\nThe command fails if the pull request does not carry the label. That failure is harmless. If you could not resolve every conflict, leave the label in place.\n\n### 8. Summarize\n\nReport these points to the user:\n\n1. The backport pull request and the original pull request.\n2. Each file that held a conflict, with one line on how you resolved it.\n3. Each change you dropped as unrelated, with the reason.\n4. Each conflict you could not resolve.\n5. The sha of the pushed commit.\n\nState the facts. If a resolution is a judgment call, say so.\n",{"name":5,"description":7,"disable-model-invocation":38},true,"version-16","38e17b09d0a500b359ccf7abf4cc0557dcd605e4",".claude\u002Fskills\u002Fresolve-backport-conflicts",1,"https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress","https:\u002F\u002Fbenchpress.cloud","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224","🚀 Backend Engineer | 🧠 Open Source Contributor | ⚙️ Frappe & ERPNext Expert | 🔬 Lab Infra Builder | 👕 Founder @gemzy.in | 💡 Building Dev Tools","2026-11-09 02:43:13",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":38},[50,53,56],{"tool":51,"command":52},"npx","npx skills add Venkateshvenki404224\u002Fbenchpress --skill resolve-backport-conflicts",{"tool":54,"command":55},"bunx","bunx skills add Venkateshvenki404224\u002Fbenchpress --skill resolve-backport-conflicts",{"tool":57,"command":58},"pnpm","pnpm dlx skills add Venkateshvenki404224\u002Fbenchpress --skill resolve-backport-conflicts","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002F.claude\u002Fskills\u002Fresolve-backport-conflicts\u002FSKILL.md",[],[62,84,96,125,155,185],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":73,"publishedAt":33},"01M6EKHBJ8ZYV9E11T2RE35X4D","benchpress-docs","Read and search the BenchPress documentation. Use when working with BenchPress — its setup, configuration, API, and behavior.","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002Fdocs-site\u002F.well-known\u002Fagent-skills\u002Fbenchpress-docs\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[74,75,76,77,78,79,80,81,82,83],"benchpress docs","docs","api","read","behavior","use","search","configuration","setup","documentation",{"skillNo":85,"name":64,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":95,"publishedAt":33},"01M6EKH56APEWPT12654C9HG67","Read and search the benchpress documentation. Use when working with benchpress — its setup, configuration, API, and behavior.","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002Fdocs-bundle\u002FSKILL.md",[89,94],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[75,74,76,80,78,79,83,82,81,77],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":108,"publishedAt":33},"01M6EKH20VPHEBRS67AMARTJRV","ui-design","General UI\u002FUX judgment for layout, polish, visual hierarchy, spacing, typography, color, and accessibility. Use when no product-specific or Frappe-specific design system skill applies.","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002F.claude\u002Fskills\u002Fui-design\u002FSKILL.md",[102,105],{"categoryNo":103,"categoryName":104,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":106,"categoryName":107,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000032","设计师",[109,110,111,112,113,114,115,116,117,118,119,79,120,121,122,123,124],"design","ui","ui design","design system","system","polish","ux","product","accessibility","color","frappe","layout","judgment","visual","general","typography",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":138,"publishedAt":33},"01M6EKGYTRTQHD402K7BBJG669","technical-writing","Write prose in \"Simplified Technical English\". This applies to documentation, READMEs, commits, pull request, plans and release notes. It does not apply to code, identifiers, marketing copy, essays, or anything that needs a voice.","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002F.claude\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[131,134,135],{"categoryNo":132,"categoryName":133,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},{"categoryNo":136,"categoryName":137,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000036","内容创作者",[139,140,141,142,143,144,145,24,146,83,147,148,149,26,150,151,152,23,153,154],"technical","technical writing","writing","it","copy","simplified technical english","english","plans","write","voice","marketing","release","code","release notes","notes","prose",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":169,"publishedAt":33},"01M6EKGRAG062FCM7SA3303GWQ","quality-code-review","Review code for any Frappe application — a checklist distilled from years of engineering practice on correctness, security, performance, concurrency, readability, API design, and testing. Use this when reviewing a diff, a PR, or a piece of code for quality and security, or when you want a reviewer's checklist grounded in hard-won Frappe\u002FERPNext lessons.","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002F.claude\u002Fskills\u002Fquality-code-review\u002FSKILL.md",[161,164,167,168],{"categoryNo":162,"categoryName":163,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":165,"categoryName":166,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":103,"categoryName":104,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[170,171,172,151,173,174,175,176,109,177,178,119,179,180,181,79,182,183,76,184],"quality code review","quality code","quality","review","code review","performance","security","testing","pr","erpnext","readability","diff","reviewer","review code","concurrency",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":194,"publishedAt":33},"01M6EKGKNGNVHYJHZZ456N4DVW","issue-to-phases","Decompose a planning document (plan.md, a spec, or a GitHub issue) into incremental, independently-shippable \"tracer bullet\" phases, write them as phase specs under specs\u002F, and optionally generate a Ralph loop (ralph.sh + prompt.md) that implements them unattended. Use this whenever the user hands you a plan and wants it broken into phases, mentions \"tracer bullets\", \"phase 0\u002F1\u002F2\", \"build this in phases\", \"thin end-to-end slice first\", \"ralph loop\", or wants phased specs in the specs\u002F folder — even if they never say the word \"phase\". Also use it when the user asks to \"implement \u002F work on phase N\" of an existing spec folder, so the branch, the PR and the spec's status all move the way every earlier phase did.","https:\u002F\u002Fgithub.com\u002FVenkateshvenki404224\u002Fbenchpress\u002Fblob\u002Fversion-16\u002F.claude\u002Fskills\u002Fissue-to-phases\u002FSKILL.md",[191],{"categoryNo":192,"categoryName":193,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000002","文档处理",[195,196,197,30,198,199,200,79,147,201,202,203,204,205,206,207,208,209,178,210],"issue to phases","issue","broken","end","decompose","never","branch","work","ralph","Word","work on","plan","loop","planning","generate","status"]