mcpField
T
to-pr

to-pr

github.com/yahyabedirhan開発269 回インストール1 日前に更新
リポジトリ

to-pr について

to-prは、現在のタスクのPull Request説明を作成・更新するスキルです。関連情報の収集、説明の構成、GitHub CLIでの公開、レビュー用リンクの提示を案内します。

主な機能

  1. 01既存Pull Requestの確認
  2. 02タスクと差分の情報収集
  3. 03所定テンプレートによる説明作成
  4. 04ghを使ったPRの更新
  5. 05変更ファイルへのリンク生成

活用シーン

  1. 01完了したブランチ作業のPR作成
  2. 02実装変更後のPR説明の修正
  3. 03レビュー向け変更概要の準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yahyabedirhan/skills --skill to-pr

インストール後、Claude Code で/to-prを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE.humanlayer
references/
describe_pr_final_answer.md
pr_description_template.md
show-me.md

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

プルリクエストを説明する

現在のタスクに対するプルリクエストを作成または更新し、変更の目的と実装の概要をレビュアーが理解しやすい簡潔な説明を記載します。

ワークフロー

  1. 説明テンプレートを読みます。

    Read({SKILLBASE}/references/pr_description_template.md)

  2. プルリクエストを特定するか、作成します。

    • 現在のブランチに対応する PR があるか、gh pr view --json url,number,title,state,baseRefName,headRefName 2>/dev/null で確認します。
    • PR がない場合は、git status --short --branch と現在のブランチのコミットを調べます。
    • 必要に応じてタスクに関連する変更をコミットし、ブランチを upstream 付きでプッシュして PR を作成します。リポジトリの Git 安全プロトコルに従ってください。
    • 現在のブランチに関連する作業がなく、安全に作成できる現在のブランチの PR もない場合に限り、ユーザーに PR の選択を依頼します。

  3. 変更を説明するために必要なコンテキストだけを集めます。

    • チケットと、タスクに関連する成果物を読みます。
    • PR の差分全体と、動作や責務を把握するのに十分な周辺コードを読みます。
    • gh pr view を使って PR のメタデータと変更ファイルを取得します。
    • PR 本文で使う視覚的な概要の規約を確認するため、{SKILLBASE}/references/show-me.md を読みます。

  4. テンプレートを使って PR の説明を書きます。

    • Why the change はちょうど 1 文にします。
    • Special things to note は 1～3 個の箇条書きにします。レビュアーへの注意点、移行、互換性の制約、意図的な対象外、または予想外の判断を優先してください。特記事項がない場合は - None. と記載します。
    • Change outline は、散文やファイルごとの変更一覧ではなく、/show-me を参考にした簡潔な構造ビューにします。
    • PR の説明に役立つビューのみを含めます。
      • SQL テーブルとエンドポイントの契約変更、およびビジネスロジックの擬似コード。
      • 主要なデータ構造や型の変更。
      • 変更された責務が分かる、階層の浅いファイルツリー。
      • 重要なフック、状態、パッケージ境界を含む React コンポーネントツリーの変更。
      • 呼び出しツリー、コールスタック、制御フロー、またはデータフローの変更。
    • 既存の構造の変更を示す場合は diff ブロックを優先します。大部分が新規の場合や、diff 表記では責務や順序が分かりにくくなる場合は、完成形の全体を示します。
    • 各ビューは、レビュアーに必要な情報に絞ります。変更されていない分類は省略します。
    • 最後のセクションは Things to be aware of とし、「変更内容」の範囲外にある事項を記載します。自分だけで決めたこと、予想外の点、PR に含まれていないこと、フォローアップをそれぞれチケット、メンテナーへの TODO、または対応不要として示します。4 行を維持し、該当する内容がない場合は None. と記載して、検討済みであることが分かるようにします。Special things to note には変更そのものについて記載します。
    • PR で完了するチケットには Closes #n を、メンテナーによる確認（QA）待ちのチケットには、マージによって先にクローズされないよう Refs #n を付けます。
    • 任意：チケット ID／URL、関連する計画やドキュメントの URL、その他の関連リンクが分かっている場合はヘッダーに含めます。ない場合はヘッダーを省略します。

  5. 説明を保存して公開します。

    • .scratch/pr-{number}/description.md に保存します。.scratch/ は Git の追跡対象外であり、公開済みの説明は GitHub に保存されるため、保存や書き換えのためのコミットは不要です。
    • gh pr edit {number} --body-file {output-path} で PR を更新します。
    • 更新が成功したことを確認します。

  6. 完了を報告します：

    • {SKILLBASE}/references/describe_pr_final_answer.md を読みます。
    • PR URL、保存した説明のパス、変更したファイルの簡潔な一覧を含め、その最終回答テンプレートに沿って回答します。
    • 変更した各ファイルについて、プッシュ後のPRの最新ヘッドコミットを使って、レビュー用リンクを2つ作成します（更新されたPRでは、新しいヘッドへのリンクになります）。gh pr view {number} --json url,headRefOid,files を実行してください。{owner}/{repo} はPRの url から取得します。
      • 最終版： https://github.com/{owner}/{repo}/blob/{headRefOid}/{path}。GitHubでMarkdownとして表示されます。
      • 差分： {pr_url}/files#diff-{hash}。{hash} はパスのSHA-256です（Linuxでは printf %s '{path}' | shasum -a 256 または sha256sum を使います）。
    • 変更ファイルが多い場合は、主要なファイルにリンクし、残りはパスを一覧にします。

人から人への自然な語り口で書いてください。専門用語や俗語を避け、簡潔で筋の通ったわかりやすい表現を使います。

Issueやプルリクエストには、番号だけでなくタイトルを付けて言及してください。例：#12 Add login。タイトル、本文、ユーザーへの回答のいずれでも同様です。

コメント

Markdown 対応