Run any Skill in Manus with one click

git-prs

Stars31

Forks1

UpdatedApril 30, 2026 at 18:59

Use when opening pull requests, drafting or revising PR descriptions, addressing PR review feedback, updating an existing PR after a force-push or rebase, handling PR templates, or working with GitHub pull requests, GitLab merge requests, or Bitbucket pull requests. Covers personal defaults for PR description hygiene and reviewer-facing content. Invoke this skill before running `gh pr create`, `glab mr create`, or equivalent, even on terse requests like "open a PR", "send a PR", "ship the PR", "PR it", "push it up for review", or "make an MR" — those phrases all map to the activities above.

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

kergoth

kergoth/dotfiles

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

git-prs

description

Pull Requests

Personal defaults for pull request work. If a project's CONTRIBUTING, AGENTS.md, or CLAUDE.md mandates a different workflow, follow the project.

Before creating a PR

Check .github/pull_request_template.md and .github/PULL_REQUEST_TEMPLATE.md. If a template exists, the PR body must follow its structure.

Invoke the clean-prose skill before finalizing the PR description.

Description hygiene

Remove or replace any placeholder text that would render in the PR body (for example, "type your description here") so the submitted description contains actual content rather than author instructions. Strip HTML comments and template scaffolding (for example, ); these don't render on GitHub but keep the description clean for future edits and copy-paste.
Do not restructure an existing PR description to match the repository's PR template when the original does not already follow it; reformatting risks losing context the author captured. Surface the mismatch and let the user choose whether to reshape it. Updating the description to track the branch contents within its existing shape is the right move.
Describe behavior relative to the base branch, not the development arc. A PR description tells reviewers what the diff introduces — not how the implementation evolved. If a feature was first written one way then refined within the branch, only the final behavior matters to a reviewer. "Changed X to Y" is implementation history; "does X" is what belongs in the description.

Checkboxes

Checkboxes that ask the human to acknowledge they reviewed, tested, or approved the work stay unchecked. The agent did not perform those acts; that acknowledgement belongs to the human.
Checkboxes that describe how the work was produced (e.g., "made with AI assistance", "co-authored by an AI agent") must be checked accurately when they apply. Leaving an AI-assistance box unchecked when AI was used is misleading and is not acceptable.

After updating an existing PR

After a force-push, additive commits, or rebase, re-read the PR description with gh pr view and compare it against the new branch contents. If the description no longer matches the diff (added or removed scope, changed approach, stale file lists), update it via gh pr edit. Description-versus-diff drift is a review hazard.

More from this repository

same repository

github-issue-triage

kergoth/dotfiles

Run end-to-end GitHub issue triage using the local triage scripts and parallel subagent scoring. Use when asked to create, refresh, or rerun issue triage markdown with complexity, difficulty, benefit, scope, and execution-lane recommendations (`agent-implementation`, `agent-assist-human`, `human-only`).

2026-07-0731

find-session

kergoth/dotfiles

Find and resume a past Claude Code, Codex, or Cursor Agent conversation by searching session history files by keyword. Use this skill whenever the user wants to find a previous conversation, can't remember which directory or agent they were using, wants to look up work from a past session, needs to resume a session they can't locate with /resume, codex resume, or agent --resume, or says something like "I know we discussed X somewhere" or "where was that session about Y". Infers search scope, agent, and keywords from the user's description and presents matching sessions with summaries before asking which to resume. Always use this skill rather than manually searching ~/.claude/, ~/.codex/, or ~/.cursor/ yourself.

2026-06-3031

git-commits

kergoth/dotfiles

Use for commit-level Git workflows in non-`.jj/` repositories: stage one logical change, write or revise commit messages, amend, create fixup commits, split bundled edits, curate history with rebase or autosquash, and verify bisectability. In repositories containing `.jj/`, use this skill only for explicit Git-only commit intent; generic commit intent routes to `jujutsu` plus `jj-commits`. Trigger on requests such as "commit this", "check it in", "ship it", "stage and commit", "amend", "fixup", "clean up history", "reword/split commits", or "draft/rewrite the commit message". Also use for indirect commit-message creation when drafting plans that specify commits (including `superpowers:writing-plans` outputs), and when writing commit message text in design docs, PR notes, or other artifacts.

2026-05-2931

cli-design

kergoth/dotfiles

Guidelines for designing and implementing command-line interfaces. Use when creating a new CLI tool, adding subcommands or flags to an existing one, implementing help text, designing error messages, or structuring CLI output. Also use when reviewing CLI code for usability, when the user asks about CLI best practices, or when generating argument parsers, config handling, or shell completions. Applies to any language.

2026-05-0531

shell-script-style

kergoth/dotfiles

Apply Christopher Larson's preferred Bash and POSIX shell script style when creating or substantially editing user-facing shell scripts. Use when writing or modifying shell utilities under `scripts/` or `script/` (including extensionless shebang executables, pre-commit entry scripts, and CI helpers), `.sh` files, shell snippets intended for the user to keep, or any Bash or POSIX sh program that will become part of the maintained codebase. Do not use for temporary test scripts, disposable intermediate artifacts, or scripts written solely for AI-agent execution.

2026-05-0431

jj-commits

kergoth/dotfiles

Use for generic commit-related intent in `.jj/` repositories. Must be paired with `jujutsu` in the same turn; never use it as a standalone skill. Explicit Git-only `.jj` commit intent routes to `git-commits`.

2026-05-0131

name

git-prs

description

Pull Requests

Personal defaults for pull request work. If a project's CONTRIBUTING, AGENTS.md, or CLAUDE.md mandates a different workflow, follow the project.

Before creating a PR

Check .github/pull_request_template.md and .github/PULL_REQUEST_TEMPLATE.md. If a template exists, the PR body must follow its structure.

Invoke the clean-prose skill before finalizing the PR description.

Description hygiene

Remove or replace any placeholder text that would render in the PR body (for example, "type your description here") so the submitted description contains actual content rather than author instructions. Strip HTML comments and template scaffolding (for example, ); these don't render on GitHub but keep the description clean for future edits and copy-paste.
Do not restructure an existing PR description to match the repository's PR template when the original does not already follow it; reformatting risks losing context the author captured. Surface the mismatch and let the user choose whether to reshape it. Updating the description to track the branch contents within its existing shape is the right move.
Describe behavior relative to the base branch, not the development arc. A PR description tells reviewers what the diff introduces — not how the implementation evolved. If a feature was first written one way then refined within the branch, only the final behavior matters to a reviewer. "Changed X to Y" is implementation history; "does X" is what belongs in the description.

Checkboxes

Checkboxes that ask the human to acknowledge they reviewed, tested, or approved the work stay unchecked. The agent did not perform those acts; that acknowledgement belongs to the human.
Checkboxes that describe how the work was produced (e.g., "made with AI assistance", "co-authored by an AI agent") must be checked accurately when they apply. Leaving an AI-assistance box unchecked when AI was used is misleading and is not acceptable.