How do I install the Manage Pr skill?

Run npx skillmds@latest add klausborges/manage-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Manage Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Manage Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Manage Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Manage Pr?

klausborges (@klausborges) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Manage Pr by klausborges — Agent Skill

Name: Manage Pr
Author: klausborges

Manage Pr

Create and update GitHub pull requests, including stacked PRs and the stack merge loop. Use when the user wants a PR opened or updated, work delivered as a stack, or says "let's get the PRs merged" or "merged

klausborges 70c81e0 3 files · 3.2 KB Updated Sep 17, 2026

File contents

Manage PR

Titles, style, and remote naming follow the git-conventions skill. PRs live on the repo's primary remote; this skill supports GitHub through gh. An explicit repo convention (PR template, title check, contributing doc) wins over these defaults.

Create or update

Inspect first: git log <base>..HEAD --oneline, git diff <base>...HEAD --stat, and gh pr view for existing PR state.
Title: type(scope): description.
Body from the template below through --body-file; pass explicit flags so gh never prompts.
Push the branch to the primary remote first (git push -u <primary> <branch>; repos usually have two remotes, and an unset upstream makes gh prompt).
Create ready for review and self-assigned: gh pr create --assignee @me --base <base> --title <title> --body-file <file>.
Fill Verification only with commands actually run and their results.

Template (omit Notes when empty):

## Summary

- 2-5 plain bullets: what changed and why.
- Stacked on #N. (stacked PRs only)

## Verification

- Commands run and their results.

## Notes

- Risk, migration order, or review pointers.

Stacks

When work spans several PRs, chain branches bottom-up: the first PR bases on the default branch, each later PR bases on the previous branch. Keep every PR independently green and order the stack so it reads as an argument.

Merge loop

On "let's get the PRs merged": map the stack bottom-up, record every branch's current tip, hand back the bottom PR's link, and wait. On each "merged #N" (any merge method, often squash):

Fetch the primary remote and fast-forward the local default branch.
Rebase the next branch onto the fresh default using the recorded tips: git rebase --onto <default> <old-base-tip> <branch>. Then rebase each remaining branch onto its rewritten parent the same way: git rebase --onto <parent> <old-parent-tip> <branch>. Record the new tips.
On conflict, stop and report; a half-resolved rebase never gets pushed.
Confirm each branch's content survived: git range-diff <old-base-tip>..<old-tip> <new-base>..<branch> shows only the base change. Push with --force-with-lease only then.
Retarget the next PR (gh pr edit <next> --base <default>), reply with its link, and wait for the next "merged #N". Resync this way even when the merge was not a squash. After the last PR, confirm the stack is complete and offer local cleanup (a branch checked out in a worktree needs git worktree remove first).

Guardrails

Merging is the user's action; this skill never merges.
Resolve the primary remote by name; a remote called origin does not exist in these repos.
Keep plan and milestone context out of titles and bodies.

Output

The PR URL, or during the merge loop the next PR's link and remaining stack.

---name: manage-prdescription: Create and update GitHub pull requests, including stacked PRs and the stack merge loop. Use when the user wants a PR opened or updated, work delivered as a stack, or says "let's get the PRs merged" or "merged---# Manage PRTitles, style, and remote naming follow the `git-conventions` skill. PRs live on the repo's primary remote; this skill supports GitHub through `gh`. An explicit repo convention (PR template, title check, contributing doc) wins over these defaults.## Create or update1. Inspect first: `git log <base>..HEAD --oneline`, `git diff <base>...HEAD --stat`, and `gh pr view` for existing PR state.2. Title: `type(scope): description`.3. Body from the template below through `--body-file`; pass explicit flags so `gh` never prompts.4. Push the branch to the primary remote first (`git push -u <primary> <branch>`; repos usually have two remotes, and an unset upstream makes `gh` prompt).5. Create ready for review and self-assigned: `gh pr create --assignee @me --base <base> --title <title> --body-file <file>`.6. Fill Verification only with commands actually run and their results.Template (omit Notes when empty): ## Summary - 2-5 plain bullets: what changed and why. - Stacked on #N. (stacked PRs only) ## Verification - Commands run and their results. ## Notes - Risk, migration order, or review pointers.## StacksWhen work spans several PRs, chain branches bottom-up: the first PR bases on the default branch, each later PR bases on the previous branch. Keep every PR independently green and order the stack so it reads as an argument.## Merge loopOn "let's get the PRs merged": map the stack bottom-up, record every branch's current tip, hand back the bottom PR's link, and wait. On each "merged #N" (any merge method, often squash):1. Fetch the primary remote and fast-forward the local default branch.2. Rebase the next branch onto the fresh default using the recorded tips: `git rebase --onto <default> <old-base-tip> <branch>`. Then rebase each remaining branch onto its rewritten parent the same way: `git rebase --onto <parent> <old-parent-tip> <branch>`. Record the new tips.3. On conflict, stop and report; a half-resolved rebase never gets pushed.4. Confirm each branch's content survived: `git range-diff <old-base-tip>..<old-tip> <new-base>..<branch>` shows only the base change. Push with `--force-with-lease` only then.5. Retarget the next PR (`gh pr edit <next> --base <default>`), reply with its link, and wait for the next "merged #N". Resync this way even when the merge was not a squash. After the last PR, confirm the stack is complete and offer local cleanup (a branch checked out in a worktree needs `git worktree remove` first).## Guardrails- Merging is the user's action; this skill never merges.- Resolve the primary remote by name; a remote called `origin` does not exist in these repos.- Keep plan and milestone context out of titles and bodies.## OutputThe PR URL, or during the merge loop the next PR's link and remaining stack.

Frequently asked questions