mcpField
D
describe-pr

describe-pr

github.com/parcadei開発3.9k501 回インストール39 週間前に更新
リポジトリ

describe-pr について

describe-pr は、リポジトリの形式に沿った Pull Request の説明を作成するスキルです。ローカルテンプレートを読み、変更やメタデータを収集して検証項目を確認し、説明を保存・更新します。

主な機能

  1. 01リポジトリの PR テンプレートを読む
  2. 02Pull Request を検索して確認
  3. 03差分、コミット、推論記録を確認
  4. 04テンプレートの検証手順を実行
  5. 05PR の説明を保存・更新

活用シーン

  1. 01オープン中の PR の説明作成
  2. 02変更後の PR 説明の更新
  3. 03PR 更新前の検証項目の確認

インストール

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

$npx skills add https://github.com/parcadei/continuous-claude-v3 --skill describe-pr

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

詳細

PR の説明を生成する

リポジトリの標準テンプレートに沿って、包括的なプルリクエストの説明を作成してください。

手順：

  1. PR の説明テンプレートを読む：

    • まず、thoughts/shared/pr_description.md が存在するか確認します
    • 存在しない場合は、thoughts/shared/pr_description.md に PR の説明テンプレートを作成する必要があることをユーザーに伝えます
    • テンプレートを注意深く読み、すべてのセクションと要件を把握します

  2. 説明する PR を特定する：

    • 現在のブランチに関連付けられた PR があるか確認します：gh pr view --json url,number,title,state 2>/dev/null
    • 現在のブランチに PR がない場合、または main/master ブランチにいる場合は、オープン中の PR を一覧表示します：gh pr list --limit 10 --json number,title,headRefName,author
    • 説明する PR をユーザーに尋ねます

  3. 既存の説明を確認する：

    • thoughts/shared/prs/{number}_description.md がすでに存在するか確認します
    • 存在する場合は内容を読み、更新することをユーザーに伝えます
    • 前回の説明の作成後に変更された内容を確認します

  4. PR の情報を網羅的に収集する：

    • PR の差分全体を取得します：gh pr diff {number}
    • デフォルトのリモートリポジトリがないというエラーが発生した場合は、gh repo set-default を実行して適切なリポジトリを選択するようユーザーに伝えます
    • コミット履歴を取得します：gh pr view {number} --json commits
    • ベースブランチを確認します：gh pr view {number} --json baseRefName
    • PR のメタデータを取得します：gh pr view {number} --json url,title,number,state

4b. 推論の履歴を収集する（利用可能な場合）：

  • 推論ファイルが存在するか確認します：ls .git/claude/commits/*/reasoning.md 2>/dev/null
  • 存在する場合は、内容を集約します：bash "$CLAUDE_PROJECT_DIR/.claude/scripts/aggregate-reasoning.sh" main
  • これにより、最終的な解決策に至るまでに試したアプローチがわかります
  • PR の説明に含めるため、出力を保存します

  1. 変更を徹底的に分析する：（コード変更、そのアーキテクチャ上の影響、潜在的な影響について深く考えます）

    • 差分全体を注意深く確認します
    • 内容を把握するため、差分に表示されていない参照先のファイルも読みます
    • 各変更の目的と影響を理解します
    • ユーザー向けの変更と内部実装の詳細を特定します
    • 破壊的変更や移行要件がないか確認します

  2. 検証要件に対応する：

    • テンプレートの「検証方法」セクションにチェック項目があるか確認します
    • 各検証手順について：
      • 実行可能なコマンド（make check test、npm test など）の場合は実行します
      • 成功した場合は、チェックボックスにチェックを入れます：- [x]
      • 失敗した場合は、チェックを入れず、失敗した内容を記載します：説明を添えて - [ ]
      • 手動テスト（UI 操作、外部サービスなど）が必要な場合は、チェックを入れず、ユーザーが実施する必要がある旨を記載します
    • 完了できなかった検証手順を記録します

  3. 説明を作成する：

    • テンプレートの各セクションを十分に埋めます：
      • 分析に基づいて、各質問やセクションに回答します
      • 解決した問題と加えた変更を具体的に記載します
      • 該当する場合は、ユーザーへの影響を重視します
      • 適切なセクションに技術的な詳細を記載します
      • 簡潔な変更履歴を記載します
    • 推論ファイルが見つかった場合（手順 4b）：
      • 「## 検証方法」の前に「## 試したアプローチ」セクションを追加します
      • 失敗した試みとそこから得られた知見を含め、集約した推論を記載します
      • これにより、レビュー担当者は最終的な結果だけでなく、そこに至る過程も把握できます
    • すべてのチェック項目に対応したことを確認します（チェックを入れるか、説明を記載します）

  4. 説明を保存する：

    • 作成した説明を thoughts/shared/prs/{number}_description.md に書き込みます
    • 作成した説明をユーザーに表示します

  5. PR を更新する：

    • PR の説明を直接更新します：gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md
    • 更新が成功したことを確認します
    • 未チェックの検証手順が残っている場合は、マージ前に完了するようユーザーに伝えます

重要な注意事項：

  • このコマンドは複数のリポジトリで使用できるため、必ずローカルのテンプレートを確認してください
  • 内容は十分に盛り込みつつ、簡潔にまとめてください。説明はざっと確認できるようにしてください
  • 「何を」だけでなく、「なぜ」も重視してください
  • 破壊的変更や移行に関する注意事項がある場合は、目立つように記載してください
  • PR が複数のコンポーネントにまたがる場合は、それに応じて説明を整理してください
  • 可能な限り、検証コマンドを実行してください
  • 手動テストが必要な検証手順を明確に伝えてください

コメント

Markdown 対応