agentsclimarketplace
Sign in

Pr create

Skill yasunori0418/skills/skills/github/pr-create

Pull Request / Merge Request を作成するときに必ず参照する。`gh pr create`/`glab mr create` で PR/MR を作る、コミット済みの作業をレビューに出す、並列・stacked 作業の各ブランチで PR を起こす、といった場面で使う。リポジトリの pull_request_template/merge_request_template を決定論スクリプトで検出して優先し、テンプレの骨組み（見出し・チェックリスト・順序）を改変せず入力箇所を埋めるだけにする（作成前に骨組み照合ゲートで機械検証）。無ければ汎用観点で本文を構成。本文の素材は対象リポジトリの git 差分のみに限定し、他リポジトリ・他タスクの内容を混入させない。draft 既定・作成前にユーザー承認。未 push のときは AskUserQuestion で承認を取ってから push。GitHub(gh) 基本、GitLab(glab) 等にも対応。From its SKILL.md

Install
npx -y skills add yasunori0418/skills --skill pr-create

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

14.9 KB, as published. Nobody here has run it

PR 作成

リポジトリ固有の PR テンプレートに沿った PR を写経なしで作成する。テンプレートが無くても汎用観点で過不足ない PR を作る。モデルが PR 作成を要する場面で自動的に参照してよく、/pr-create の明示実行でも動く。

制約（厳守）

  • push は無断で行わない。未 push を検出しても勝手に push せず、作成直前に AskUserQuestion で push 可否の承認を取る（要点・選択肢は本文にも記載。§7）。承認されれば push してよい。拒否ならユーザーに委ねて停止。
  • 作成は draft が既定。「通常 PR で」の指示時のみ非 draft。
  • 作成前に必ずタイトルと本文を提示しユーザー承認を得てから 作成コマンドを実行する。
  • 対象リポジトリの取り違え・文脈混入を禁止。本文・タイトルは scripts/pr-context.sh が出すこの作業ディレクトリの git 状態（REPO IDENTITY / COMMITS / DIFF）だけを根拠にする。会話履歴に残る別リポジトリ・別タスクの内容を PR 本文へ持ち込まない。スクリプトの REPO IDENTITY（repo slug / worktree-root）が、PR を作ろうとしている対象と一致することを作成前に必ず確認する。
  • テンプレートは確定フォーム。骨組みを改変しない。TEMPLATE が primary/選択 multi を返したら、見出し・チェックリスト・順序を逐語で保ち、入力箇所を埋めるだけ（§4）。独自フォーマットへの差し替え・セクションの削除/追加/並べ替え・見出しの言い換えは禁止。作成前に scripts/template-check.sh の骨組み照合ゲート（§5）を必ず通す。
  • PR本文にセッションURLを含めない。Claude Code の既定動作は本文末尾にセッションへのリンクを付与するが、このリポジトリでは付与しない。ローカル CLI・remote-control のどちらのセッションでも同様。

ワークフロー

1. コンテキスト収集（スクリプト）

プラットフォーム判定・ベース特定・差分・push 状態は決定論的に行えるため scripts/pr-context.sh を実行する。手で git コマンドを並べ直さない。

bash <skill-dir>/scripts/pr-context.sh [base-branch]

=== SECTION === 区切りの出力を読む:

  • REPO IDENTITY = 対象リポジトリの repo slug と worktree-root。本文を起こす前にここを確認し、いま PR を作ろうとしている対象と一致することを担保する（制約「対象リポジトリの取り違え禁止」）。
  • PR BODY FILE = 本文下書きの書き出し先（絶対パス）。§5 でここに本文を Write し、template-check.sh の第2引数にも同じパスを渡す。パスにはセッションごとにユニークな ID が埋まっている（worktrunk 等で複数セッションが tmp_claude/ を symlink 共有していても衝突しないよう分離済み）。自分でファイル名を決めず、必ずこの行のパスを使う。同一セッションでの再実行は同じパスに落ちるので下書きの上書き更新になる。
  • PLATFORM = remote URL から判定したプラットフォームと使用 CLI・導入有無。github→gh、gitlab→glab、unknown/installed: no → 本文を提示して手動作成を案内。コマンド詳細は references/platforms.md。
  • TEMPLATE = リポジトリルートから決定論検出したテンプレ。primary: が出たらそれを使う（独自フォーマット禁止）。multi: は複数テンプレなので候補提示して選んでもらう。(テンプレートなし) のときだけ §4 の汎用構成。ここで primary が出ているのに自前の見出しで書くのは規約違反。
  • BASE BRANCH = リモート既定ブランチではなく、作業ブランチの分岐元をローカル探索した結果。(特定できませんでした) や誤検出が疑わしいときは引数 base-branch を渡して再実行、またはユーザーに確認。
  • COMMITS / COMMIT MESSAGES = 本文の主素材。
  • DIFF STAT / CHANGED FILES = 変更範囲。完全差分が要れば末尾の git diff <base>...HEAD を別途実行。
  • UPSTREAM / PUSH STATUS に WARNING（未 push／未 push コミットあり）が出たら記録しておき、§7 の作成直前に AskUserQuestion で push 可否の承認を取る（承認されれば push、拒否なら停止）。ここで自動 push はしない。

