qa-pr-requirements-analyzer

QA PR 要件アナライザー

プルリクエストの人が書いたコンテキスト（タイトル、説明、コメント、リンクされたチケット、添付画像）を確認して、元の要件を抽出し、スコープを検証したうえで、後続のスキル（qa-write-test-cases）が利用できる要件の概要を作成します。

pull-request-diff-analyzer を補完するスキルです。

スキル	入力	出力	焦点
pull-request-diff-analyzer	git diff、変更されたファイル	コード変更に基づく AC	「コードが何をするか」
qa-pr-requirements-analyzer	PR タイトル、説明、コメント、リンクされた issue	スコープ検証と AC を含む要件の概要	「PR が何を実現するべきか」

• 全体像を把握するには、両方を併用してください。
• ユーザーがコードの変更内容だけを知りたい場合は、代わりに pull-request-diff-analyzer を使用してください。

ステップ 1：PR のコンテキストを特定する

優先順位の高い順に、以下を受け付けます。

1. ユーザーのプロンプトに含まれる PR 番号または URL（例：https://github.com/org/repo/pull/1234）。
2. 現在のブランチのオープン中の PR：gh pr view --json number,title,baseRefName,headRefName,url。
3. チケットキーのみ（Jira の PRJ-123、Linear など）の場合は、チケットを分析してから、それを参照するオープン中の PR があるか確認します。

• 特定できない場合は、PR 番号／URL、ブランチ名、またはチケットキーをユーザーに尋ねてください。
• ブランチがローカルにしか存在しない場合は、プッシュするか、PR の詳細を直接提示するようユーザーに依頼してください。

ステップ 2：PR のコンテキストを読む

開発者やチームが書いた内容を収集します。コードは対象にしません。利用可能な MCP／CLI ツールを検出し、以下を取得します。

• PR のメタデータ（タイトル、説明、コメント、ラベル、マイルストーン、担当者）。有効な場合は Jira／Linear／GitHub MCP を使い、そうでなければ gh CLI を使います。
• 本文に埋め込まれた画像／図。内容を読み取ってください（画像認識に対応したエージェントを使うか、fetch で取得して説明します）。画像には、テキストでは見落とされる UI の変更、エラー状態、フローが示されていることがよくあります。
• リンクされたチケット。PR の本文とブランチ名からチケットへの参照を解析します。

チケットの内容を捏造したり、誤った情報を追加したりしないでください。

ステップ 3：リンクされたチケットを確認する

PR の説明は簡単な概要にとどまることが多く、実際の要件はチケットに記載されています。最初に利用できるツールを使ってください。

1. 有効な場合は Jira／Linear MCP を使い、issue の概要、説明、AC、コメント、リンクされた issue、添付ファイルを取得します。
2. 有効な場合は GitHub MCP を使い、リンクされた issue を取得します。
3. 代替手段として gh CLI を使います：gh issue view {N} --json title,body,comments,labels。MCP がない場合は、Jira／Linear の issue 内容をユーザーに貼り付けてもらってください。
4. アクセスできない場合は、その不足を出力に明記し、入手できた情報に基づいて続行します。

ステップ 4：スコープを確認し、曖昧さを検出する

PR の変更内容と、チケットで求められている内容を比較します。以下は提起する質問であり、コードに誤りがあるという断定ではありません。

スコープの確認 — 次の3つのリストを作成します。

• 対象範囲内 — PR で対応されたチケットの要件（説明またはコード。ステップ 5 を参照）。
• 対象範囲外 — 対応する PR の変更がないチケットの要件。このスキルで最も価値のある出力です。
• 追加（チケットに記載なし） — チケットで言及されていない PR の変更。レビュー対象として提示します（意図的か、誤って加えられたか）。

曖昧さ、エッジケース、未解決の質問 — 入手可能なコンテキストで裏付けられる問題だけを取り上げます。新しい要件を作り出したり、チケット、PR の説明、コメント、周辺のコンテキストから関連性が示されていないシナリオへの対応を、プロダクトに期待したりしないでください。 以下を確認します。

• 詳細が不足している動作 — チケットで機能が説明されているものの、重要な詳細が省かれている（例：エクスポートが必要だが、形式、命名、権限、空の状態での動作が定義されていない）。
• 未回答のコメント — PR またはチケットのコメントにある質問で、解決したことが確認できないもの。
• 要件の矛盾 — チケット、コメント、PR の説明の異なる箇所で意見が食い違っている。
• 関連する可能性のあるエッジケース — 記載された要件に関連し、期待される動作が定義されていないシナリオ。要件ではなく、質問として提示します。
  • 一般的なソフトウェア上の懸念という理由だけで、エッジケースを報告しないでください。
  • チケット、PR の説明、対象のドメイン、または議論から関連性が示されている場合に限り、エッジケースを取り上げます。

