mcpField
P
pull-request-diff-analyzer

pull-request-diff-analyzer

github.com/testomatioテスト・品質1694 回インストール6 日前に更新
リポジトリ

pull-request-diff-analyzer について

Pull Request Diff Analyzer は、Git の差分やプルリクエストを分析し、変更範囲の要約とテスト可能でユーザー視点の受け入れ基準を作成するスキルです。分析のみを行い、コードは変更しません。

主な機能

  1. 01ブランチとベースブランチの状況を特定
  2. 02変更ファイルの一覧と PR 詳細を確認
  3. 03変更を機能追加、修正、リファクタリングに分類
  4. 04ソースコードの変更を中心に分析
  5. 05簡潔な要約とテスト可能な受け入れ基準を作成

活用シーン

  1. 01ソースコードの PR に対する手動テスト基準を準備
  2. 02ローカルブランチの差分や未コミット変更を要約
  3. 03ドキュメントや設定のみの変更では詳細基準を省略

インストール

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

$npx skills add https://github.com/testomatio/skills --skill pull-request-diff-analyzer

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

詳細

Pull Request 差分アナライザー

git の差分または PR を分析して変更の種類を検出し、手動テスト用の受け入れ条件を抽出します。分析のみを行い、コードは変更しません。

Step 1: ブランチのコンテキストとスコープを検出する

現在のブランチを取得します。

git branch --show-current

ベースブランチを次の順序で検出します。

  1. PR のコンテキストから（優先）。PR 番号が分かっている場合：
gh pr view {PR_NUMBER} --json baseRefName

レスポンスの baseRefName は PR のベースブランチです。

  • ベースブランチを検出できない場合は、ユーザーに指定を求めます。

変更されたファイルを取得します。

git diff {BASE_BRANCH}...HEAD --name-only

未コミットのローカル変更のみの場合：

git diff --name-only

GitHub PR の全差分を表示する場合：

gh pr diff {PR_NUMBER}

次の場合は、簡潔な要約のみで Step 3 に進みます（受け入れ条件は含めません）。

  • 現在のブランチが master、main、stable、または baseRefName で検出されたデフォルトブランチである。
  • 変更されたファイルがない。
  • 変更がすべてソースコード以外である：
    • ドキュメント／要件（*.md、docs/**）
    • テストの更新とテストドキュメント（*.test.md、test-flows/**、tests/e2e）
    • CI/CD およびインフラ設定（.github/workflows/**、Jenkinsfile）
    • lint／フォーマッター／ツール設定
    • 動作の変更を伴わない依存関係のバージョン更新
  • アプリケーション／ソースコードの動作に変更がない。

ソースコードが変更された場合は Step 2 に進みます（src/**、lib/**、app/**、またはルートの .ts／.js／.tsx／.jsx／.java／.py／.go／.rb／.php／.cs／.kt／.swift／.rs など）。

Step 2: PR のコンテキストとファイルを分析する

PR の詳細を取得します。

gh pr view {PR_NUMBER} --json title,body,comments,reviews,issues

テストに関連する情報を抽出します。

  • タイトル — 機能／修正名、影響を受けるコンポーネント。
  • 説明 — 条件、テストシナリオ。
  • コメント — テストに関する注記、エッジケース、再現手順。

ソースコードファイルのみを分析します。

  • ディレクトリ：src/**、lib/**、app/**、controllers/**、services/**、models/**、pages/**、components/**、handlers/**、modules/** など。
  • 拡張子：.ts、.js、.tsx、.jsx、.java、.py、.go、.rb、.php、.cs、.kt、.swift、.rs
  • 設定、依存関係、テスト、ドキュメント、マイグレーション、およびソースコードに関係しないその他のファイルは除外します。

PR の種類を判定します。

  • 機能追加 — 新しいファイル、エンドポイント、コンポーネント、モジュール。
  • 修正 — バグ修正、パッチ、ホットフィックス（コミットに「fix」、「bug」、「hotfix」が含まれているか確認します）。
  • リファクタリング — 動作を変更せずにコードを再構成すること。
任意：scan-automation-project

デフォルトでは scan-automation-project を実行しないでください。 受け入れ条件を書く前に、プロジェクトの追加情報が明確に役立つ場合にのみ実行してください。

次の場合は実行します。

  • PR で新機能または大幅な機能変更が導入される。
  • 類似の手動テストがすでに存在するか確認する必要がある。
  • ユーザーから明示的に依頼された場合（「重複を確認して」、「既存のテストを教えて」など）。

次の場合は実行しません。

  • PR が小規模な修正または軽微な UI／コンポーネントの更新である。
  • 差分だけで自信を持って AC を作成できる。
  • 変更がドキュメント、要件、テスト、設定、またはソースコード以外の更新に限られる。
  • プロジェクトに手動テストが含まれていないように見える。
  • 既存のテスト一覧が依頼内容に関係しない。

利用できない場合：

  • 既存のテストを確認せずに続行します。
  • AC の出力に次の注記を追加します：Manual test inventory not checked — verify existing tests manually if needed.

スキャン結果は次の目的にのみ使用します。

  • 既存の手動テストケースとの重複を避ける。
  • プロジェクトの構造、フレームワーク、テストの構成を把握する。
  • 作成する受け入れ条件の関連性と一貫性を高める。

Step 3: 受け入れ条件を含む要約

出力形式：

## PR Diff Summary

**PR Type:** ... (feature | fix | refactor)
**Branch:** ... (branch name, e.g. feature/user-auth)
**Changes:** ... (one sentence describing the overall purpose of this PR)
**Affected Files:**
- ... (bullet list of all affected files in this PR)

**Impacted Areas:**
- ... (1-3 bullets, only real impacted files/areas in the PR)

**Acceptance Criteria:**
- action to perform → expected result
- ...

要約のルール：

  • 要約は簡潔かつ概要レベルにします。
  • 「Changes」は 1 文にします。段落にはしません。
  • 「Impacted Areas」には、ビジネスまたは技術面で意味のある影響のみを記載します。
  • 空のセクションは None や N/A と記載せず、省略します。
  • 受け入れ条件は、テスト可能でユーザー視点のものにしてください。
  • 「コードのクリーンアップ」、「軽微な修正」、「さまざまな改善」などの一般的な表現は避けます。
  • 実装の詳細を行ごとに説明しないでください。

コメント

Markdown 対応