Create PR
Use this skill when the user asks to create or open a pull request.
PR Granularity
A PR is a reviewable responsibility unit; one PR may contain multiple atomic commits. A branch is not a PR boundary: split independent work into separate PRs and stack only dependent work.
Workflow
Inspect the current branch, status, and diff:
git status --short
git branch --show-current
git diff --stat
If the current branch is main, create a feature branch with a feature/, fix/, or chore/ prefix unless the user requested a different branch name.
Review the diff before committing. Exclude unrelated changes, temporary files, secrets, generated junk, and debug-only edits.
Commit with the repo-local commit skill using an English Conventional Commit message. When CI is unnecessary and repository instructions permit skipping it, append [ci skip] to the commit message.
Prepare a PR title and body proportional to the change:
- Use a Conventional Commit type such as
feat, fix, docs, refactor, or chore in the PR title.
- For a small focused change, use 2–4 sentences covering what changed and why.
- For a larger change, include Summary, What Changed, Why, and Testing only when tests were actually run. Add Related Issues only when relevant.
- Use
--body-file - for multi-line bodies. Do not embed \n escape sequences in --body.
When the change is visual (UI, layout, rendering, or a bug clearer on screen), attach real local screenshots or short videos with gh pr create --attach. Do not invent media; skip when there is nothing useful to show, or when gh pr create --help does not list --attach. Prefer Markdown references to local paths in the body so alt text survives upload. If media appears only after the PR exists, attach with gh pr edit / gh pr comment instead of recreating the PR. See gh pr create --help and https://gh.io/gh-attach.
Publish using the path that matches the PR structure:
Use gh-stack only when requested or when the branch is already stacked; verify parent-child ancestry before linking.
For an ordinary PR, push the branch and create the PR with:
git push -u origin <branch-name>
gh pr create --title "feat(scope): summary" --body-file -
Add --attach on that invocation when step 6 applies.
Report the PR URL. If publishing fails, inspect the error and verify the branch, remote, authentication, or duplicate PR state before retrying.
All commit messages, PR titles, and PR bodies must be in English. Confirm the target branch before creating the PR, and do not call it ready until the relevant checks and review feedback have been inspected.
1---2name: create-pr-33description: Runs the full PR workflow — creates a feature branch, commits, pushes, and opens the pull request. Use when the user asks to create or open a PR ("create a PR", "push this up and open a PR").4---56# Create PR78Use this skill when the user asks to create or open a pull request.910## PR Granularity1112A PR is a reviewable responsibility unit; one PR may contain multiple atomic commits. A branch is not a PR boundary: split independent work into separate PRs and stack only dependent work.1314## Workflow15161. Inspect the current branch, status, and diff:1718 ```sh19 git status --short20 git branch --show-current21 git diff --stat22 ```23242. If the current branch is `main`, create a feature branch with a `feature/`, `fix/`, or `chore/` prefix unless the user requested a different branch name.25263. Review the diff before committing. Exclude unrelated changes, temporary files, secrets, generated junk, and debug-only edits.27284. Commit with the repo-local `commit` skill using an English Conventional Commit message. When CI is unnecessary and repository instructions permit skipping it, append `[ci skip]` to the commit message.29305. Prepare a PR title and body proportional to the change:3132 - Use a Conventional Commit type such as `feat`, `fix`, `docs`, `refactor`, or `chore` in the PR title.33 - For a small focused change, use 2–4 sentences covering what changed and why.34 - For a larger change, include Summary, What Changed, Why, and Testing only when tests were actually run. Add Related Issues only when relevant.35 - Use `--body-file -` for multi-line bodies. Do not embed `\n` escape sequences in `--body`.36376. When the change is visual (UI, layout, rendering, or a bug clearer on screen), attach real local screenshots or short videos with `gh pr create --attach`. Do not invent media; skip when there is nothing useful to show, or when `gh pr create --help` does not list `--attach`. Prefer Markdown references to local paths in the body so alt text survives upload. If media appears only after the PR exists, attach with `gh pr edit` / `gh pr comment` instead of recreating the PR. See `gh pr create --help` and https://gh.io/gh-attach.38397. Publish using the path that matches the PR structure:4041 - Use `gh-stack` only when requested or when the branch is already stacked; verify parent-child ancestry before linking.42 - For an ordinary PR, push the branch and create the PR with:4344 ```sh45 git push -u origin <branch-name>46 gh pr create --title "feat(scope): summary" --body-file -47 ```4849 Add `--attach` on that invocation when step 6 applies.50518. Report the PR URL. If publishing fails, inspect the error and verify the branch, remote, authentication, or duplicate PR state before retrying.5253All commit messages, PR titles, and PR bodies must be in English. Confirm the target branch before creating the PR, and do not call it ready until the relevant checks and review feedback have been inspected.
ryoppippi