How do I install the Pr skill?

Run npx skillmds@latest add tomevault-io/pr-12 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.

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with 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.

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

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

Pr by tomevault-io — Agent Skill

Name: Pr
Author: tomevault-io

File contents

Create a Pull Request

Create a branch, commit, push, and open a PR for the current changes.

Steps

1. Assess the current state

Run in parallel:

git status (never use -uall)
git diff and git diff --staged to understand all changes
git log --oneline -5 to see recent commit message style

Identify which files should be committed. Do NOT commit files that are:

Scratch/debug/temporary files
Files containing secrets (.env, credentials, etc.)

If there are no meaningful changes to commit, tell the user and stop.

2. Determine the branch name

Branch names in this repo follow the pattern: <area>/<type>/<short-description>

Where:

<area> is one of: backend, web, frontend, mobile, devops, docs, or another area that matches the changed files. For cross-cutting changes spanning multiple areas, pick the one that best describes the change.
<type> is one of: feature, bugfix, fix, refactor, or similar
<short-description> is a short kebab-case description

Infer area and type from the changed files and the nature of the changes. Never use a username as the area.

3. Run linters and formatters

Before committing, run the appropriate linters and formatters for the changed areas:

Backend: make format and make mypy from /app/backend
Web/Frontend: lint/format as appropriate

Fix any issues before proceeding. If linters produce changes, include those in the commit.

4. Create the branch and commit

If there are already commits on the current branch and no uncommitted changes remain (e.g. changes were already committed earlier), skip the commit and proceed to pushing.

Otherwise:

git checkout -b <branch-name>
git add <specific files>  # add only the relevant files by name
git commit -m "<message>"

Write a concise commit message (1-2 sentences) that describes what changed and why.

5. Push the branch

git push -u origin <branch-name>

6. Create the PR

Read the PR template from .github/pull_request_template.md in this repo. Fill it in based on the actual changes:

Fill in the description at the top (what and why)
Fill in the Testing section with what was done or what should be done
Include the appropriate checklist(s) — backend, web, or both — based on which areas were changed. Remove checklists that don't apply.
Keep the "For maintainers" section as-is
Append the following note as the very last line of the PR body, after the "For maintainers" section (separated by a blank line):
```
_This PR was created with the Couchers PR skill._
```

gh pr create --base develop --title "<short title>" --body "$(cat <<'EOF'
<filled-in PR template>

_This PR was created with the Couchers PR skill._
EOF
)"

7. Report back

Tell the user the PR URL when done.

Source: Couchers-org/couchers — distributed by TomeVault.

---name: pr-12description: Commit all changes, push to a new branch, and create a pull request using the repo's PR template. Use when the user says to make a PR or submit changes. Use when this capability is needed.---# Create a Pull RequestCreate a branch, commit, push, and open a PR for the current changes.## Steps### 1. Assess the current stateRun in parallel:- `git status` (never use `-uall`)- `git diff` and `git diff --staged` to understand all changes- `git log --oneline -5` to see recent commit message styleIdentify which files should be committed. Do NOT commit files that are:- Scratch/debug/temporary files- Files containing secrets (`.env`, credentials, etc.)If there are no meaningful changes to commit, tell the user and stop.### 2. Determine the branch nameBranch names in this repo follow the pattern: `<area>/<type>/<short-description>`Where:- `<area>` is one of: `backend`, `web`, `frontend`, `mobile`, `devops`, `docs`, or another area that matches the changed files. For cross-cutting changes spanning multiple areas, pick the one that best describes the change.- `<type>` is one of: `feature`, `bugfix`, `fix`, `refactor`, or similar- `<short-description>` is a short kebab-case descriptionInfer area and type from the changed files and the nature of the changes. Never use a username as the area.### 3. Run linters and formattersBefore committing, run the appropriate linters and formatters for the changed areas:- **Backend**: `make format` and `make mypy` from `/app/backend`- **Web/Frontend**: lint/format as appropriateFix any issues before proceeding. If linters produce changes, include those in the commit.### 4. Create the branch and commitIf there are already commits on the current branch and no uncommitted changes remain (e.g. changes were already committed earlier), skip the commit and proceed to pushing.Otherwise:```git checkout -b <branch-name>git add <specific files> # add only the relevant files by namegit commit -m "<message>"```Write a concise commit message (1-2 sentences) that describes what changed and why.### 5. Push the branch```git push -u origin <branch-name>```### 6. Create the PRRead the PR template from `.github/pull_request_template.md` in this repo. Fill it in based on the actual changes:- Fill in the description at the top (what and why)- Fill in the Testing section with what was done or what should be done- Include the appropriate checklist(s) — backend, web, or both — based on which areas were changed. Remove checklists that don't apply.- Keep the "For maintainers" section as-is- Append the following note as the very last line of the PR body, after the "For maintainers" section (separated by a blank line): ``` _This PR was created with the Couchers PR skill._ ``````bashgh pr create --base develop --title "<short title>" --body "$(cat <<'EOF'<filled-in PR template>_This PR was created with the Couchers PR skill._EOF)"```### 7. Report backTell the user the PR URL when done.---> Source: [Couchers-org/couchers](https://github.com/Couchers-org/couchers) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions

Pr