Run any Skill in Manus with one click

pr-helper

Stars33

Forks1

UpdatedFebruary 20, 2026 at 13:30

Creates GitHub pull requests from the current branch. Use when the user asks to make a PR, open a PR, or create a pull request.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

butttons

butttons/pi-kit

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	pr-helper
description	Creates GitHub pull requests from the current branch. Use when the user asks to make a PR, open a PR, or create a pull request.
allowed-tools	Read, Bash(git:), Bash(gh:)

Creating Pull Requests

Create GitHub pull requests using the gh CLI.

Instructions

Run git log --oneline main..<current-branch> to see all commits on the branch.
Ensure the branch is pushed: git push origin <branch>. If it fails, ask the user.
Draft a PR title and body based on the commits.
Create the PR with gh pr create.

Title

Short, descriptive. Follow the same conventions as commit messages but can be slightly longer. Examples:

v0.0.5: session metadata + query command
fix: resolve stale session detection race condition
feat: add branch tracking across CLI and worker

If the branch contains a mix of features, use a version or summary label.

Body

Use this structure:

## Summary

One or two sentences describing the overall goal of the PR.

## Changes

Group changes by area/theme with `###` subheadings. Under each, use bullet points. Be concise -- one line per change, describe what not how.

## Tests

Describe what was tested, not raw counts. Focus on what test suites were added or changed and why. Example:
- **CLI**: Search text extractor tests for OpenCode agent
- **Worker**: OpenCode mapper tests, migrated existing test suites to new data layer utilities

Body rules

No emojis.
Use **bold** for package/component names in bullet points.
Keep bullet points to one sentence each.
Do not list every file changed -- summarize by feature.
Include test summary if tests were added or changed. Describe what was tested, not raw pass counts.
If there is a single commit, the body can be minimal (summary + one bullet list).

Flags

Always specify --base main (or whatever the target branch is). Let --head default to the current branch or specify it explicitly.

Flow

Gather commits and draft the title + body.
Show the proposed title and body to the user as plain text.
If the user approves, push the branch and run gh pr create.
If the user has feedback, revise and repeat.
Output the PR URL after creation.

Best Practices

Push before creating the PR so the remote branch exists.
If the branch is already pushed, do not push again unless there are new commits.
Use gh pr create not the GitHub web UI.
Pass the body inline with --body rather than opening an editor.

More from this repository

same repository

tanstack-start

butttons/pi-kit

Build full-stack React applications with TanStack Start. Use when creating, configuring, or working with TanStack Start projects, routing, server functions, middleware, deployment, or when the user mentions tanstack/start.

2026-04-1933

commit-helper

butttons/pi-kit

Generates clear commit messages from git diffs. Use when writing commit messages or reviewing staged changes.

2026-03-1433

beans

butttons/pi-kit

Manage tasks, bugs, and features with the beans issue tracker. Use when creating, listing, updating, or working on beans, or when the user asks what to work on next.

2026-03-0233

wrangler-ops

butttons/pi-kit

Operational patterns for Cloudflare Wrangler CLI. Use when deploying workers, running D1 migrations, querying D1 databases, managing R2 buckets, or generating binding types. Distinct from cloudflare-api which covers documentation lookups.

2026-03-0233

obi

butttons/pi-kit

Query Obsidian vaults via obi CLI. Use for any vault data lookup instead of grep or find -- searching notes, filtering by frontmatter (read status, type, tags), listing folders, reading sections, checking backlinks, and finding unread or recent notes.

2026-02-2733

changeset-helper

butttons/pi-kit

Manage changelogs and versioning using the changesets CLI. Use when creating changesets, bumping versions, consuming changesets for a release, or maintaining CHANGELOG.md files.

2026-02-2033

Creating Pull Requests

Create GitHub pull requests using the gh CLI.

Instructions

Run git log --oneline main..<current-branch> to see all commits on the branch.

Ensure the branch is pushed: git push origin <branch>. If it fails, ask the user.

Draft a PR title and body based on the commits.

Create the PR with gh pr create.

Title

Short, descriptive. Follow the same conventions as commit messages but can be slightly longer. Examples:

v0.0.5: session metadata + query command

fix: resolve stale session detection race condition

feat: add branch tracking across CLI and worker

If the branch contains a mix of features, use a version or summary label.

Body

Use this structure:

## Summary One or two sentences describing the overall goal of the PR. ## Changes Group changes by area/theme with `###` subheadings. Under each, use bullet points. Be concise -- one line per change, describe what not how. ## Tests Describe what was tested, not raw counts. Focus on what test suites were added or changed and why. Example: - **CLI**: Search text extractor tests for OpenCode agent - **Worker**: OpenCode mapper tests, migrated existing test suites to new data layer utilities

Body rules

No emojis.

Use **bold** for package/component names in bullet points.

Keep bullet points to one sentence each.

Do not list every file changed -- summarize by feature.

Include test summary if tests were added or changed. Describe what was tested, not raw pass counts.

If there is a single commit, the body can be minimal (summary + one bullet list).

Flags

Always specify --base main (or whatever the target branch is). Let --head default to the current branch or specify it explicitly.

Flow

Gather commits and draft the title + body.

Show the proposed title and body to the user as plain text.

If the user approves, push the branch and run gh pr create.

If the user has feedback, revise and repeat.

Output the PR URL after creation.

Best Practices

Push before creating the PR so the remote branch exists.

If the branch is already pushed, do not push again unless there are new commits.

Use gh pr create not the GitHub web UI.

Pass the body inline with --body rather than opening an editor.