mcpField
P
pr

pr

github.com/tldraw開発51.2k48 回インストール2 日前に更新
リポジトリ

pr について

現在のブランチでプルリクエストを作成または更新する Claude Code スキルです。ブランチ準備、作業の重複確認、差分レビュー、PR 内容の更新を案内します。

主な機能

  1. 01ブランチと PR の状況確認
  2. 02重複するプルリクエストの調査
  3. 03ブランチの準備、コミット、プッシュ
  4. 04PR 作成前の変更レビュー
  5. 05PR のタイトルと本文の作成・更新

活用シーン

  1. 01現在のブランチ変更から PR を作成
  2. 02コード変更後に既存 PR を更新
  3. 03競合する PR の提案前に関連作業を確認

インストール

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

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

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

詳細

PR

現在のブランチのプルリクエストを作成または更新します。

PR のタイトル、説明、リリースノート、API の変更、コード変更の表、ユーザー向けメモの保持に関する基準として、../write-pr/SKILL.md を使用してください。

ワークフロー

  1. コンテキストを収集します：
    • 現在のブランチ：git branch --show-current
    • 作業ツリー：git status --short
    • 既存の PR：gh pr view --json number,title,url 2>/dev/null
    • ブランチの最近のコミット：git log main..HEAD --oneline 2>/dev/null || git log -3 --oneline
  2. チームメイトの作業と競合しないよう、重複する作業がないか確認します：
    • 同じ領域に触れているオープンな PR を一覧表示します：gh pr list --state open --json number,title,url,author,headRefName,updatedAt。また、関連する作業を検索します：gh pr list --search "<keywords>" --state open。
    • 変更されたファイルをこちらの変更と比較します（gh pr diff <number> --stat）。ファイル名が共通しているだけでなく、実際に重複しているかを判断します。
    • すでに誰かがこの作業の PR を出している場合は、競争するより、その作業を土台にすることを優先します。相手のブランチをベースにする、レビューやフォローアップのコミットで貢献する、またはこちらの変更を引き渡す方法を提案してください。アプローチが実際に異なる場合に限り、競合する PR を作成し、その際は相手の PR にリンクして、レビュー担当者が選びやすいようにこちらとの違いを説明します。
    • 意味のある重複がある場合は、作業を進める前に調査結果をユーザーに伝えます。
  3. ブランチを準備します：
    • main にいる場合は、内容がわかる名前で新しいブランチを作成します。
    • シークレットや明示的に非公開とされた内容を除き、関連する変更をコミットします。
    • ブランチをリモートにプッシュします。フォースプッシュは絶対に行わないでください。
  4. 人にレビューを依頼する前に、初回のレビューを行います。差分（git diff main...HEAD）に対して、観点を絞った複数のサブエージェントを並行して動かし、見つかった問題を具体的な修正に反映します：
    • 変更は、症状を取り繕うのではなく、明示された問題を最初から最後まで実際に解決していますか？
    • コードベースは変更前より良くなっていますか？名前はわかりやすく、不要なコードや重複コードがなく、便乗した変更によるリグレッションもありませんか？
    • レビュー担当者が指摘しそうな、奇妙な抽象化、時期尚早な汎用化、不要なコードはありませんか？より小さく、直接的な実装を優先します。
    • 差分で追加されたコメントを見直し、../write-pr/SKILL.md の「コメントの見直し」に従って、隣接箇所に古い記述が残っていないか確認します。更新時には、PR 作成後にブランチへ追加された変更を確認できます。長期運用されているブランチでは、その大部分が対象になります。
    • 明らかに修正すべき点は修正し、人によるレビューを始める時点で差分の質を高めておきます。プロダクトや設計上の判断が必要な指摘は、推測で対応せずユーザーに確認します。
    • この確認で修正した内容をコミットしてプッシュし、PR の作成、更新、共有前にリモートブランチへ反映します。フォースプッシュは絶対に行わないでください。
  5. PR がない場合は、gh pr create で作成します。
  6. PR がある場合は、gh pr view --json title,body,labels,number で内容を読み、変更ファイルの概要を gh pr diff --stat で確認します。
  7. 既存の PR が現在の差分または write-pr の基準に合っていない場合は、gh pr edit でタイトルまたは本文を更新します。
  8. 関連するイシューを検索し、該当する場合は Closes #123 または Relates to #123 を PR の説明に記載してリンクします。
  9. PR の URL をユーザーに共有します。

問題への対処

コミット時にはフックが自動的に実行されます。フォーマット、lint、型、インポートに関する問題は、機械的に修正できる場合は修正してください。

フックの失敗に、プロダクトや実装に関する重要な判断が必要な場合は、作業を中断してユーザーに進め方を確認してください。

強制コミットやフォースプッシュは絶対に行わないでください。

ルール

  • PR の内容に関するすべての基準について、../write-pr/SKILL.md に従ってください。
  • コミットメッセージ、PR のタイトル、PR の説明に、AI による貢献を記載しないでください。
  • 自分自身や AI ツールを共同作成者として追加しないでください。

コメント

Markdown 対応