mcpField
T
tenzir-create-pull-requests

tenzir-create-pull-requests

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

tenzir-create-pull-requests について

現在の作業ツリーから Pull Request を作成する Tenzir のスキルです。関連課題の確認、PR の作成、変更履歴やドキュメント更新との連携、ブランチのプッシュを案内します。

主な機能

  1. 01関連課題と PR の確認
  2. 02現在のブランチから PR を作成
  3. 03tenzir-ship による変更履歴の調整
  4. 04関連ドキュメント PR の連携
  5. 05定型の PR 本文とフッター

活用シーン

  1. 01Linear の課題に紐づくコード PR の作成
  2. 02変更履歴とコード変更の整合
  3. 03関連ドキュメント PR の調整

インストール

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

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

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

詳細

プルリクエストの作成

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

ワークフロー

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

追加の編集を行う場合は、変更した機能と変更履歴エントリの整合性を維持してください。変更履歴ファイルを手動で編集せず、 エントリの更新には tenzir-ship を使用します。

PR フッター

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

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

Linear では、フッターに専用のマジックワードを明記します。

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

フッターの例:

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

PR 本文

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

## 🔍 Problem



## 🛠️ Solution



## 💬 Review




指示:

  • 対象読者はシニアソフトウェアエンジニアです。簡潔に要点をまとめます。
  • 各 HTML コメントを簡潔な説明に置き換えます。
  • 長い文章より箇条書きを優先します。
  • 差分を見ればわかるため、変更したファイルの説明は不要です。
  • Issue トラッカーが確実に解析でき、関連 PR のリンクが視覚的にまとまるよう、フッターは PR 本文の末尾に配置します。

コメント