create-pr

スター8

フォーク0

更新日2026年7月3日 10:18

Create a GitHub pull request with context-aware description

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

ebkn

ebkn/dotfiles

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Pre-fetched context

!git rev-parse --abbrev-ref HEAD !git status --short !git ls-files ':(top,icase).github/pull_request_template.md' ':(top,icase).github/pull_request_template/*.md' ':(top,icase)pull_request_template.md'

Instructions

Create a pull request. Follow this flow:

Gather context: Get the default branch locally via git rev-parse --abbrev-ref origin/HEAD (strip the origin/ prefix); only if that fails (origin/HEAD unset) fall back to gh repo view --json defaultBranchRef -q .defaultBranchRef.name. Then read the commits with full messages via git log <base>..HEAD (bodies included — the commit skill records the why there) plus git diff --stat <base>..HEAD for the file-level shape. Pull the full git diff <base>..HEAD only when the messages and stat don't sufficiently explain the changes (thin or missing commit bodies) — for large PRs this avoids reading the whole diff needlessly.
Uncommitted changes: Don't block. Create the PR from the commits that already exist and note in your reply that any uncommitted changes were left out. Only stop if there are no commits ahead of the base branch — there is then nothing to open a PR from.
PR template:
- If a template path is listed, Read it before writing title/body.
- Detect template_language from headings/instructions/checklists (ignore code, URLs, HTML comments).
- Keep template headings/order and keep HTML comments ().
- If no template exists, skip.
Compose PR:
- Title: Conventional Commits.
- Decide title language before drafting and keep it fixed unless the user requests a change.
- Title language policy: use template_language first whenever it can be detected.
- If the user explicitly asks to override language for the current PR, follow that override.
- If no template_language is detected, use: explicit user request > latest substantive user message > English.
- Ignore slash commands (for example /create-pr), code blocks, file paths, and URLs when inferring language.
- If language signals conflict or are ambiguous, don't block — fall back to the priority order above (default to English when nothing is decisive).
- Keep type(scope) tokens standard (feat, fix, etc.); localize only the description text.
- Body: if template exists, fill its sections. If not, use Summary / Changes / Concerns / References.
- Proactively include any reference links (issues, docs, related PRs) found in conversation history.
- Do not append the Claude session URL (https://claude.ai/code/…) to the PR body.
Push and create: Do not ask the user to confirm the title/body — create directly. Push before creating:
- Check for an upstream with git rev-parse --abbrev-ref --symbolic-full-name @{upstream}.
- If it fails (no upstream — the common new-branch case), push unconditionally with git push -u origin HEAD.
- If an upstream exists, push only when git log @{upstream}..HEAD shows unpushed commits.
Then create the PR, passing the body via a quoted heredoc into --body-file - (stdin) so backticks, $, and quotes in the body stay literal — no escaping, no temp file, and no $() subshell:
```
gh pr create --title "<title>" --body-file - <<'PR_BODY_EOF'
<body>
PR_BODY_EOF
```
Keep the title free of backticks — GitHub renders PR titles as plain text, so backticks would appear literally and would trigger shell command substitution inside the double quotes; escape any $ or " if the title contains them. Return the PR URL.

このリポジトリの他の Skills

同じリポジトリ

init-project

ebkn/dotfiles

Scaffold a new project in the current directory — git init, README.md, CLAUDE.md, AGENTS.md, Claude settings.json, linter/test config, unused-code detection (knip for TypeScript), runtime pin, lockfile (npm for TypeScript, uv for Python), supply-chain hardening (SHA-pinned GitHub Actions, least-privilege GITHUB_TOKEN, Dependabot cooldown, pinned container base images), and CI (GitHub Actions + Dependabot) for the specified language (TypeScript, Go, Python), plus optional Next.js boilerplate with error boundaries, security headers, SEO, and a health endpoint. Use this skill when the user wants to initialize or bootstrap a new project from scratch, set up a fresh repo, or scaffold project boilerplate.

2026-07-218

commit

ebkn/dotfiles

Stage and commit changes with conventional commits

2026-07-038

deep-dive

ebkn/dotfiles

A relentless interview to think a topic through before committing — software requirements or any general question (a decision, a concept, a plan, research). Act as a critical thinking partner: surface the real intent, challenge assumptions, weigh alternatives, name what stays uncertain. One question at a time, each with a recommended answer. Always end by writing a document capturing what was decided and what is open. Use proactively whenever the user wants to think something through, define requirements, or clear up ambiguity — triggered by "要件定義したい", "深掘りしたい", "壁打ちしたい", "一緒に考えて", "help me think this through", "grill me", or the `/deep-dive` command.

2026-07-038

review-support

ebkn/dotfiles

Help the reviewer understand a GitHub pull request through dialogue. Start with a short orientation to the PR's purpose and approach, then answer their questions and dig into the real code interactively so their understanding deepens. Only once understanding is solid — and only when the reviewer asks — organize their own conclusions into review notes they send themselves. Facilitator: never produce ok/ng verdicts or review comments on your own. Triggered by requests like "PRをレビューしたい", "PRを理解したい", "このPRを見たい", "help me review this PR", or the `/review-support` command.

2026-07-038

review-test

ebkn/dotfiles

テストコードのレビューを行う。公開契約（入出力・エラー契約・副作用保証）を起点に、テストが振る舞いの仕様として機能しているかを評価し、改善点を優先度付きで報告する。「テストをレビューして」「テストのレビューをお願い」「test review」「review the tests」などテストそのもののレビューを依頼された時、または /review-test コマンドで起動する。

2026-07-038

update-pr

ebkn/dotfiles

Update an existing GitHub pull request after adding commits by revising title/body, preserving template format, and pushing pending branch changes.

2026-07-038

name	create-pr
description	Create a GitHub pull request with context-aware description
effort	low
allowed-tools	Bash(git status ), Bash(git diff ), Bash(git log ), Bash(git rev-parse ), Bash(git push ), Bash(git ls-files ), Bash(gh repo view ), Bash(gh pr create ), Bash(echo *), Read, Glob, Grep, AskUserQuestion

Pre-fetched context

Instructions

Create a pull request. Follow this flow:

Gather context: Get the default branch locally via git rev-parse --abbrev-ref origin/HEAD (strip the origin/ prefix); only if that fails (origin/HEAD unset) fall back to gh repo view --json defaultBranchRef -q .defaultBranchRef.name. Then read the commits with full messages via git log <base>..HEAD (bodies included — the commit skill records the why there) plus git diff --stat <base>..HEAD for the file-level shape. Pull the full git diff <base>..HEAD only when the messages and stat don't sufficiently explain the changes (thin or missing commit bodies) — for large PRs this avoids reading the whole diff needlessly.
Uncommitted changes: Don't block. Create the PR from the commits that already exist and note in your reply that any uncommitted changes were left out. Only stop if there are no commits ahead of the base branch — there is then nothing to open a PR from.
PR template:
- If a template path is listed, Read it before writing title/body.
- Detect template_language from headings/instructions/checklists (ignore code, URLs, HTML comments).
- Keep template headings/order and keep HTML comments ().
- If no template exists, skip.
Compose PR:
- Title: Conventional Commits.
- Decide title language before drafting and keep it fixed unless the user requests a change.
- Title language policy: use template_language first whenever it can be detected.
- If the user explicitly asks to override language for the current PR, follow that override.
- If no template_language is detected, use: explicit user request > latest substantive user message > English.
- Ignore slash commands (for example /create-pr), code blocks, file paths, and URLs when inferring language.
- If language signals conflict or are ambiguous, don't block — fall back to the priority order above (default to English when nothing is decisive).
- Keep type(scope) tokens standard (feat, fix, etc.); localize only the description text.
- Body: if template exists, fill its sections. If not, use Summary / Changes / Concerns / References.
- Proactively include any reference links (issues, docs, related PRs) found in conversation history.
- Do not append the Claude session URL (https://claude.ai/code/…) to the PR body.
Push and create: Do not ask the user to confirm the title/body — create directly. Push before creating:
- Check for an upstream with git rev-parse --abbrev-ref --symbolic-full-name @{upstream}.
- If it fails (no upstream — the common new-branch case), push unconditionally with git push -u origin HEAD.
- If an upstream exists, push only when git log @{upstream}..HEAD shows unpushed commits.
Then create the PR, passing the body via a quoted heredoc into --body-file - (stdin) so backticks, $, and quotes in the body stay literal — no escaping, no temp file, and no $() subshell:
```
gh pr create --title "<title>" --body-file - <<'PR_BODY_EOF'
<body>
PR_BODY_EOF
```
Keep the title free of backticks — GitHub renders PR titles as plain text, so backticks would appear literally and would trigger shell command substitution inside the double quotes; escape any $ or " if the title contains them. Return the PR URL.