ワンクリックで
create-pr
Create or update a GitHub pull request from a pushed branch after local review, base-branch sync, validation, and issue linking.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Create or update a GitHub pull request from a pushed branch after local review, base-branch sync, validation, and issue linking.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-pr |
| description | Create or update a GitHub pull request from a pushed branch after local review, base-branch sync, validation, and issue linking. |
Use this after git-push when the user asks to create, update, or open a GitHub pull request.
Create or update a review-ready PR from the current branch after syncing the base branch, reviewing the diff locally, and linking the related task.
Inspect and choose base Run:
git status --short
git branch --show-current
git status -sb
Prefer the repo's default PR base. If repo guidance names a different base, use that. If the worktree is dirty, pause unless the changes are intentionally excluded from the PR.
Review and sync locally Run:
git diff --stat <base>...HEAD
git diff <base>...HEAD
Review the diff for accidental files, secrets, conflict markers, generated churn, and missing tests or docs.
Fetch the base branch and make sure it has been merged or rebased into the current branch before creating or updating the PR.
If conflicts occur, resolve them locally, rerun relevant validation, commit the resolution, and push through git-push so any configured pre-push hook runs.
Build title, body, and issue link Default the title from the issue title or the main commit subject. Infer issue links from the user request, branch name, or commits. Do not invent issue IDs. Keep the body concise and include:
Closes #123, Fixes #123, or Refs #123 when knownCreate or update PR
Use GitHub CLI when available. First check only for an open PR from the current branch. Do not use gh pr view as the existence check because it may resolve a previously merged or closed PR for the same branch name:
pr_url="$(gh pr list --state open --head "$branch" --json url --jq '.[0].url' --limit 1)"
If pr_url is not empty, update that open PR instead of creating a duplicate:
gh pr edit "$pr_url" --title "$title" --body-file "$body_file"
Before editing an open existing PR, read the current body and preserve user-authored content that is not clearly generated by this workflow. Do not overwrite manual notes, review context, checklist items, or release details just to apply the generated summary. If there is no open PR, create one. A merged or closed PR with the same branch name is not reusable and must not block creation of a new PR:
gh pr create --base "$base" --head "$branch" --title "$title" --body-file "$body_file"
Pass generated title/body/base/head values as separate argv-style arguments.
Do not paste user-, issue-, branch-, or commit-derived text directly into a
shell command line; if using shell variables, populate them without eval or
command substitution and always quote expansions.
If gh is unavailable or not authenticated, report the exact title/body/base/head needed to create or update the PR manually.
After creating or finding a PR, report:
Generate a local static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions.
Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.github/issue-triage/config.json` and `.github/CODEOWNERS`. Use when setting up triage automation on a new or existing repository for the first time.
Compare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available.
Create a product spec from a GitHub issue in this repository by applying the local shared `write-product-spec` workflow with issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/issue-<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or pull requests itself.
Create a technical spec from a GitHub issue in this repository by applying the local shared `write-tech-spec` workflow with issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/issue-<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or pull requests itself.
Repo-specific dedupe guidance . Only the categories declared overridable by the core dedupe-issue skill may be specialized here.