mcpField
M
manage-pr

manage-pr

github.com/klausborgesDevelopment1110 installsUpdated 2w ago
Repository

About manage-pr

A skill for creating, updating, and coordinating GitHub pull requests with `gh`, including stacked PR workflows. It emphasizes repository conventions, explicit verification, and leaving merges to the user.

Key features

  1. 01Inspect commits, diffs, and PR state
  2. 02Draft PR titles and template-based bodies
  3. 03Push branches to the primary remote
  4. 04Coordinate stacked PR rebases
  5. 05Leave merging to the user

Use cases

  1. 01Create a PR after completing a branch
  2. 02Update an existing PR using repository conventions
  3. 03Advance a stack after a PR is merged

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/klausborges/workflow-skills --skill manage-pr

After installing, type/manage-prin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlskill.toml

Details

From the project README

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

  1. 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.

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):

  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.

Output

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

Comments

Markdown supported