mcpField
D
detailed-pr-description

detailed-pr-description

github.com/biw開発2800 回インストール4 週間前に更新
リポジトリ

detailed-pr-description について

リポジトリの根拠に基づき、テスト範囲を評価して詳細なプルリクエスト説明を作成するスキルです。評価、ローカルでの下書き、GitHub の更新を分け、明示的な依頼がある場合のみ更新します。

主な機能

  1. 01根拠に基づく PR 評価
  2. 02テスト範囲と不足の分析
  3. 03GitHub を変更しない下書き
  4. 04明示的な許可後の更新
  5. 05変更コード抜粋を本文に記載

活用シーン

  1. 01プルリクエストのテスト評価
  2. 02レビュー向け PR 説明の準備
  3. 03明示的な許可後の PR 更新

インストール

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

$npx skills add https://github.com/biw/skills --skill detailed-pr-description

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

同梱ファイルagents/openai.yamlassets/pr-body.md.tmpl

詳細

詳細な PR の説明

結果を決定する

  • **評価：**ブランチのテストが十分に強固かどうかを判断します。PR の本文を作成または更新してはいけません。
  • **下書き：**提案する本文をローカルまたは回答内に作成します。GitHub は変更してはいけません。
  • **更新／投稿：**更新、編集、投稿、または公開を明示的に依頼された場合に限り、下書きを作成して GitHub を更新します。

複数の結果を依頼された場合は、それぞれを実行します。CLI を利用できることは、PR を変更する許可を意味しません。

ワークフロー

  1. PR とベースブランチを特定します。優先して gh pr view --json number,title,body,baseRefName,headRefName,url を使用します。PR がない場合は、ユーザーが指定したベース、またはリポジトリのデフォルトのベースと比較します。古い参照に依存する前に fetch します。
  2. git status --short、差分の統計とファイル名、関連するコミット、変更されたファイル、テスト、ドキュメント、マイグレーション、設定、生成された成果物から根拠を確認します。.context/ は一時作業用として扱い、有用な事実は未追跡であることを明記して再記述します。動作に関する主張の根拠として、チャットや記憶に頼ってはいけません。
  3. 問題、アプローチ、結果、意図的な対象外事項、リスク、互換性、エッジケース、運用上の注意点、マイグレーション、フラグ、クリーンアップ、レビュー時の注目点を特定します。重点的にレビューすべき箇所については、正確なファイル／行参照と説明を記載します。すべての PR 本文に、レビュー上もっとも重要な差分箇所から抜粋した実際に変更されたコード、設定、またはドキュメントを、フェンス付きコードブロックで 1 つ含めます。抜粋は最大 15 行とし、リンクだけのレビューセクションでは不十分です。
  4. 影響を受けたテストと追加されたテストを一覧にします。まず最も範囲を絞った信頼性の高いチェックを実行し、可能であれば、ドキュメントに記載されたより広範な検証も実行します。カバレッジを「十分」「一部十分」「不十分」に分類し、検出できる回帰、重要な不足、具体的な追加テストを示します。未実行または無関係なテストから確信を示してはいけません。
  5. 許可された結果のみを提示します。
    • 評価：本文を作成せず、根拠とカバレッジの判断を報告します。
    • 下書き：本文を返すか .context/pr-description.md に書き込みます。gh pr edit を呼び出してはいけません。
    • 更新／投稿：.context/pr-description.md に書き込んだ後、gh pr edit <number> --body-file .context/pr-description.md を使用します。投稿に失敗した場合は、下書きを保持し、失敗した理由を説明します。

PR 本文

下書き／更新作業では、リポジトリにより優先度の高いテンプレートがない限り、assets/pr-body.md.tmpl を読み込みます。本文は、チャットやローカルのメモがなくても単独で内容が伝わるものにします。情報価値の高い文脈を優先し、スクリーンショット、ロールアウト、マイグレーション、フラグ、パフォーマンス、アクセシビリティ、セキュリティ、リリースノートは関連する場合にのみ追加します。空のセクションを削除するのは、その内容が本当に該当しない場合に限ります。省略によって重要なレビュー観点が見えなくなるおそれがある場合は、該当なし と記載します。

品質基準

  • 主張の根拠をコード、テスト、ドキュメント、コミット、またはコマンド出力に求め、事実と仮定・判断を区別します。
  • 既存のタイトルと有用な本文の内容を維持します。ただし、置き換えたほうが明確な場合はその限りではありません。
  • 「さまざまな修正」や「動作を改善」といった表現ではなく、動作を具体的に記述します。
  • 重点的にレビューすべき箇所には、正確なファイル／行参照を記載します。実際に変更された抜粋をフェンス付きコードブロックで 1 つ含め、実質的に役立つ内容とし、15 行以内にします。
  • 失敗した検証、スキップした検証、実行できなかった検証とその理由を含めます。
  • 明示的に依頼されない限り、無関係なコード変更を行ってはいけません。

最終回答

PR が存在する場合はその URL、結果が評価・ローカルの下書き・投稿済み更新のいずれか、検証コマンドと結果、そして最終的なカバレッジ評価を報告します。許可された投稿に失敗した場合は、下書きのパスを報告します。

コメント

Markdown 対応