Github
Squash-merge a stack of dependent GitHub PRs onto main as separate commits using gh CLI and rebase --onto.
Overview
GitHub Workflows is an agent skill for the Ship phase that merges stacked GitHub pull requests onto main as individual squash commits using rebase and gh CLI.
Install
npx skills add https://github.com/callstackincubator/agent-skills --skill githubWhat is this skill?
- Maps stacked PR chains (each PR bases on the previous branch, not main)
- Squash-merges the bottom PR to main, then rebases --onto main for each upstream PR
- Uses gh pr merge, gh pr edit --base, and force-with-lease pushes
- Preserves one squash commit per PR instead of a single mega-merge
- Sequential workflow: pull main after each merge before handling the next PR
Adoption & trust: 4.9k installs on skills.sh; 1.4k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have several open PRs stacked on each other’s branches and need them on main as separate commits without a messy merge or lost PR boundaries.
Who is it for?
Solo builders using stacked PRs (feat-a → feat-b → feat-c) who want squash-on-main discipline and can run git plus gh locally.
Skip if: Single PRs merged directly to main, repos without gh CLI, or teams that require merge commits or forbid force-push on shared branches.
When should I use this skill?
User has multiple PRs where each targets the previous PR's branch and wants to squash merge them all to main preserving separate commits per PR.
What do I get? / Deliverables
Each PR in the chain lands on main as its own squash commit with bases corrected to main, ready for the next PR in the stack or for closing the train.
- Main branch updated with one squash commit per stacked PR
- Upstream PR branches rebased with base branch set to main
Recommended Skills
Journey fit
Stacked PR merge chains are a shipping-time integration workflow once review branches exist, not early discovery or greenfield coding. Canonical shelf is code review and PR hygiene: rebasing stacked branches, retargeting bases, and landing reviewed work on main.
How it compares
Opinionated stacked-train procedure—not a generic “how to open a PR” or CODEOWNERS review checklist.
Common Questions / FAQ
Who is github for?
Indie developers and small teams who stack dependent GitHub PRs and want an agent-guided sequence to squash-merge the whole chain onto main.
When should I use github?
Use it in Ship during review when multiple PRs form a chain (each bases on the previous branch) and you want one squash commit per PR on main after rebasing and retargeting bases.
Is github safe to install?
The skill instructs force-with-lease pushes and gh merges—review permissions and branch rules in your repo; check the Security Audits panel on this Prism page before enabling autonomous git writes.
SKILL.md
READMESKILL.md - Github
interface: display_name: "GitHub Workflows" short_description: "GitHub PR and code review workflow patterns" default_prompt: "Use $github to apply GitHub PR and review workflows." --- title: Merge PR Chain tags: pull-request, stacked-pr, merge, squash, cherry-pick, github --- # Skill: Merge PR Chain Merge a chain of stacked GitHub PRs into main as individual squash commits. Use when user has multiple PRs where each targets the previous one's branch (e.g., PR #2 → PR #1's branch → main) and wants to squash merge them all to main while preserving separate commits per PR. ## Workflow ### 1. Identify the chain Fetch PR details to map the chain structure: ``` main └── #1 (base: main, branch: feat-a) └── #2 (base: feat-a, branch: feat-b) └── #3 (base: feat-b, branch: feat-c) ``` ### 2. Merge and rebase sequentially **First PR** (targets main): ```bash # Squash merge via GitHub CLI gh pr merge <N> --squash --title "<PR title> (#N)" git pull origin main ``` **Subsequent PRs** — rebase onto main, update base, then merge: ```bash # 1. Checkout the branch for the next PR git checkout <next-branch> # 2. Rebase onto main, excluding commits from the old base branch # This replays only this PR's commits onto main git rebase --onto origin/main <old-base-branch> <next-branch> # 3. Force push the rebased branch git push --force-with-lease origin <next-branch> # 4. Update the PR's base branch to main via GitHub CLI gh pr edit <N> --base main # 5. Squash merge the PR gh pr merge <N> --squash --title "<PR title> (#N)" # 6. Update local main git fetch origin main git checkout main git pull origin main ``` Repeat step 2 for each subsequent PR in the chain. ## Key details - **Always use PR title as commit title** — GitHub may default to branch name or first commit otherwise. Pass `--title` explicitly. - **Use `--force-with-lease`** — Safer than `--force`, fails if remote has unexpected changes. - **Update PR base before merging** — After rebasing, change the PR's base branch to `main` so it merges correctly and shows "merged into main" in GitHub UI. ## Handling conflicts When `git rebase --onto` encounters conflicts: 1. Git will pause and show which files have conflicts 2. **Stop and ask the user** to resolve conflicts manually 3. After user resolves: `git add <resolved-files> && git rebase --continue` 4. If user wants to abort: `git rebase --abort` **Never auto-resolve conflicts** — always ask the user to review and resolve manually. ## Why this works `git rebase --onto <new-base> <old-base> <branch>` takes commits that are in `<branch>` but not in `<old-base>` and replays them onto `<new-base>`. This effectively strips the already-merged commits and moves only the PR's unique changes onto main. ## Benefits over cherry-pick - PRs show as "merged into main" in GitHub UI - Clean linear history on main - No duplicate commits or confusing merge states - Each PR's diff remains reviewable until merged --- name: github description: GitHub patterns using gh CLI for pull requests, stacked PRs, code review, branching strategies, and repository automation. Use when working with GitHub PRs, merging strategies, or repository management tasks. license: MIT metadata: author: Callstack tags: github, gh-cli, pull-request, stacked-pr, squash, rebase --- # GitHub Patterns ## Tools Use `gh` CLI for all GitHub operations. Prefer CLI over GitHub MCP servers for lower context usage. ## Quick Commands ```bash # Create a PR from the current branch gh pr create --title "feat: add feature" --body "Description" # Squash-merge a PR gh pr merge <PR_NUMBER> --squash --title "feat: add feature (#<PR_NUMBER>)" # View PR status and checks gh pr status gh pr checks <PR_NUMBER> ``` ## Stacked PR Workflow Summary When merging a chain of stacked PRs (each targeting the previous branch): 1. **Merge the first PR** into main via squash merge 2. **For each subsequent PR**: rebase onto main, update base to main, then