How do I install the Git Pr skill?

Run npx skillmds@latest add ivy00johns/git-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 Git Pr safe to use?

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

Which AI agents work with Git 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 Git Pr free to use?

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

Who published Git Pr?

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

Git Pr by ivy00johns — Agent Skill

Name: Git Pr
Rating: 4.5 (4 reviews)
Author: ivy00johns

Git Pr

Guide for creating and updating GitHub pull requests in this repository: PR title format, body structure, clean descriptions, and the gh CLI workflow. Use when creating a pull request, writing a PR description, updating a PR, or preparing changes for review. Trigger on: "create a PR", "open a PR", "pull request", "PR description", "PR body", "ready for review", "gh pr create", "open pull request", "submit PR", "PR template". Also use proactively whenever you are about to run `gh pr create` — even if the user did not explicitly mention this skill.

ivy00johns Updated Sep 22, 2026

File contents

GitHub Pull Request Conventions

PR Title Format

type: Short description of the change

Use the same type conventions as git-commit (feat, fix, docs, etc.).
Sentence case for the description (capital first letter, no trailing period).
Keep it concise (under 70 characters is ideal).
The description should summarize the intent of the whole PR, not list individual commits.

Title examples

feat: Add retry policy to HTTP client
fix: Handle null input in prompt builder
docs: Add platform comparison document
chore: Update skill frontmatter spec

PR Body Structure

Use this template when writing the PR description. Adjust sections as needed for the size and complexity of the change — small fixes may only need the summary.

## Summary

<1–3 bullet points explaining what changed and why>

## Changes

<Grouped list of notable changes.>

## Test plan

<How was this tested? What should reviewers verify?>

Body guidelines

Lead with the why. Reviewers already have the diff — tell them what problem this solves.
Keep it scannable. Bullet points and short paragraphs. No walls of text.
Mention risks. If the change has migration steps or deployment ordering constraints, call them out.

Workflow

Creating a new PR

Ensure the branch is pushed with tracking set:
```
git push -u origin HEAD
```
Create the PR using gh pr create. Pass the body via a HEREDOC to preserve formatting. Keep HEREDOC content flush-left so GitHub renders the markdown correctly:
```
gh pr create --title "type: Description here" --body "$(cat <<'EOF'
## Summary

- <what changed and why>

## Changes

- <notable change 1>
- <notable change 2>

## Test plan

- [ ] <verification step>
EOF
)"
```
Use --base <branch> if targeting a branch other than the repository default.
Return the PR URL to the user so they can review it.

Updating an existing PR

gh pr edit {number} --title "type: Updated description"
gh pr edit {number} --body "$(cat <<'EOF'
…updated body…
EOF
)"

Checking PR status

gh pr status          # overview of your PRs
gh pr view {number}   # details of a specific PR
gh pr checks {number} # CI check status

Pre-Push Checklist

PR title: type: Description (sentence case, under 70 chars)
PR body has a Summary section explaining the why
Test plan describes how to verify the change
CI checks pass (or failures are understood and noted)

---name: git-prdescription: Guide for creating and updating GitHub pull requests in this repository: PR title format, body structure, clean descriptions, and the gh CLI workflow. Use when creating a pull request, writing a PR description, updating a PR, or preparing changes for review. Trigger on: "create a PR", "open a PR", "pull request", "PR description", "PR body", "ready for review", "gh pr create", "open pull request", "submit PR", "PR template". Also use proactively whenever you are about to run `gh pr create` — even if the user did not explicitly mention this skill.---# GitHub Pull Request Conventions## PR Title Format```texttype: Short description of the change```- Use the same type conventions as git-commit (`feat`, `fix`, `docs`, etc.).- Sentence case for the description (capital first letter, no trailing period).- Keep it concise (under 70 characters is ideal).- The description should summarize the *intent* of the whole PR, not list individual commits.### Title examples```textfeat: Add retry policy to HTTP clientfix: Handle null input in prompt builderdocs: Add platform comparison documentchore: Update skill frontmatter spec```---## PR Body StructureUse this template when writing the PR description. Adjust sections as neededfor the size and complexity of the change — small fixes may only need the summary.```markdown## Summary<1–3 bullet points explaining what changed and why>## Changes<Grouped list of notable changes.>## Test plan<How was this tested? What should reviewers verify?>```### Body guidelines- **Lead with the why.** Reviewers already have the diff — tell them what problem this solves.- **Keep it scannable.** Bullet points and short paragraphs. No walls of text.- **Mention risks.** If the change has migration steps or deployment ordering constraints, call them out.---## Workflow### Creating a new PR1. **Ensure the branch is pushed** with tracking set: ```bash git push -u origin HEAD ```2. **Create the PR** using `gh pr create`. Pass the body via a HEREDOC to preserve formatting. Keep HEREDOC content flush-left so GitHub renders the markdown correctly: ```bash gh pr create --title "type: Description here" --body "$(cat <<'EOF' ## Summary - <what changed and why> ## Changes - <notable change 1> - <notable change 2> ## Test plan - [ ] <verification step> EOF )" ``` Use `--base <branch>` if targeting a branch other than the repository default.3. **Return the PR URL** to the user so they can review it.### Updating an existing PR```bashgh pr edit {number} --title "type: Updated description"gh pr edit {number} --body "$(cat <<'EOF'…updated body…EOF)"```### Checking PR status```bashgh pr status # overview of your PRsgh pr view {number} # details of a specific PRgh pr checks {number} # CI check status```---## Pre-Push Checklist- [ ] PR title: `type: Description` (sentence case, under 70 chars)- [ ] PR body has a Summary section explaining the why- [ ] Test plan describes how to verify the change- [ ] CI checks pass (or failures are understood and noted)

Frequently asked questions