2. テンプレート確認

テンプレ検出は §1 の pr-context.sh が TEMPLATE セクションで決定論的に済ませている。手で find を打ち直さない（打ち忘れ・スキップの元）。

  • primary: があり multi: が無い → そのファイルを読んで使う。
  • multi: がある → 候補をユーザーに提示し、選ばれたものを使う。
  • (テンプレートなし) → §4 の汎用構成へ。

配置の網羅一覧やプラットフォーム別の細部は references/platforms.md。スクリプトの検出漏れが疑わしいとき（独自配置のテンプレ等）だけ手動探索を補助に使う。

3. 言語判定

本文の言語は次の優先順で決める。①テンプレートがある → テンプレートの見出し・コメントの言語に合わせる。②無い → 直近コミットや README の言語。③不明 → ユーザーに確認。

4. 本文生成

大原則: 本文の素材は §1 スクリプトが出したこの作業ディレクトリの COMMITS / DIFF / CHANGED FILES だけ。会話に残る別リポジトリ・別タスクの記憶を素材にしない。

テンプレートあり（TEMPLATE に primary/選択した multi）: **テンプレは「確定した入力フォーム」**として扱う。テンプレ作成者が「何をどこに書くか」を既に決めているので、文脈を読んで構成を作り直す作業ではなく、決められた入力箇所を埋めるだけ。

  • 骨組みは逐語で不変。見出しのテキスト・階層・順序、チェックリスト項目のラベル、HTML コメントの指示は変えない・消さない・並べ替えない・言い換えない。編集してよいのは入力箇所だけ（見出し下の空行やプレースホルダを埋める、- [ ]→- [x]）。これはモデルの無断改変を禁じるルールであり、ユーザーが骨組み変更を明示指示・許可したときは §5 の例外に従う（ユーザー指示 > このデフォルト）。
  • 該当しないセクションも削らない。「今回は関係ない」と判断しても見出しは残し、中身に「該当なし」等と正直に書く。掃除・簡潔化を目的にセクションを落とさない。レビュアーはそのフォームの型で読む前提なので、型を崩すとレビュー観点が抜け落ちる。
  • テンプレに無いセクションを勝手に足さない（どうしても補足が要るならテンプレ末尾に最小限）。
  • <!-- ... --> は指示として読み、埋めた後の扱い（残す/消す）はテンプレ慣習・既存 PR に倣う。
  • チェックリスト - [ ] は差分から確実に満たすものだけ - [x]。不明は未チェックで残し、全部チェックしない。
  • 推測で事実を捏造しない。差分から読めない背景は埋めず、ユーザーに補完を促す。

生成した本文は、作成前に §5 の骨組み照合ゲートを必ず通す。

テンプレートなし: 下記の汎用構成（言語は §3 準拠、不要セクションは省く）。

## 概要
<!-- この PR で何をするか 1〜2 行 -->
## 変更内容
<!-- 主な変更点を箇条書き -->
## 変更の背景・理由
<!-- なぜ必要か。関連課題・経緯 -->
## 動作確認
<!-- どう確認したか。テスト・検証手順 -->
## 影響範囲・注意点
<!-- 影響箇所・レビュー注意点・未対応事項 -->
## 関連 Issue / リンク
<!-- Closes #xxx など -->

5. 骨組み照合（テンプレートがある場合の作成前ゲート）

テンプレ遵守を目視に委ねると、無意識にセクションを落としたり見出しを言い換えたりしやすい。決定論スクリプトで機械的に照合し、drift があれば提示前に潰す。

  1. 生成した本文を §1 の PR BODY FILE が示すパスに書き出す（セッション分離済みの絶対パス。自分でファイル名を決めない）。

  2. テンプレ本体と照合する（<pr-body> は §1 の PR BODY FILE のパス）:

    bash <skill-dir>/scripts/template-check.sh <テンプレのパス> <pr-body>
    • RESULT: OK → 骨組み一致。§7 の提示へ進む。
    • RESULT: DRIFT DETECTED → MISSING（削った見出し/項目）・EXTRA（勝手に足した見出し）・REORDER（並べ替え）を確認し、下書きをテンプレ構造に戻して再チェック。OK になるまで提示に進まない。骨組みを守った上で入力箇所を埋め直す（勝手にセクションを消して辻褄を合わせない）。

