shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringNo API key required

"git-diff-requirement"

Analyzes git diff HEAD to evaluate code changes against business requirements, detects defects, and generates structured analysis reports. Invoke when reviewing code changes or validating requirement implementation.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

Git Diff Requirement Analyzer

通过分析 git diff HEAD 的内容，系统性地评估代码变更与业务需求的匹配度，识别潜在缺陷并生成结构化分析报告。

When to Use

在以下情况下调用此技能：

  • 用户想要审查代码变更是否满足需求
  • 用户请求分析 git diff 或代码变更
  • 用户希望验证代码实现的完整性
  • 用户询问"变更是否正确"、"是否遗漏了什么"
  • 提交代码前的最终检查
  • Code Review 场景

Execution Workflow

Phase 1: 变更内容获取与解析

Step 1.1: 执行 Git Diff 命令

git diff HEAD

Step 1.2: 解析 Diff 输出

  • 识别所有变更的文件列表
  • 分类统计：新增文件、修改文件、删除文件
  • 提取每个文件的具体变更内容（新增行、删除行、修改行）
  • 识别变更涉及的函数/方法/类

Step 1.3: 生成变更摘要 输出格式：

📁 变更文件统计
├── 新增文件: X 个
├── 修改文件: Y 个
├── 删除文件: Z 个
└── 总变更行数: +A / -B

📄 变更文件列表
├── [新增] path/to/new_file.go
├── [修改] path/to/modified_file.go (+10/-5)
└── [删除] path/to/deleted_file.go

Phase 2: 需求推断与确认

Step 2.1: 基于代码变更推断需求 分析变更内容，推断可能的业务需求：

  • 分析新增的数据结构（struct/class/interface）
  • 分析新增或修改的 API 端点
  • 分析数据库迁移文件
  • 分析业务逻辑的变化
  • 分析配置变更
  • 分析测试用例的变化

Step 2.2: 生成需求摘要并确认 输出推断的需求摘要，使用以下格式：

🎯 推断的业务需求

根据代码变更分析，推断本次变更旨在实现以下需求：

1. 【主要需求】<需求描述>
   - 依据：<从哪些代码变更推断出>

2. 【次要需求】<需求描述>
   - 依据：<从哪些代码变更推断出>

---
⚠️ 请确认以上需求理解是否正确？
- 如有偏差，请提供准确的需求描述
- 如有补充，请提供额外的需求点

IMPORTANT: 必须等待用户确认需求后再继续后续分析

Phase 3: 业务上下文关联分析

Step 3.1: 识别相关代码上下文 使用 codebase_search 和 grep_search 工具：

  • 查找变更函数/方法的调用方
  • 查找变更类/结构体的使用位置
  • 查找相关的业务逻辑实现
  • 查找相关的配置和常量定义

Step 3.2: 分析业务一致性 检查以下方面：

  • 变更是否与现有业务逻辑保持一致
  • 命名规范是否符合项目惯例
  • 数据流是否完整
  • 错误处理是否与现有模式一致
  • API 契约是否兼容

Step 3.3: 输出上下文分析结果

🔗 业务上下文分析

1. 关联组件
   - <组件名>: <关联关系描述>

2. 数据流分析
   - 入口: <数据入口点>
   - 处理: <处理流程>
   - 出口: <数据出口点>

3. 一致性评估
   - ✅ <一致的方面>
   - ⚠️ <需要注意的方面>

Phase 4: 完整性验证

Step 4.1: 需求覆盖度检查 针对每个确认的需求点，检查：

  • 是否有对应的实现代码
  • 实现是否完整（前端/后端/数据库/配置）
  • 是否有对应的测试用例

Step 4.2: 层级完整性检查 根据项目架构，检查各层是否完整：

  • [ ] 数据层（Model/Entity/Migration）
  • [ ] 数据访问层（Repository/DAO）
  • [ ] 业务逻辑层（Service/Handler）
  • [ ] 接口层（Controller/API/Router）
  • [ ] 配置层（Config/Constants）
  • [ ] 测试层（Unit Test/Integration Test）

Step 4.3: 输出完整性报告

✅ 完整性验证报告

需求覆盖度: X/Y (Z%)

| 需求点 | 实现状态 | 测试覆盖 | 备注 |
|--------|----------|----------|------|
| 需求1  | ✅ 完整  | ✅ 有    |      |
| 需求2  | ⚠️ 部分  | ❌ 缺失  | 缺少XX |
| 需求3  | ❌ 缺失  | ❌ 缺失  | 未实现 |

层级完整性:
- ✅ 数据层: 已实现
- ✅ 业务层: 已实现
- ⚠️ 接口层: 部分实现
- ❌ 测试层: 缺失

Phase 5: 缺陷检测

Step 5.1: 代码质量检查 检查以下潜在问题：

  • 空指针/空值处理
  • 边界条件处理
  • 异常/错误处理完整性
  • 资源泄漏（未关闭的连接、文件等）
  • 并发安全问题
  • SQL 注入风险
  • 硬编码问题

Step 5.2: 业务逻辑缺陷检查

  • 业务规则遗漏
  • 状态机不完整
  • 数据验证缺失
  • 权限检查缺失
  • 事务边界问题
  • 幂等性问题

Step 5.3: 兼容性检查

  • API 向后兼容性
  • 数据库迁移兼容性
  • 配置变更影响

Step 5.4: 输出缺陷报告

🐛 缺陷检测报告

发现问题: X 个 (严重: A, 警告: B, 建议: C)

### 严重问题 🔴
1. [文件:行号] <问题描述>
   - 风险: <潜在风险说明>
   - 建议: <修复建议>

### 警告问题 🟡
1. [文件:行号] <问题描述>
   - 风险: <潜在风险说明>
   - 建议: <修复建议>

### 改进建议 🔵
1. [文件:行号] <建议描述>
   - 理由: <改进理由>

Phase 6: 生成分析报告

最终输出格式：

# 📊 Git Diff 需求匹配分析报告

## 1. 变更概述
<Phase 1 的变更摘要>

## 2. 需求理解
<Phase 2 确认后的需求列表>

## 3. 上下文分析
<Phase 3 的分析结果>

## 4. 完整性评估
<Phase 4 的完整性报告>

### 需求实现匹配度: XX%
<匹配度评分和说明>

## 5. 发现的问题
<Phase 5 的缺陷报告>

## 6. 总结与建议

### 6.1 整体评估
- 变更质量: ⭐⭐⭐⭐☆ (X/5)
- 需求匹配度: XX%
- 代码完整性: XX%
- 潜在风险: 低/中/高

### 6.2 待办事项
- [ ] <需要修复/补充的事项1>
- [ ] <需要修复/补充的事项2>

### 6.3 改进建议
- <建议1>
- <建议2>

---
📅 分析时间: <当前时间>
🔍 分析范围: git diff HEAD

Best Practices

  1. 渐进式分析: 按照 Phase 1-6 的顺序执行，确保每个阶段完成后再进行下一阶段
  2. 用户确认: Phase 2 完成后必须等待用户确认需求理解是否正确
  3. 上下文关联: 充分利用代码搜索工具理解业务上下文
  4. 客观评估: 基于实际代码变更进行评估，避免主观臆断
  5. 可操作建议: 提供的建议应该具体、可执行

Notes

  • 如果 git diff HEAD 没有输出，说明没有未提交的变更，应提示用户
  • 对于大型变更，可以按文件或模块分批分析
  • 分析结果应该与项目的技术栈和架构风格保持一致
  • 如需分析指定范围的 diff，可使用 git diff <commit1> <commit2> 替代