pull-request-diff-analyzer

拉取请求差异分析器

分析 git 差异或 PR，以检测变更类型并提取供人工测试的验收标准。仅进行分析——绝不修改代码。

步骤 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}

如果符合以下条件，跳至步骤 3，仅提供简短摘要（不含验收标准）：

• 当前分支是 master、main、stable，或 baseRefName 中检测到的默认分支。
• 没有文件变更。
• 所有变更都属于非源代码更新：
  • 文档/需求（*.md、docs/**）
  • 测试更新和测试文档（*.test.md、test-flows/**、tests/e2e）
  • CI/CD 和基础设施配置（.github/workflows/**、Jenkinsfile）
  • lint/格式化工具/工具链配置
  • 不影响行为的依赖版本升级
• 应用程序/源代码的行为没有变化。

如果源代码发生变化（src/**、lib/**、app/**，或根目录中的 .ts/.js/.tsx/.jsx/.java/.py/.go/.rb/.php/.cs/.kt/.swift/.rs 等文件），继续执行步骤 2。

步骤 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/组件更新。
• 差异内容已提供足够上下文，可据此自信地编写验收标准。
• 变更仅涉及文档、需求、测试、配置或非源代码更新。
• 项目似乎不包含人工测试。
• 现有测试清单与当前任务无关。

如果该工具不可用：

• 继续执行，不检查现有测试。
• 在验收标准输出中添加以下说明：未检查人工测试清单——如有需要，请手动确认现有测试。

仅将扫描结果用于：

• 避免重复已有的人工测试用例。
• 了解项目结构、框架和测试组织方式。
• 提高生成的验收标准的相关性和一致性。

步骤 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”必须是一句话，不得写成段落。
• “Impacted Areas”仅列出有意义的业务或技术影响。
• 省略空白章节，不要写 None 或 N/A。
• 验收标准必须可测试，且以用户为中心。
• 避免使用“代码清理”“小修小补”或“各种改进”等笼统表述。
• 不要逐行描述实现细节。