テンプレが無い（§4 の汎用構成）ときはこのゲートは不要。

例外: ユーザーが骨組み変更を明示許可したとき

このゲートが弾くのはモデルの無断改変。ユーザーが明示的に骨組みの変更を指示・許可した場合は別で、その変更後の本文を採用してよい（例: 「テストケース1/2/3 のラベルを実際の確認観点に書き換えてよい」「このチェック項目は棄却してよい」「ゲートを棄却する」等）。DRIFT を消すためにユーザー指示を無視してテンプレ構造へ戻してはならない（今回の逆走はこれ）。手順:

  1. ユーザーの許可を1文で再言明してから本文を編集する（例:「テスト節の テストケース1 を『本番で Slack 通知を確認』に置換します。2/3 はプレースホルダのまま残します」）。解釈が割れる指示は AskUserQuestion で確定してから触る。
  2. 変更後の本文を PR BODY FILE に書き出し、参考として template-check.sh を再実行する。ここで出る DRIFT は想定内なので OK にする必要はない。
  3. どの項目を何に変えたかを §7 の提示でユーザーに見せ、承認を得てから作成する（無断改変との区別のため、承認前に作成しない）。
  4. この「ユーザー承認済み DRIFT」であることを覚えておき、§7 の CREATE 直前ゲート（下記）でも DRIFT を許容する。

判断が曖昧なら「ユーザーが骨組み変更を許可したのか、それとも入力箇所を埋める話か」を確認する。デフォルトは骨組み不変。棄却は明示指示があるときだけ。

6. タイトル

Conventional Commits 形式（<type>(<scope>): <subject>、commit-flow スキル準拠）を基本。単一コミットはそのメッセージを流用、複数は全体を要約。既存 PR にタイトル規約があればそれを優先。

7. 承認 →（未 push なら push 承認）→ 作成

  1. タイトルと本文をチャットに提示 → ユーザー承認。
  2. §1 の PUSH STATUS が WARNING（未 push／未 push コミットあり）なら、AskUserQuestion で push 可否の承認を取る（要点と選択肢は本文にも記載／CLAUDE.md 準拠）。
    • 承認 → push する。SSH 認証（publickey）で弾かれる非対話環境では gh-push スキルに従い HTTPS+gh トークン経由で push。
    • 拒否 → push せず、ユーザーが push してから作成する旨を伝えて停止。
    • 既に push 済み（WARNING なし）ならこの手順は不要。
  3. CREATE 直前の最終ゲート（テンプレありのとき必須）。§5 の照合は「その時点のファイル」の保証でしかなく、その後の Write や外部変更で無効化される。作成コマンドに渡すまさにそのファイルを再検証する:
    • gh pr create --body-file <PR BODY FILE> の直前に、実ファイルを cat してユーザーに承認された本文と同一内容であることを確認する（Write 成功メッセージや context 上の状態を信用せず、必ず実ファイルを読む）。食い違っていたら作成せず、正しい本文を書き直してからやり直す。
    • あわせて template-check.sh <テンプレ> <PR BODY FILE> をもう一度実行する。
      • RESULT: OK → 作成へ。
      • RESULT: DRIFT DETECTED かつ §5 の「ユーザー承認済み DRIFT」に該当しない → 作成を中止。無断改変が紛れ込んでいるので本文を戻して再照合する。
      • RESULT: DRIFT DETECTED だが §5 でユーザーが明示許可した変更そのものなら、想定内として作成してよい（許可外の drift が増えていないことは DIFF で確認）。
  4. draft 作成（コマンドは references/platforms.md）→ PR の URL を報告。

参照

  • scripts/pr-context.sh — リポジトリ同定（REPO IDENTITY）・プラットフォーム判定・テンプレ決定論検出（TEMPLATE）・ベース特定〜差分・push 状態を出す read-only スクリプト（§1）。
  • scripts/template-check.sh — テンプレ本体と本文下書きの骨組み（見出し＋チェックリストのラベル）を照合し、削り・勝手追加・並べ替えを検出する作成前ゲート（§5）。
  • references/platforms.md — プラットフォーム別 CLI コマンド・テンプレ配置・手動作成フォールバック。

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.