القائمة
Pull request style guidelines covering title, body, assignee, and label selection. Use when writing or proposing GitHub pull requests, including direct `gh pr create` invocations outside the /pr skill.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Generate a commit message from staged changes and let the user review before committing. Use when the user wants to commit changes or create a git commit.
Generate a GitHub pull request title and body from the current branch and let the user review before creation. Use when the user wants to create a pull request.
Investigate any topic by querying multiple external sources (web, official docs, GitHub, MCP servers). Use whenever a question requires information not already in the working context, including library behavior, API specifications, error diagnostics, version comparisons, or general factual lookup.
himari is ncaq's rio-like custom Haskell Prelude. Import it with a single `import Himari`, never `import Himari.Prelude` or other submodules directly. Use when writing or reviewing Haskell code in a project that depends on the himari package.
Prefer the most specific built-in method over general-purpose ones in TypeScript/JavaScript. Use includes over indexOf, some over filter().length, find over filter()[0], flatMap over map().flat(), at(-1) over length-based access, startsWith/endsWith/includes over indexOf on strings, structuredClone over JSON round-trip. Use when writing or reviewing code that searches, tests, transforms arrays, objects, or strings.
Avoid for loops (C-style, for...of, for...in) in TypeScript/JavaScript. Prefer higher-order Array methods like map, filter, find, some, every, reduce. Use when writing or reviewing loops or iteration over arrays, objects, Map, Set, or String.
| name | pr-style |
| description | Pull request style guidelines covering title, body, assignee, and label selection. Use when writing or proposing GitHub pull requests, including direct `gh pr create` invocations outside the /pr skill. |
| allowed-tools | Bash(gh label list:*), Bash(gh pr list:*), Bash(gh pr view:*), Bash(gh repo view:*), Bash(git diff:*), Bash(git log:*), Bash(read-contributing:*), Bash(read-pull-request-template:*), mcp__github__get_me, mcp__github__list_pull_requests, mcp__github__pull_request_read |
| user-invocable | false |
| effort | medium |
GitHubのpull requestを作成するときのスタイルガイドラインです。
タイトルと本文の書き方に加え、
アサインとラベルの決め方も扱います。
/prスキル経由でないPR作成でも、
このガイドラインに従ってください。
リポジトリ固有のスタイルがある場合は、 ここに書かれたデフォルトより優先してください。
!read-contributing
上記の内容が空でなければリポジトリのCONTRIBUTING.mdの内容です。
CONTRIBUTING.mdファイルが典型的に存在する場所を探索して、
最初に見つかったファイルの内容を出力します。
内容に従ってください。
!read-pull-request-template
上記の内容が空でなければリポジトリのpull requestテンプレートです。 GitHub標準のテンプレートの置き場所を探索して、 全てのテンプレートの内容を出力します。
テンプレートが存在する場合は、 そのテンプレートの構造を本文に反映してください。 複数のテンプレートが存在する場合は、 PRの内容に最も合うものを選んでください。
直近のmergedなPRは、 タイトルと本文のスタイル、 そしてラベルの実際の使われ方の両方の参考になります。 GitHub MCPが利用可能な場合は優先して使ってください。 PR一覧の応答にはラベル情報も含まれているため、 この取得結果を後のラベル選定にも流用してください。
mcp__github__list_pull_requests: PR一覧の取得mcp__github__pull_request_read: PR詳細の取得GitHub MCPが使えない場合はGitHub CLI(gh)を使ってください。
gh pr list --state merged --limit 20 --json number,title,body,author,labels
gh pr view <number> --json title,body,labels
bot(renovate, dependabotなど)のPRは参考になりません。
author.is_botがfalseのPRだけを参考にしてください。
baseブランチからの差分を以下のコマンドで取得してください。
git log <base>..HEAD --no-merges
git diff <base>...HEAD --stat
差分が大きい場合は--statで概要を把握してから、
必要な範囲だけgit diff本体で内容を確認してください。
リポジトリのスタイルが不明な場合のデフォルトスタイルは、
commit-styleスキルのガイドラインに従った、
Conventional Commits準拠の日本語タイトルです。
リポジトリのスタイルがある場合はそちらを優先してください。
PRに含まれるコミットが1つだけの場合は、 そのコミットのタイトルをそのままPRのタイトルに使ってください。
PRに含まれるコミットが複数ある場合は、 PR全体の変更を要約するタイトルを新たに書いてください。
リポジトリ固有のテンプレートが用意されている場合は、 そのテンプレートを埋める形で本文を書いてください。
リポジトリのスタイルの個別の要素が不明な場合のデフォルトスタイルの要素は以下です。
日本語で記述してください。
丁寧語とですます調で書いてください。
英単語と日本語が混在する場合は、 英単語の前後にスペースを入れないでください。 中国語の風習では普通スペースを入れますが、 日本語ではスペースを入れないのも一般的で、 私は基本的にスペースなしのスタイルを採用しています。
行長は100文字以内に収めてください。 URLなど改行できないものを挿入する場合は例外です。
改行位置は句読点の後など、 自然な場所を選んでください。 不自然な場所で改行はしないでください。 改行位置が不自然になるぐらいなら文章を練りなおしてください。 日本語は英語と違い好きに改行して良い言語ではないので、 改行位置には十分注意してください。
コードのシンボル(関数名や変数名など)を本文に含める場合は、 Markdownのインラインコード記法であるバッククォートで囲んでください。
本文には変更の内容だけではなく、 なぜその変更が必要だったのか、 理由をなるべく書いてください。
PRに含まれるコミットが1つだけの場合は、 そのコミットメッセージの本文をそのままPRの本文に使ってください。
PRに含まれるコミットが複数ある場合は、 PR全体の変更を要約する本文を新たに書いてください。
要約は投稿時点のスナップショットを意識してください。 「最初は〜という実装だったが、〜に変えた」のような中間地点の情報は不要です。 最終的にこのPRがmergeされたら何が達成されるのかを書いてください。
実装の具体的詳細はPR提出後の修正で変わる可能性が高いです。
よって具体的な関数名やファイル名の羅列ではなく、 何故この変更が必要なのか、 これをマージすることで何を達成するのか、 という抽象的な記述を優先してください。
以下はGitHub CLIやコーディングエージェントが自動挿入しがちですが、 意味のない汚染になるため使いません。 PR本文を生成するときに混入させないでください。
## Summary, ## Test plan, ## Changesのような固定見出しは、
リポジトリのテンプレートで指定されていない限り使いません。
内容に応じて自由に文章で書いてください。
Generated with Claude Codeのような署名や、
Co-Authored-By: Claude <noreply@anthropic.com>のようなトレーラーを付けないでください。
Claude Codeはテキストエディタの延長線上でしかないので、 ツールの名前をわざわざ書く必要はないと考えているからです。
Markdownの、
*emphasis***strong**_emphasis___strong__などの強調シンタックスは基本的に使いません。
LLMによって乱用されがちなためです。
強調しなくても意味が通じる場合は強調シンタックスを使わないでください。
強調が意味的に必要な場合は許可されます。
ユーザが明示的に要求しない限り絵文字は使わないでください。
ASCIIに対応する全角形は使用禁止です。
()は半角()を使ってください。:は半角:を使ってください。,は半角,を使ってください。0-9は半角0-9を使ってください。そのPRがissueをクローズする場合は、
原型小文字のcloseキーワードと番号を本文に含めてください。
例:
close #123
closesclosedfixfixesfixedresolveresolvesresolvedなどの活用形や別キーワードは使いません。
原型小文字のcloseに統一してください。
クローズせず関連を示すだけの場合は、
原型小文字のrefを使ってください。
例:
ref #123
refs, referencesなどは使いません。
原型小文字のrefに統一してください。
別リポジトリのissueを参照する場合は、 わかりやすさと移動しやすさのために、 短縮記法ではなくURLを使ってください。
close https://github.com/owner/repo/issues/123
ref https://github.com/owner/repo/issues/456
mcp__github__get_meで認証済みユーザの情報を取得し、
loginを記憶してください。
PRのアサインは基本的にこの自分自身を表すユーザ名を指定します。
!gh label list --json name,description,color --limit 100
上の埋め込みコマンドの結果はリポジトリで定義されているラベル一覧です。
GitHub MCPにラベル一覧を取得するツールはないため、 ここだけGitHub CLIを使っています。
存在しないラベルを指定するとアサインとラベルの一括設定ステップが失敗するため、 ここから外れたラベルは付与しないでください。
その上で「過去のmerged PRの参照」で取得したPRで、 どのようなラベルが付与されているかも参考にしてください。 ラベルの定義名だけでは用途の温度感が分からないため、 実際の使われ方を観察することで適切な選定ができます。
PRの内容を考慮して、 取得したラベル一覧から適切なものを選んでください。 適切なラベルが見当たらない場合はラベルなしで構いません。