[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CP7PX89VYPA1FBJH119YFN":3,"skill-same:01M6CP7PX89VYPA1FBJH119YFN":66},{"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":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6CP7PX89VYPA1FBJH119YFN","dsh-merging-stacked-prs",null,"Use when landing a stack of dependent GitHub PRs (A ← B ← C, where each bases on the one below) onto master, merging a PR whose base is another open PR's branch, or whenever a request mentions \"stacked PRs\", \"PR stack\", \"dependent PRs\", or merging several related PRs in sequence. Requires every same-repository dependency chain to use GitHub's official stacked-PR feature before landing so GitHub owns stack-wide rules, CI, ordering, retargeting, and merge state.","gccszs\u002FWorldSoul","gccszs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F85680574?v=4","01M6CP73CSF9QGSTGE0NMMX8WV","cris_tofu","01M6CP73H2C65X28TS1NATXRZT",2,"MIT","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002F.agents\u002Fskills\u002Fdsh-merging-stacked-prs\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"dsh merging stacked prs","stacked prs","stack","base","master","bases","dependency","use","landing","branch","Rules","github","open","ci","repository","open pr","state","pr","official","merge","2026-11-10 10:12:30",false,"---\nname: dsh-merging-stacked-prs\ndescription: Use when landing a stack of dependent GitHub PRs (A ← B ← C, where each bases on the one below) onto master, merging a PR whose base is another open PR's branch, or whenever a request mentions \"stacked PRs\", \"PR stack\", \"dependent PRs\", or merging several related PRs in sequence. Requires every same-repository dependency chain to use GitHub's official stacked-PR feature before landing so GitHub owns stack-wide rules, CI, ordering, retargeting, and merge state.\n---\n\n# Landing an official GitHub PR stack\n\nLand dependent PRs through GitHub's native stack object and `gh stack merge`. Do not reproduce stack semantics by merging and retargeting individual PRs with `gh pr merge` and `gh pr edit`. The root [AGENTS.md](..\u002F..\u002F..\u002FAGENTS.md) owns the allowed merge-forward and rebase histories; the [stack review guide](..\u002F..\u002F..\u002Fdocs\u002Fcookbook\u002Fresponding-to-pr-review-on-a-stack.md) owns review-fix propagation.\n\n## Require native stack support\n\nRun `gh stack --version` before changing GitHub state. Hard-stop if the official extension or server-side stack feature is unavailable; do not fall back to manually merging and retargeting PRs one at a time. GitHub stacks require every head branch to live in the same repository, so hard-stop on a cross-fork chain.\n\nUse a clean dedicated worktree. Fetch current PR metadata and exact head OIDs rather than trusting branch names or an earlier report:\n\n```sh\ngh pr view \u003Cpr> --json number,author,baseRefName,baseRefOid,headRefName,headRefOid,isCrossRepository,state,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup\n```\n\nQuery `PullRequest.stack` and `stackEntry.position` for at least one PR in each apparent chain; this official GitHub object, not base-branch inference alone, is the stack-membership authority. Paginate `entries` when `size` exceeds the returned page:\n\n```sh\ngh api graphql -F owner=\u003Cowner> -F name=\u003Crepo> -F number=\u003Cpr> -f query='\nquery($owner: String!, $name: String!, $number: Int!) {\n  repository(owner: $owner, name: $name) {\n    pullRequest(number: $number) {\n      number\n      author { login }\n      baseRefName\n      headRefName\n      stackEntry { position }\n      stack {\n        number\n        baseRefName\n        size\n        entries(first: 100) {\n          nodes {\n            position\n            pullRequest { number author { login } baseRefName headRefName state isDraft }\n          }\n        }\n      }\n    }\n  }\n}'\n```\n\nEstablish the expected bottom-to-top order from the live PR bases: the bottom targets the trunk, and each higher PR targets the head branch immediately below it.\n\n## Link missing stack members\n\nFirst compare any existing stack entries with the expected chain. One existing stack may contain an order-preserving subset of the requested chain; multiple stack numbers, an unexpected entry, or a conflicting order requires user direction before any mutation.\n\nWhen any dependent PR is not yet in that official stack:\n\n1. Compare every `author.login` exactly.\n2. If all authors match, link the chain automatically in bottom-to-top order:\n\n```sh\ngh stack link --base \u003Ctrunk> \u003Cbottom-pr> \u003Cnext-pr> ... \u003Ctop-pr>\n```\n\n3. If authors differ or any author is unavailable, ask the user whether to link before changing GitHub state.\n4. Re-query GraphQL and require one stack number, the expected trunk, the complete PR set, and the expected positions and base chain.\n\nNever dissolve, reorder, or rebuild an existing stack automatically; `gh stack link` is additive and merged or queued entries cannot be unstacked.\n\n## Refresh only when needed\n\nDo not rewrite branches merely because a refresh mechanism exists. When the live merge state or repository rules require an updated trunk, choose either allowed history:\n\n- **Native cascading rebase:** check out the remote stack with `gh stack checkout \u003Cpr-or-stack>` when it is not tracked locally, then run `gh stack sync`. The command may rebase and lease-protected force-push every active layer before local validation. Immediately inspect the rewritten scope, run the relevant checks for every affected layer, and do not merge or claim readiness until they pass. If sync detects a rebase conflict, use `gh stack rebase`, resolve and validate it, then publish with `gh stack push`. If checkout or sync reports divergent local and remote stack compositions, cancel and ask rather than deleting or recreating the remote stack automatically.\n- **Incremental merge-forward:** merge the trunk into the bottom affected branch, then propagate each updated parent into its child in bottom-to-top order and push normally. If the base advances during an in-progress merge, preserve that checkpoint before merging the newer tip as specified by the [incremental-retargeting note](..\u002F..\u002Fnotes\u002Fimplemented\u002Fprocess\u002F2026-07-26-incremental-pr-base-retargeting.md).\n\nAny history rewrite is allowed after review, but it invalidates commit-OID assumptions. Re-fetch exact heads and re-audit unresolved review threads, approvals, mergeability, and checks after the push. Never use raw `--force` or overwrite a concurrently advanced remote head.\n\n## Preflight the merge range\n\nRe-query the official stack immediately before merging. Require every selected PR to be open, non-draft, in the expected order, and compliant with the repository's review and check requirements. Treat each PR's state independently; a ready top layer does not prove its dependencies are ready.\n\n\"Land the stack\" selects the whole stack. A partial landing requires an explicit boundary PR and includes every layer from the bottom through that boundary.\n\n## Merge through the stack API\n\nMerge the whole stack by its official stack number:\n\n```sh\ngh stack merge \u003Cstack-number> --yes --merge\n```\n\nFor an explicitly requested partial landing, merge through the boundary PR:\n\n```sh\ngh stack merge \u003Cboundary-pr> --yes --merge\n```\n\nDo not pass `--delete-branch`, manually retarget dependents, or issue per-PR merge commands. GitHub merges the selected range bottom-up and retargets\u002Frebases any remaining upper layers. A direct stack merge is all-or-nothing; when the trunk uses a merge queue, GitHub queues the selected range together but may land it in separate groups.\n\nDo not bypass merge requirements. If the native merge reports a blocker, inspect and resolve that blocker through the owning PR or stop and report it; never fall back to `gh pr merge`.\n\n## Verify the landed state\n\nWait for every selected PR to report `MERGED`; a queued request is not a completed landing:\n\n```sh\ngh pr view \u003Cpr> --json number,state,mergedAt,mergeCommit,baseRefName,headRefName\n```\n\nFor a partial landing, re-query the official stack and verify that every remaining PR is still linked in the expected order and targets the stack trunk or the layer below it. Re-check current heads, review state, and CI because GitHub may have rebased the remaining layers.\n\nDelete branches only in a separate final pass after the corresponding PRs report `MERGED`. Before deleting each branch, require GitHub to report no open PR still using it as a base:\n\n```sh\ngh pr list --state open --base \u003Cbranch> --json number --jq length\n```\n\nAnything other than `0` blocks deletion.\n\n## Checklist\n\n- [ ] Native `gh stack` support is available; every PR branch is in the same repository.\n- [ ] Live PR bases and exact heads establish one bottom-to-top dependency chain.\n- [ ] GraphQL reports one official stack with the expected trunk, entries, and order; an eligible same-author unstacked chain was linked automatically.\n- [ ] Any rewritten layers passed relevant validation, and review threads, approvals, mergeability, and checks were re-audited afterward.\n- [ ] The whole stack, or an explicitly bounded prefix, was submitted through `gh stack merge --yes --merge`.\n- [ ] Every selected PR reports `MERGED`; any remaining upper layers still form the expected official stack.\n- [ ] Branch deletion happened only after merged-state and zero-dependent verification.\n","# Landing an official GitHub PR stack\n\nLand dependent PRs through GitHub's native stack object and `gh stack merge`. Do not reproduce stack semantics by merging and retargeting individual PRs with `gh pr merge` and `gh pr edit`. The root [AGENTS.md](..\u002F..\u002F..\u002FAGENTS.md) owns the allowed merge-forward and rebase histories; the [stack review guide](..\u002F..\u002F..\u002Fdocs\u002Fcookbook\u002Fresponding-to-pr-review-on-a-stack.md) owns review-fix propagation.\n\n## Require native stack support\n\nRun `gh stack --version` before changing GitHub state. Hard-stop if the official extension or server-side stack feature is unavailable; do not fall back to manually merging and retargeting PRs one at a time. GitHub stacks require every head branch to live in the same repository, so hard-stop on a cross-fork chain.\n\nUse a clean dedicated worktree. Fetch current PR metadata and exact head OIDs rather than trusting branch names or an earlier report:\n\n```sh\ngh pr view \u003Cpr> --json number,author,baseRefName,baseRefOid,headRefName,headRefOid,isCrossRepository,state,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup\n```\n\nQuery `PullRequest.stack` and `stackEntry.position` for at least one PR in each apparent chain; this official GitHub object, not base-branch inference alone, is the stack-membership authority. Paginate `entries` when `size` exceeds the returned page:\n\n```sh\ngh api graphql -F owner=\u003Cowner> -F name=\u003Crepo> -F number=\u003Cpr> -f query='\nquery($owner: String!, $name: String!, $number: Int!) {\n  repository(owner: $owner, name: $name) {\n    pullRequest(number: $number) {\n      number\n      author { login }\n      baseRefName\n      headRefName\n      stackEntry { position }\n      stack {\n        number\n        baseRefName\n        size\n        entries(first: 100) {\n          nodes {\n            position\n            pullRequest { number author { login } baseRefName headRefName state isDraft }\n          }\n        }\n      }\n    }\n  }\n}'\n```\n\nEstablish the expected bottom-to-top order from the live PR bases: the bottom targets the trunk, and each higher PR targets the head branch immediately below it.\n\n## Link missing stack members\n\nFirst compare any existing stack entries with the expected chain. One existing stack may contain an order-preserving subset of the requested chain; multiple stack numbers, an unexpected entry, or a conflicting order requires user direction before any mutation.\n\nWhen any dependent PR is not yet in that official stack:\n\n1. Compare every `author.login` exactly.\n2. If all authors match, link the chain automatically in bottom-to-top order:\n\n```sh\ngh stack link --base \u003Ctrunk> \u003Cbottom-pr> \u003Cnext-pr> ... \u003Ctop-pr>\n```\n\n3. If authors differ or any author is unavailable, ask the user whether to link before changing GitHub state.\n4. Re-query GraphQL and require one stack number, the expected trunk, the complete PR set, and the expected positions and base chain.\n\nNever dissolve, reorder, or rebuild an existing stack automatically; `gh stack link` is additive and merged or queued entries cannot be unstacked.\n\n## Refresh only when needed\n\nDo not rewrite branches merely because a refresh mechanism exists. When the live merge state or repository rules require an updated trunk, choose either allowed history:\n\n- **Native cascading rebase:** check out the remote stack with `gh stack checkout \u003Cpr-or-stack>` when it is not tracked locally, then run `gh stack sync`. The command may rebase and lease-protected force-push every active layer before local validation. Immediately inspect the rewritten scope, run the relevant checks for every affected layer, and do not merge or claim readiness until they pass. If sync detects a rebase conflict, use `gh stack rebase`, resolve and validate it, then publish with `gh stack push`. If checkout or sync reports divergent local and remote stack compositions, cancel and ask rather than deleting or recreating the remote stack automatically.\n- **Incremental merge-forward:** merge the trunk into the bottom affected branch, then propagate each updated parent into its child in bottom-to-top order and push normally. If the base advances during an in-progress merge, preserve that checkpoint before merging the newer tip as specified by the [incremental-retargeting note](..\u002F..\u002Fnotes\u002Fimplemented\u002Fprocess\u002F2026-07-26-incremental-pr-base-retargeting.md).\n\nAny history rewrite is allowed after review, but it invalidates commit-OID assumptions. Re-fetch exact heads and re-audit unresolved review threads, approvals, mergeability, and checks after the push. Never use raw `--force` or overwrite a concurrently advanced remote head.\n\n## Preflight the merge range\n\nRe-query the official stack immediately before merging. Require every selected PR to be open, non-draft, in the expected order, and compliant with the repository's review and check requirements. Treat each PR's state independently; a ready top layer does not prove its dependencies are ready.\n\n\"Land the stack\" selects the whole stack. A partial landing requires an explicit boundary PR and includes every layer from the bottom through that boundary.\n\n## Merge through the stack API\n\nMerge the whole stack by its official stack number:\n\n```sh\ngh stack merge \u003Cstack-number> --yes --merge\n```\n\nFor an explicitly requested partial landing, merge through the boundary PR:\n\n```sh\ngh stack merge \u003Cboundary-pr> --yes --merge\n```\n\nDo not pass `--delete-branch`, manually retarget dependents, or issue per-PR merge commands. GitHub merges the selected range bottom-up and retargets\u002Frebases any remaining upper layers. A direct stack merge is all-or-nothing; when the trunk uses a merge queue, GitHub queues the selected range together but may land it in separate groups.\n\nDo not bypass merge requirements. If the native merge reports a blocker, inspect and resolve that blocker through the owning PR or stop and report it; never fall back to `gh pr merge`.\n\n## Verify the landed state\n\nWait for every selected PR to report `MERGED`; a queued request is not a completed landing:\n\n```sh\ngh pr view \u003Cpr> --json number,state,mergedAt,mergeCommit,baseRefName,headRefName\n```\n\nFor a partial landing, re-query the official stack and verify that every remaining PR is still linked in the expected order and targets the stack trunk or the layer below it. Re-check current heads, review state, and CI because GitHub may have rebased the remaining layers.\n\nDelete branches only in a separate final pass after the corresponding PRs report `MERGED`. Before deleting each branch, require GitHub to report no open PR still using it as a base:\n\n```sh\ngh pr list --state open --base \u003Cbranch> --json number --jq length\n```\n\nAnything other than `0` blocks deletion.\n\n## Checklist\n\n- [ ] Native `gh stack` support is available; every PR branch is in the same repository.\n- [ ] Live PR bases and exact heads establish one bottom-to-top dependency chain.\n- [ ] GraphQL reports one official stack with the expected trunk, entries, and order; an eligible same-author unstacked chain was linked automatically.\n- [ ] Any rewritten layers passed relevant validation, and review threads, approvals, mergeability, and checks were re-audited afterward.\n- [ ] The whole stack, or an explicitly bounded prefix, was submitted through `gh stack merge --yes --merge`.\n- [ ] Every selected PR reports `MERGED`; any remaining upper layers still form the expected official stack.\n- [ ] Branch deletion happened only after merged-state and zero-dependent verification.\n",{"name":5,"description":7},"main","d682beee161da2963de0a1bc91d17efc54ea8689","worldsoul-harness\u002F.agents\u002Fskills\u002Fdsh-merging-stacked-prs",0,"https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul","https:\u002F\u002Fgithub.com\u002Fgccszs","Code is cheap! Show me your prompt.","2026-09-27 15:07:46",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add gccszs\u002FWorldSoul --skill dsh-merging-stacked-prs",{"tool":58,"command":59},"bunx","bunx skills add gccszs\u002FWorldSoul --skill dsh-merging-stacked-prs",{"tool":61,"command":62},"pnpm","pnpm dlx skills add gccszs\u002FWorldSoul --skill dsh-merging-stacked-prs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002F.agents\u002Fskills\u002Fdsh-merging-stacked-prs\u002FSKILL.md",true,[],[67,80,98,106,122,146],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":39},"01M6CP8JPZRGT3SEHGSV9AHG4H","user-only-skill","Prove model-disabled skills stay outside the model catalog.","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002Fsnapshots\u002Fsession\u002Fskill-load\u002Fworkspace\u002F.dsh\u002Fskills\u002Fuser-only-skill\u002FSKILL.md",[],[74,75,76,77,78,79],"user","only","user only skill","model catalog","model","catalog",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"publishedAt":39},"01M6CP8H9P868EE1HX81BRXY0Y","snapshot-skill","Exercise project skill discovery and loading in snapshot tests.","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002Fsnapshots\u002Fsession\u002Fskill-load\u002Fworkspace\u002F.dsh\u002Fskills\u002Fsnapshot-skill\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[92,93,94,95,96,97],"snapshot skill","snapshot","discovery","exercise","project skill","skill discovery",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":39},"01M6CP8FWAC3866R4B6R8GZ04V","model-only-skill","Prove user-disabled skills remain available to the model.","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002Fsnapshots\u002Fsession\u002Fskill-load\u002Fworkspace\u002F.dsh\u002Fskills\u002Fmodel-only-skill\u002FSKILL.md",[],[78,75,105,74],"model only skill",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":39},"01M6CP8DE65MXX0KW3TMP2655R","editing-cordis-compositions","Use when creating, changing, or validating a Cordis composition for this harness — writing or editing an agent preset, adding or removing a plugin row, deciding whether something belongs to the host composition or to one session, checking whether a preset you authored actually mounts, or diagnosing a row that mounted but contributed nothing.","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002Fpackages\u002Fpreset\u002Fagent-presets\u002Fpresets\u002Fcordis\u002Fskills\u002Fediting-cordis-compositions\u002FSKILL.md",[],[113,114,115,116,117,26,118,119,120,121],"editing cordis compositions","editing","harness","Composition","session","but","writing","plugin","preset",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":39},"01M6CP8A0ACVBGHRR5M9X77KBG","cordis-plugin-development","Create, modify, debug, or extend dynamic Cordis Plugins, including Host Services and Events, Client Slot and theme UI, Package-private Client-to-Host calls, dynamic Tools, version updates, approval failures, and runtime diagnostics. Use this Skill to route a user request to the correct platform and Inspect Provider, then define, run, repair, or roll back the Plugin.","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002Fpackages\u002Fpreset\u002Fagent-presets\u002Fpresets\u002Fcordis\u002Fskills\u002Fcordis-plugin-development\u002FSKILL.md",[],[129,130,120,131,132,133,134,135,136,137,138,139,140,74,141,26,142,143,144,145],"cordis plugin development","development","Tools","debug","diagnostics","create","run","package","plugins","ui","services","correct","approval","version","provider","back","route",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":39},"01M6CP88NJH71DR1W6MRQ6ZMN6","preview-tour","Inspect the bundled Preview workspace and its deterministic Session examples.","https:\u002F\u002Fgithub.com\u002Fgccszs\u002FWorldSoul\u002Fblob\u002Fmain\u002Fworldsoul-harness\u002Fpackages\u002Fexperimental\u002Fwebworker-runtime\u002Ftests\u002Ffixtures\u002Fvfs-example\u002Fworkspace\u002F.agents\u002Fskills\u002Fpreview-tour\u002FSKILL.md",[],[153,154,117,155,156],"preview tour","workspace","deterministic","examples"]