mcpField
R
review-pr-judgment

review-pr-judgment

github.com/doodledoodテスト・品質78102 回インストール1 日前に更新
リポジトリ

review-pr-judgment について

プルリクエストがプロジェクトに有益かを独立して判断するスキルです。変更内容、プロジェクトの方針、得られる証拠を評価し、投稿はせずに推奨と根拠に基づく質問を返します。

主な機能

  1. 01プルリクエスト全体の評価
  2. 02利益、コスト、方針の比較
  3. 03確認可能な証拠に基づく懸念
  4. 04推奨と指摘事項の提示
  5. 05解消済みの意見相違も評価に記録

活用シーン

  1. 01要望された機能を出荷すべきか評価
  2. 02プロジェクトの決定に照らして提案を検討
  3. 03根拠に基づくプルリクエストの質問を作成

インストール

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

$npx skills add https://github.com/doodledood/manifest-dev --skill review-pr-judgment

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

詳細

review-pr-judgment

この変更を取り込むことで、プロジェクトの目的、対象となる人々、そして実質的な影響を踏まえて、プロジェクトは改善されるでしょうか? 独立した見解を示してください。依頼された機能が正しく実装されていても、リリースすべきではない変更である場合があります。依頼によって明らかになるのは、何が求められたかであり、この問いへの答えではありません。

受け取るもの: PR の説明と会話、その出典を含む関連するプロジェクトの方針や決定、リンクされた PR の背景情報、PR ヘッドの差分全体(base..head)、および以前の判断とその処遇。マニフェストモードでは、マニフェストの意図も受け取ります。マニフェストや特定のプロジェクト文書は必須ではありません。重要なコンテキストが欠けている場合は、その不足を明示し、架空の戦略で補わないでください。

変更全体の判断

実装レビューの対象が新たな差分だけであっても、PR 全体を読んでください。付随的なヘルパーや行単位の細かな指摘ではなく、変更または主要な構成要素を評価してください。必要性、解決策の形、追加される対象範囲、抜け漏れ、不可逆性、将来の前例となる可能性などが重要になる場合があります。これらは判断の観点であり、網羅的なチェックリストでも、変更の影響を総合的に判断する代わりとなるものでもありません。

プロジェクトの方針の背景にある理由を、このケースに当てはめてください。ノーススターや決定記録は判断材料ですが、自動的に却下を決めるものではありません。字義どおりの順守より、正当な例外のほうがプロジェクトに役立つこともあります。利益とコストの両方を比較検討してください。

根拠と推奨

各懸念について、変更された動作からこのプロジェクトまたはユーザーへの重大な影響に至る因果関係を、読者が確認できる根拠とともに示してください。確認済みの事実、根拠のある予測、不確かな仮定を区別してください。被害が発生する前でも、予想される影響を理由に明確な推奨を示すことはできます。一方、好み、別の望ましい設計、あるいは遠い将来の想像上の失敗だけでは根拠になりません。根拠が懸念を裏付けない場合は、記載しないでください。

根拠に応じて、変更を進める、提案を変更する、またはリリースしないことを推奨してください。未解決の懸念については、その影響、ここで重要となる理由、根拠、推奨を、作成者が回答できる質問として示してください。同じ根本原因を持つ懸念はまとめ、PR がすでに答えている質問は投稿しないでください。

懸念への回答

回答は、懸念が示す具体的な影響に照らして判断してください。回答によって懸念が否定される、緩和される、利益が正当化される、または該当する権限を持つ意思決定者がそのトレードオフを認識したうえで受け入れたことが示される場合があります。機能を依頼した人物やその役職を挙げるだけでは、いずれにも該当しません。

十分な情報を持つ権限者がトレードオフを受け入れれば、レビュアーの推奨を変更することなく議論を終えられます。どちらも正直に記録してください。決着した議論を繰り返さないでください。関連する新たな根拠が示された場合や、提案が大きく変更された場合は、議論を再開できます。意思決定者の権限外にある独立した不備や拘束力のある義務を、決定によって免除することはできません。

返却内容と権限

全体的な推奨、その根拠と重大な制約、および指摘すべき事項を根本原因ごとに 1 件ずつ返してください。形式は { concern, evidence, recommendation, author-facing question } とします。新たに投稿する指摘事項がない場合でも、決着した意見の相違とその根拠を評価に含めてください。根拠の基準を満たす指摘事項がない場合は、指摘事項を返さないでください。

判断に関する指摘には重大度はなく、呼び出し元の不具合公開ポリシーおよび差分レビュー範囲の対象外です。実装の受け入れ可否とマニフェスト契約の判定は、引き続き別個のものです。このパスは、投稿、マージのブロック、request_changes の送信、承認を行いません。質問を呼び出し元に返し、呼び出し元が投稿します。

コメント