create-pr

Creates reviewer-friendly GitHub pull requests with honest template sections and conventional titles.

Updated Feb 15, 2026
One-click install
npx skills add https://github.com/kbukum/gokit --skill create-pr-kbukum
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: create-pr
Source: https://github.com/kbukum/gokit/tree/main/.github/skills/create-pr
Command: npx skills add https://github.com/kbukum/gokit --skill create-pr-kbukum

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing a pull request description that a reviewer can actually understand is hard: diffs get dumped file-by-file, template checkboxes get ticked dishonestly, and titles carry internal batch numbers. This Skill turns a pushed branch into a PR whose description explains the change at a high level, filled honestly against the gokit engineering baseline. ## Core Features & Use Cases - High-level change analysis: Reads the actual diff against origin/main and groups it by concern instead of narrating per file. - Honest template filling: Completes every section of the repo PR template — title, motivation, type, modules, testing evidence, breaking changes, sibling parity — checking only what is genuinely true. - Safe gh CLI creation: Writes the body to a file and opens the PR with gh pr create --base main, only when explicitly asked, never adding reviewers unprompted. - Use Case: After pushing a feature branch adding a GCS storage backend, ask for a PR and get a conventional-commit title, a concise grouped summary, accurate test-gate evidence, and the PR URL back. ## Quick Start Ask the assistant to open a pull request for the current pushed branch against main using the create-pr skill.

Frequently Asked Questions about create-pr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a GitHub pull request with the gh CLI?▼

Write the PR body to a file, then run gh pr create --base main --title "<conventional-title>" --body-file <path>. The branch must already be committed and pushed to origin before opening the PR.

How to write a good pull request description for reviewers?▼

Group the diff by concern rather than narrating per file, state what changed and why at the capability level, and link issues with Fixes #123. Check only the testing gates you actually ran and leave untrue checklist boxes unchecked.

What title format should a pull request use?▼

Use Conventional Commit style naming the change, such as feat(storage): add GCS backend or refactor(di): typed cycle detection. Avoid plan, batch, or step numbers since the PR must stand alone.

When should a pull request not be created automatically?▼

A PR should only be opened when explicitly requested, never as a side effect of finishing work. The branch must be pushed to origin first, and reviewers should not be added unless asked.

How are cross-repository issue references handled in PR descriptions?▼

Issues in the same repo are linked as Fixes #123, but issues in other repositories like rskit must be referenced as full URLs such as https://github.com/kbukum/rskit/issues/45, never a bare #45.