메뉴
Create a Pull Request (GitHub) or Merge Request (GitLab) with a well-crafted title and description. Use when the user asks to create a PR, MR, open a pull request, submit a merge request, or says something like "open a PR".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | pull-request |
| description | Create a Pull Request (GitHub) or Merge Request (GitLab) with a well-crafted title and description. Use when the user asks to create a PR, MR, open a pull request, submit a merge request, or says something like "open a PR". |
| model | haiku |
| allowed-tools | Bash(git:*), Bash(gh:*), Bash(glab:*), Read |
Create PRs/MRs with descriptions that help:
git remote get-url origin
github.com → GitHub, use ghgitlab → GitLab, use glabgit branch --show-current
Abort if on a protected branch (main, master).
Get the default branch:
gh repo view --json defaultBranchRefglab repo viewgh pr view --json urlglab mr viewIf one already exists, show the URL and ask the user if they want to update its title and description. If yes, continue the workflow and update the existing PR/MR at the end instead of creating a new one.
git fetch origin <default-branch>
git log --oneline origin/<default-branch>..HEAD
If ≤ 10 commits, get per-commit diffs for better context:
git show <sha> --format="commit %H%n%n %s%n %b"
If > 10 commits, use a global diff:
git diff origin/<default-branch>...HEAD
Skip questions if the context is clear from commits and conversation.
Ask up to 3-4 questions if you need to clarify:
Questions must be specific to the commits — cite what you observe:
Never ask vague questions like "Why these changes?" or "How to test?".
Also ask for linked issues if the user hasn't mentioned any.
feat:, fix:, refactor:, etc.Use only the relevant sections — skip empty ones:
<!-- Only if the user provided a real issue number -->
Closes #NN
## Context
Why this change exists. 1-2 sentences + bullet points.
## Proposal
Summary of the approach and technical choices.
### Breaking changes
<!-- if applicable -->
### Design decisions
<!-- if non-obvious choices were made -->
## How to review
<!-- for large PRs -->
- Start with `file1.ts` which contains the main logic
- Then `file2.ts` for adaptations
## How to test
<!-- if not obvious -->
1. Step 1
2. Step 2
## TODO
<!-- ONLY if user asked for a draft -->
- [ ] Remaining task 1
- [ ] Remaining task 2
## Out of scope
<!-- if useful to set boundaries -->
- What is NOT included in this PR
Closes #NN if the user provided a real issue number — never use placeholders like #XXXXX or #NNgit branch -r
If the branch isn't on the remote yet:
git push -u origin <branch>
Create (new PR/MR):
gh pr create --title "<title>" --body "<body>"glab mr create --title "<title>" --description "<body>"Add --draft if the user asked for a draft.
Update (existing PR/MR):
gh pr edit --title "<title>" --body "<body>"glab mr update --title "<title>" --description "<body>"Show the PR/MR URL when done.
Conversational code review written to a markdown file the reviewer annotates, then acted on. Use when the user asks to review the current branch or diff, runs /paper-review (optionally with "working tree", "staging", "rescan", or a ref/range), says "review my changes", or asks to act on their annotations in an existing review file.
Perform a non-interactive interactive git rebase. Use when the user asks to rebase, squash, reorder, drop, or rename commits.
Interview the user to deeply explore an idea, feature, or problem through Q&A. Use when the user asks to be interviewed, wants to think through something, or needs help clarifying a concept.
Create a git commit with a well-crafted conventional commit message. Use when the user asks to commit, create a commit, or says something like "commit this".