pr-creator
installsforks
How to install pr-creator?
rstackjs/agent-skills/pr-creator
$npx -y skills add rstackjs/agent-skills --skill pr-creatorUse when asked to create a pull request for this repository. It helps the PR follow the repository's branch safety rules, title convention, pull request template, and concise English writing style.
SKILL.md
| 1 | # Pull Request Creator |
| 2 | |
| 3 | ## Steps |
| 4 | |
| 5 | 1. Confirm the current branch with `git branch --show-current`. |
| 6 | If it is the default branch, create and switch to a new branch before doing anything else. |
| 7 | Use a descriptive branch name, preferably `feat-<topic>` or `fix-<topic>`. |
| 8 | |
| 9 | 2. Review local changes with `git status --short`. |
| 10 | Do not revert unrelated user changes. |
| 11 | Before creating the PR, ensure the intended changes are committed and never commit directly on the default branch. |
| 12 | |
| 13 | 3. If `.github/PULL_REQUEST_TEMPLATE.md` exists, read it and follow its structure. |
| 14 | |
| 15 | 4. Draft the PR title in the repository's standard format. If the repository uses Conventional Commits, common patterns include: |
| 16 | - `feat(core): add ...` |
| 17 | - `fix(types): ...` |
| 18 | - `docs: ...` |
| 19 | - `refactor(types): ...` |
| 20 | - `chore(ci): ...` for CI workflow, check, or release automation changes |
| 21 | - `chore(deps): ...` |
| 22 | - `release: v1.2.0` |
| 23 | |
| 24 | 5. Write the PR body in concise, clear English. |
| 25 | - In `Summary`, explain the change context first: the user-facing problem, maintenance goal, or compatibility constraint that makes the change necessary. |
| 26 | - Prioritize high-signal information: public API changes, behavior changes, breaking changes, migration notes, and important compatibility implications. |
| 27 | - Then describe the main implementation change only as much as needed to understand the review. |
| 28 | - Keep the PR body concise and review-oriented: use 1-4 short standalone sentences for typical changes, covering why it matters, what changed, and any reviewer-important impact. |
| 29 | - Omit incidental updates to tests, documentation, and supporting artifacts from the PR description; mention them only when they are the PR's primary purpose or carry reviewer-relevant risk. |
| 30 | - Avoid low-signal sections such as `Test plan` or `Validation`, routine verification commands, generated file lists, or obvious implementation details unless the repository template explicitly requires them or the change has unusual validation risk. |
| 31 | - Good background examples: |
| 32 | - `This PR adds support for custom logger injection so CLI output can be isolated per instance.` |
| 33 | - `This PR fixes incorrect padding in URL labels to keep terminal output aligned across different label lengths.` |
| 34 | - `This PR updates the English docs to clarify how the extraction option works and when to enable it.` |
| 35 | |
| 36 | 6. Fill `Related Links` with issue links, design docs, related PRs, or discussion pages. |
| 37 | If the PR upgrades an npm dependency, add a link to the upgraded version's release notes or tag page when available. |
| 38 | Example: `https://github.com/web-infra-dev/rspack/releases/tag/v1.0.0` |
| 39 | If there is no relevant link, omit the entire `Related Links` section from the PR body. |
| 40 | |
| 41 | 7. Push the branch only after re-checking the branch name. Never push the default branch directly. |
| 42 | |
| 43 | 8. Create the PR. |
| 44 | When running in Codex, use the Codex GitHub connector/plugin for GitHub operations. |
| 45 | Use `gh pr create` only as a fallback when the connector is unavailable. |
| 46 | |
| 47 | ## Constraints |
| 48 | |
| 49 | - Do not modify code while following this skill. |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
