Skip to content

Document stacked dependent PR handling in split PR skill #5496

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
wujingyue merged 1 commit into from
Jul 2, 2026
Merged

Document stacked dependent PR handling in split PR skill #5496

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions skills/mcore-split-pr/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -65,17 +70,18 @@ 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.

## Important guidelines

- 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.
Expand Down
Loading