メニュー
Create a pull request using the repo PR template. Use when the user wants to open or submit a PR without immediately merging it. SKIP for end-to-end ship flows; use `ship` instead.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Address pull request review feedback from humans or bots. Use when existing comments, requested changes, unresolved review threads, or CodeRabbit/codex review findings need code fixes, verification, push updates, and thread resolution. SKIP fresh code-review requests with no existing feedback; use review-deep.
Take a GitHub issue from implementation to merged PR. Use for 'complete issue #N', 'finish this issue end-to-end', or fully autonomous issue-to-merge requests. SKIP issue startup without merge intent; use start-issue.
Run end-to-end PR verification with browser testing. Use before merge or in fix-and-ship mode when the user asks to verify a PR, run E2E, browser-test, or visually check UI changes. SKIP backend-only checks with no browser/UI path; use review-deep or ship as appropriate.
Start implementation of a GitHub issue: fetch context, prepare worktree flow, implement with TDD, verify, and submit PR. Use for 'start issue #N', issue URLs, or requests to begin issue work. SKIP fully autonomous issue-to-merge requests; use complete-issue.
Start issue work in a new tmux window with its own worktree. Use when the user has tmux running and wants issue startup to continue outside the current session. SKIP when not inside a tmux session ($TMUX unset) or when the user wants to work in the current session; use start-issue directly.
Ship a PR end-to-end: verify locally, push, create/update the PR, watch CI, handle review feedback, and merge without admin override. Use for 'ship', 'ship it', or 'push and merge'. SKIP if the user only wants a PR opened; use `create-pr`.
| name | create-pr |
| description | Create a pull request using the repo PR template. Use when the user wants to open or submit a PR without immediately merging it. SKIP for end-to-end ship flows; use `ship` instead. |
| allowed-tools | ["Read","Bash(git:*)","Bash(gh:*)","Bash(cat:*)","Bash(ls:*)","Glob","AskUserQuestion"] |
Create a pull request following the repo's PR template and conventions.
$create-pr
CURRENT_BRANCH=$(git branch --show-current)
DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | sed 's/.*: //')
git log "${DEFAULT_BRANCH}..HEAD" --oneline
git diff "${DEFAULT_BRANCH}..HEAD" --stat
If the current branch is main, master, or matches the default branch, stop and inform the user — do not create a PR from the default branch.
Ensure the branch is pushed to the remote:
git push -u origin "$CURRENT_BRANCH"
Check for a PR template in these locations (in order):
cat .github/pull_request_template.md 2>/dev/null || \
cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || \
cat docs/pull_request_template.md 2>/dev/null || \
cat pull_request_template.md 2>/dev/null || \
echo "NO_TEMPLATE"
If a template directory exists (.github/PULL_REQUEST_TEMPLATE/), list templates and ask the user which to use.
PR titles, bodies, and test-plan entries describe modules, contracts, and observable behavior, not file paths, line numbers, or current internal layout. Acceptance criteria are stated as behaviors a reviewer can verify.
If a template was found: Use its exact section structure. Fill in every section based on the commits and diff. Do not omit or skip sections.
If no template: Use this default format:
## Summary
- <1-3 bullet points describing what changed and why>
## Test Plan
- <How the changes were tested>
Look for issue references in:
issue-42-, fix/42-)Include Fixes #<number> or Closes #<number> in the PR body.
<type>(<scope>): <subject>gh pr create --title "<title>" --body "<body>"
Display the PR URL so the user can review it.