ステップ 5：影響を受けるファイルを特定する

詳細なコードレビューは行いません。それは pull-request-diff-analyzer の役割です。PR の説明またはチケットで言及されているファイルを優先します。説明でファイルが列挙されていない場合に限り、git diff {base}...HEAD --name-only で照合します。

早期終了（ソースコードの動作変更なし）： 変更されたファイルがすべてソースコード以外（*.md、docs/**、tests/**、設定ファイル、CI、依存関係、ロックファイル）の場合：

• AC を作り出さないでください。pull-request-diff-analyzer を呼び出さないでください。
• 短い要約を作成します。PR タイトル、種類（docs／chore／ci／deps）、1文の Changes、ファイルの完全な一覧を含めます。
• 次の注記を追加します：> No source code behavior changed. Acceptance criteria generation is not applicable for this PR.
• ここで終了します。

PR の説明が空： 本文がなく、ブランチ名から意図を読み取れない場合：

• git log {base}..HEAD --pretty=format:"%s%n%b" を実行します。
• 変更ファイルとブランチ名を組み合わせて、暫定的な1文の Changes を作成します。
• 次の注記を付けます：> PR description was empty. Summary derived from branch name, commits, and changed files only.
• 関連するチケットがある場合は、チケットを優先的な情報源とし、空の本文について「曖昧さ」に記載します。

ステップ 6：要件の要約を作成する

元のプロンプトで保存が明示的に要求されている場合に限り、.md ファイルに保存します。 ユーザーが指定したフォルダーに書き込みます。

ファイル名：PR タイトルをスラッグ化します（小文字、ハイフン区切り、特殊文字なし、最大40文字）。その後ろに PR 番号を付けます。例：Add user export to CSV → add-user-export-to-csv-pr-1234.md。

出力テンプレート（記入例：summary-example.md）：

## PR Requirements Summary

**PR:** {title}
**Branch:** {headRefName} → {baseRefName}
**Type:** {feature | bugfix | refactor | deps}
**Linked Tickets:** ... (only if any exist)

**Source of Truth:**
- PR description: {present | empty — derived from commits/branch}
- Jira/GitHub ticket: {resolved | not resolved — no MCP available}
- Most reliable source: {PR description | ticket | commits}

**Changes Overview:** ... (1-2 sentences — intent, not implementation)

**Impacted Areas:**
- Payment processing (6 source files)
- Billing configuration (2 config files)
- ... (bullet list, only meaningful business/technical impact; omit if empty)

**High Level Key files (up to 5):**
- `path/to/file.ts` — source
- ... (categorized: source | config | test | docs | migration | deps)

**Scope Verification:**
- ✅ In scope: {ticket requirement → where in PR it is addressed}
- ⚠️ Out of scope: {ticket requirement not addressed in PR}
- ➕ Extra (not in ticket): {change present in PR but not in ticket}

**Ambiguities, Edge Cases & Open Questions:**
- ... (underspecified behavior / unanswered comment / conflicting requirement / missing edge case)
- ... (empty input / permissions / error path / performance / backward compatibility / ...)
- ...

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

要約のルール：

• 簡潔で、概要レベルかつ要件中心にします。これは要件文書であり、コードレビューではありません。
• Changes Overview は1～2文にします。
• Impacted Areas は意味のある箇条書きにします。内容がない場合はセクションを省略します。
• Source of Truth は必須です。情報源同士が食い違う場合に、後続のスキルがどの情報を優先すべきかを示します。
• Acceptance Criteria はテスト可能でユーザー視点の内容とし、「操作 → 期待される結果」の形式で記述します。ソースコードの動作に変更がない場合は、このセクションをステップ 5 の明示的な「該当なし」の注記に置き換えます。
• 空のセクションは None／N/A と記載せず、省略します。ただし、「ソースコードに変更なし」の注記は明示する必要があります。
• 「コードの整理」「軽微な修正」「さまざまな改善」のような一般的な表現は避けます。変更内容を具体的に示すか、省略します。

参考資料

説明	ファイル
出力サマリーの記入例	summary-example.md
.testeiya/ ディレクトリの規約	../scan-automation-project/SKILL.md
コードに焦点を当てた PR 分析（関連スキル）	../pull-request-diff-analyzer/SKILL.md
後続処理：要件からテストケースを生成	../qa-write-test-cases/SKILL.md
後続処理：生成したケースを Testomat.io と同期	../sync-test-cases-with-tms/SKILL.md