How do I install the Pull Requests skill?

Run npx skillmds@latest add coder/pull-requests-4 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 Pull Requests 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 Pull Requests?

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 Pull Requests free to use?

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

Who published Pull Requests?

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

Pull Requests by coder — Agent Skill

Name: Pull Requests
Rating: 4.2 (5 reviews)
Author: coder

File contents

Pull Request Skill

When to Use This Skill

Use this skill when asked to:

Create a pull request for the current branch.
Update an existing PR branch or description.
Rewrite a PR body.
Follow up on CI or check failures for an existing PR.

References

PR conventions and local validation: AGENTS.md (Essential Commands and Commit Style sections)

Lifecycle Rules

Check for an existing PR before creating a new one:
```
gh pr list --head "$(git branch --show-current)" --author @me --json number --jq '.[0].number // empty'
```
If that returns a number, update that PR. If it returns empty output, create a new one.
Check you are not on main. If the current branch is main or master, create a feature branch before doing PR work.
Default to draft. Use gh pr create --draft unless the user explicitly asks for ready-for-review.
Keep description aligned with the full diff. Re-read the diff against the base branch before writing or updating the title and body. Describe the entire PR diff, not just the last commit.
Never auto-merge. Do not merge or mark ready for review unless the user explicitly asks.
Never push to main or master.

PR Title Format

Follow the commit style from AGENTS.md:

type(scope): message

Examples:

feat(mcp): add tool allowlist filtering
fix(intercept/messages): handle empty streaming chunks
refactor(provider): extract common auth logic

PR Description

Start with a one-line summary of what and why.
List key changes as bullet points.
Note any breaking changes or migration steps.
Do not fabricate or embellish — describe only what the diff contains.

CI / Checks Follow-up

Always watch CI checks after pushing. Do not push and walk away.

After pushing:

Monitor CI with gh pr checks <PR_NUMBER> --watch.
Use gh pr view <PR_NUMBER> --json statusCheckRollup for programmatic check status.

If checks fail:

Find the failed run ID from the gh pr checks output.
Read the logs with gh run view <run-id> --log-failed.
Fix the problem locally.
Run make test and make fmt before pushing the fix.
Push the fix.

Pre-Push Validation

Before pushing, always run:

make fmt
make test

What Not to Do

Do not reference or call helper scripts that do not exist in this repository.
Do not auto-merge or mark ready for review without explicit user request.
Do not push to origin/main or origin/master.
Do not skip local validation before pushing.
Do not fabricate or embellish PR descriptions.
Do not use --no-verify on git operations.

---name: pull-requests-4description: Guide for creating, updating, and following up on pull requests in the aibridge repository. Use when asked to open a PR, update a PR, rewrite a PR description, or follow up on CI/check failures.---# Pull Request Skill## When to Use This SkillUse this skill when asked to:- Create a pull request for the current branch.- Update an existing PR branch or description.- Rewrite a PR body.- Follow up on CI or check failures for an existing PR.## References- PR conventions and local validation: `AGENTS.md` (Essential Commands and Commit Style sections)## Lifecycle Rules1. **Check for an existing PR** before creating a new one: ``` gh pr list --head "$(git branch --show-current)" --author @me --json number --jq '.[0].number // empty' ``` If that returns a number, update that PR. If it returns empty output, create a new one.2. **Check you are not on main.** If the current branch is `main` or `master`, create a feature branch before doing PR work.3. **Default to draft.** Use `gh pr create --draft` unless the user explicitly asks for ready-for-review.4. **Keep description aligned with the full diff.** Re-read the diff against the base branch before writing or updating the title and body. Describe the entire PR diff, not just the last commit.5. **Never auto-merge.** Do not merge or mark ready for review unless the user explicitly asks.6. **Never push to main or master.**## PR Title FormatFollow the commit style from `AGENTS.md`:```type(scope): message```Examples:- `feat(mcp): add tool allowlist filtering`- `fix(intercept/messages): handle empty streaming chunks`- `refactor(provider): extract common auth logic`## PR Description- Start with a one-line summary of **what** and **why**.- List key changes as bullet points.- Note any breaking changes or migration steps.- Do not fabricate or embellish — describe only what the diff contains.## CI / Checks Follow-up**Always watch CI checks after pushing.** Do not push and walk away.After pushing:- Monitor CI with `gh pr checks <PR_NUMBER> --watch`.- Use `gh pr view <PR_NUMBER> --json statusCheckRollup` for programmatic check status.If checks fail:1. Find the failed run ID from the `gh pr checks` output.2. Read the logs with `gh run view <run-id> --log-failed`.3. Fix the problem locally.4. Run `make test` and `make fmt` before pushing the fix.5. Push the fix.## Pre-Push ValidationBefore pushing, always run:```bashmake fmtmake test```## What Not to Do- Do not reference or call helper scripts that do not exist in this repository.- Do not auto-merge or mark ready for review without explicit user request.- Do not push to `origin/main` or `origin/master`.- Do not skip local validation before pushing.- Do not fabricate or embellish PR descriptions.- Do not use `--no-verify` on git operations.

Frequently asked questions

Pull Requests