메뉴
Create a pull request for the current branch. Use when the user says "create a PR", "open a PR", "push and PR", "make a pull request", "submit a PR", "create pull request", or asks to publish/submit changes as a PR. Searches for a PR template and uses it to structure the description.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Unified VCS workflow skill: use jj for all local version control, gh for GitHub operations (PRs, issues), and trunk-based development with stacked PRs. Covers feature branches, daily work loops, PR creation, error recovery, and stack management. Triggers on: feature branch, create PR, push, pull, stacked PR, trunk-based, vcs workflow, jj workflow, github PR.
Use for ALL version control operations in projects. Handles commits, history, branches (bookmarks), remotes, diffs, conflict resolution, workspaces, and repository management using the jujutsu (jj) CLI. Triggers on: commit, branch, push, pull, merge, diff, log, history, undo, stash, rebase, squash, worktree, workspace, or any VCS/source control request.
Use when the user wants to create a commit message or commit changes. Follows Conventional Commits specification with feat, fix, ci, chore, docs, style, refactor, perf, test prefixes. Author-neutral messages, no AI persona. Triggers on: commit, write commit message, commit changes, describe change.
Use when the user wants to start implementing a new feature. Accepts a feature description (plain text) or a URL to a requirements document, issue, or ticket. Analyses the requirements, creates an isolated workspace for the feature, plans the development, and presents the plan for user approval before any code is written. Triggers on: new feature, implement feature, start feature, feature request, build feature, /new-feature.
Use when the user wants to plan or implement a feature using trunk-based development (TBD) with short-lived feature branches and stacked PRs. Guides decomposition of features into an ordered PR stack where each PR is independently green. Triggers on: trunk-based development, TBD, feature branch, stacked PRs, plan feature with TBD, PR stack.
| name | pr |
| description | Create a pull request for the current branch. Use when the user says "create a PR", "open a PR", "push and PR", "make a pull request", "submit a PR", "create pull request", or asks to publish/submit changes as a PR. Searches for a PR template and uses it to structure the description. |
Create a pull request for the current branch with a well-structured description.
Determine the current branch, the appropriate base branch, and a summary of commits and changed files that will be included in the PR.
The base branch is typically the repository's default trunk — common names include main, master, develop, trunk, or default. Detect it from the remote when possible rather than assuming a name.
If the branch has no commits ahead of the base branch, stop and inform the user there is nothing to PR.
Search for a pull request template in the project. Common locations to check:
.github/pull_request_template.md.github/PULL_REQUEST_TEMPLATE.md.github/PULL_REQUEST_TEMPLATE/ (directory with multiple templates — pick the most relevant)docs/pull_request_template.mdpull_request_template.mdIf a template is found: Use its structure as the basis for the PR description. Fill in all sections with relevant information from the commits and diff. Remove inapplicable sections and placeholder comments.
If no template is found: Use the default structure below.
Title: Short (under 72 characters), imperative mood, describes the change. Do not prefix with ticket numbers unless the template requires it.
Default description structure (when no template exists):
## Summary
<1–3 bullet points explaining what changed and why>
## Changes
<bullet list of key changes grouped by area if needed>
Populate every section with concrete details from the commits and diff. Do not leave placeholder text.
If the current branch has not been pushed to the remote yet, push it so the PR can be created against it.
If gh (GitHub CLI) is available and the remote is GitHub:
Use gh pr create with the composed title, description, and base branch. If gh is not authenticated, output the title and description so the user can open the PR manually.
For other VCS platforms (GitLab, Bitbucket, Azure DevOps, etc.):
Output the composed title and description in full so the user can paste them into the platform's PR/MR creation UI. Include a note on the base branch to target.
If the PR was created via CLI, return the PR URL. Otherwise, confirm the composed content was printed and remind the user which base branch to target.