mcpField
C
create-pull-requests

create-pull-requests

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

create-pull-requests について

現在のワークツリーのブランチからプルリクエストを作成し、変更ログをコード変更に合わせるワークフロースキルです。課題の確認、PR本文、関連ドキュメントPR、課題リンク用フッターを扱います。

主な機能

  1. 01関連する課題の確認
  2. 02現在のブランチからPRを作成
  3. 03tenzir-ship経由で変更ログを更新
  4. 04関連ドキュメントPRの調整
  5. 05機械可読な課題フッターの整形

活用シーン

  1. 01コード変更のPR準備
  2. 02PRとLinear課題の関連付け
  3. 03変更ログ項目の同期
  4. 04関連ドキュメント変更の調整

インストール

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

$npx skills add https://github.com/tenzir/skills --skill create-pull-requests

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

詳細

プルリクエストの作成

プルリクエストを作成し、変更履歴を最新の状態に保ちます。

ワークフロー

  1. 変更が一貫性のある単位でコミットされていることを確認します。ステージング、変更の分割、コミットメッセージの作成には、commit-changes スキルを使用します。
  2. PR の本文を作成する前に、現在のコンテキストを確認して関連するイシューを探します。ユーザーの依頼、前後の会話、ブランチ名、コミット メッセージ、既存の変更履歴エントリ、既存の PR テキスト、利用可能なイシュートラッカーのコンテキストを確認します。トラッカーを利用できる場合は、このコード PR でクローズすべき主要な Linear のイシューを特定します。関連するドキュメント PR では、それらを参照するだけにします。
  3. 現在のワークツリーブランチからプルリクエストを作成します。
  4. 変更履歴エントリを追加してコミットします。ここで変更履歴エントリを手動で作成または編集しないでください。エントリの生成、書式設定、更新には tenzir-ship スキルを使用します。
  5. 変更が docs.tenzir.com に記載されているユーザー向けの動作に影響する場合は、update-documentation スキルに従って関連するドキュメント PR を作成し、2 つの PR を相互にリンクして、ドキュメント PR で同じ Linear のイシューを参照します。
  6. ブランチをプッシュします。

追加の編集を行う場合は、機能の変更に合わせて変更履歴エントリを最新の状態に保ちます。変更履歴ファイルを直接編集せず、エントリの更新には tenzir-ship を使用します。

PR フッター

PR の説明を確定する前に、関連するイシューと関連する PR を必ず確認します。

  • まず現在のコンテキストを確認します。ユーザーのプロンプト、ブランチ名、最近のコミット、既存の変更履歴テキスト（ある場合）、PR のタイトルと本文の下書き、関連するドキュメント PR や後続 PR を確認します。
  • トラッカーのコンテキストを利用できる場合は、このコード PR でクローズすべきイシューを確認します。
  • PR 本文の末尾に、簡潔な <sub>...</sub> フッターを 1 つだけ記載します。
  • フッターは PR コメントではなく、PR の説明に記載します。
  • すでにフッターがある場合は、新しいセクションや 2 つ目のフッターを作成せず、既存のフッターを拡張します。
  • 簡潔で機械処理しやすい形式にします。1 行につき 1 つの指示またはリンクを記載し、行は <br> でつなぐことを推奨します。
  • 確認後も信頼できるイシュー参照や関連 PR が見つからない場合は、その行を省略するか、関連付けが重要であればユーザーに確認します。

Linear では、フッターでマジックワードを明示的に使用します。

  • メインのコード PR では、マージ時に主要なイシューが完了に向かうよう、closes などのクローズを示す語を使います。
  • この PR でクローズしない関連ドキュメント PR や二次的なイシューには、references、related to、part of など、クローズを示さない語を使います。
  • 読みやすさのために行頭に絵文字を付けてもかまいませんが、Linear のマジックワードの代わりにはなりません。キーワード自体は変更せずに記載します。
  • ブランチ名や PR のタイトルにすでにイシュー ID が含まれていても、クローズするか関連付けるかを明確にする場合は、フッターにも記載します。
  • 複数のイシューが同じ関係にある場合は、フッターを簡潔にするため、1 つのマジックワードの後に列挙します。例：✅ Closes TNZ-82, TNZ-499, TNZ-108, TNZ-109
  • 関係が異なる場合に限り、行を分けます。たとえば、closes の行と references の行を分けます。
  • 関連するドキュメント PR がある場合は、専用セクションを設けず、📚 Docs PR: tenzir/docs#261 のような行を同じフッターブロックに追加します。
  • フッターで GitHub の PR をリンクする場合は、完全な URL ではなく、tenzir/tenzir#5999 や tenzir/docs#261 のような GitHub の短縮表記を使います。特定のイシューコメントなど、短縮表記で表せない詳細なリンクに限り、完全な URL を使います。

フッターの例：

<sub>
📚 Docs PR: tenzir/docs#261<br>
✅ Closes TNZ-150, TNZ-151<br>
🎫 References TNZ-152<br>
📎 Related: tenzir/tenzir#5999
</sub>

PR 本文

プルリクエストの説明には、次のテンプレートを使用します。

## 🔍 Problem



## 🛠️ Solution



## 💬 Review

指示：

  • 対象読者はシニアソフトウェアエンジニアです。簡潔に要点を述べます。
  • HTML コメントはそれぞれ簡潔な説明に置き換えます。
  • 長い説明文より箇条書きを優先します。
  • 差分を見れば分かることを、変更したファイルの説明に費やさないでください。
  • イシュートラッカーが確実に解析でき、関連 PR のリンクがまとまって表示されるよう、フッターは PR 本文の末尾に記載します。

コメント

Markdown 対応