代码评审与提交助手

解决什么问题

在多人协作的代码仓库中，Pull Request 的审查往往依赖个人经验，导致安全漏洞或性能瓶颈被遗漏。同时，编写符合团队规范的 commit message 和 PR description 既耗时又容易出现格式不统一的问题。

核心能力与工作流程

• 代码审查：

- 确定范围：区分单文件、多文件或整个 PR 的审查目标，必要时提出澄清问题。
- 按优先级检查：
1. 安全：检查 SQL injection、硬编码密钥、不安全的反序列化等。
2. 性能：排查 N+1 查询、不必要的循环或内存泄漏。
3. 代码质量：规范命名、控制函数长度（>50 行建议重构）、消除死代码。
4. 可维护性：关注文档覆盖率、测试用例和错误处理策略。
- 结构化输出：生成包含问题优先级、文件位置和修复建议的 Markdown 表格，并提供 ❌ Bad / ✅ Good 代码对比。

• 提交信息生成：

- 读取 git diff --staged 或 git diff 分析变更。
- 遵循 Conventional Commits 规范（如 feat, fix, refactor）。
- 标题控制在 50 字符以内，正文每行不超过 72 字符，支持简单、详细或多 commit 拆分。

• PR 描述生成：

- 自动填充 Key Changes、How to Test、Checklist 等标准段落，明确关联的 Issue。

适用边界与注意点

• 该技能依赖静态文本分析，无法执行代码，因此不能替代 CI/CD 流水线中的自动化测试或深度安全扫描。
• 对于极其复杂的业务逻辑，修复建议可能需要开发者结合上下文进一步验证。
• 开发者仍需在本地手动执行 git add 等 Git 命令，技能本身不直接修改文件系统或 Git 状态。