diff --git a/skills/mcore-split-pr/SKILL.md b/skills/mcore-split-pr/SKILL.md
index 40bf67b476f..28c86f9a172 100644
--- a/skills/mcore-split-pr/SKILL.md
+++ b/skills/mcore-split-pr/SKILL.md
@@ -28,6 +28,11 @@ workflow:
   separate PR just to reduce reviewer groups.
 - If PR B depends on symbols renamed in PR A, call out the dependency and put
   backward-compatible aliases, re-exports, or shims in PR A when needed.
+- When creating dependent PRs, set the dependent PR's GitHub base/diffbase to
+  `pull-request/<base PR number>`, not the base PR author's branch.
+- Before merging a base PR, retarget each dependent PR back to `main` and
+  refresh it against `main`; otherwise GitHub may automatically close the
+  dependent PR, losing approvals and review discussion.
 - Wait for user approval before execution.
 - Execution creates draft PRs from the right base, applies file-scoped diffs
   with `git diff upstream/main..<source-branch> -- <paths> | git apply`, pushes
@@ -65,10 +70,10 @@ Wait for user approval before proceeding.
 ### 3. Execute the split (after user approval)
 
 For each new PR:
-1. Create a new branch from the appropriate base (`main`, or a dependency PR's branch).
+1. Create a new branch from the appropriate local base (`main`, or a dependency PR's branch).
 2. Extract the relevant changes: `git diff upstream/main..<source-branch> -- <file paths> | git apply`.
 3. Stage, commit with a clear message, and push to the user's fork.
-4. Create the PR as a **draft** (per repo contributing guidelines).
+4. Create the PR as a **draft** (per repo contributing guidelines). For dependent PRs, set the GitHub base/diffbase to `pull-request/<base PR number>`.
 5. If the original PR needs to be narrowed in scope, confirm with the user before force-pushing.
 6. Report all PR URLs when done.
 
@@ -76,6 +81,7 @@ For each new PR:
 
 - Always create PRs as **drafts** and push to the user's fork, never directly to upstream.
 - Backward-compatible changes (aliases, re-exports, deprecation shims) should go in the first PR so subsequent PRs can depend on them.
+- Dependent PRs should target `pull-request/<base PR number>` while stacked, then be retargeted and refreshed to `main` before the base PR is merged.
 - Test files should go with the production code they test, not in a separate PR.
 - Prefer a single clean commit per split PR over replaying the original commit history.
 - If a file is hard to categorize (e.g., it touches two groups), ask the user which PR it should go in.