SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场pr-review

pr-review

编程与开发

查看项目

更新于 10-15 02:02

技能介绍

用途

pr-review 用于在合并前对 Pull Request 或功能分支执行一次全面的质量审查，覆盖生产就绪性、代码质量、用户体验、文档、测试与安全性。审查以七个维度的清单形式组织，每个维度都要求查看实际代码并给出具体发现，而不是简单地说“看起来不错”，需要附带文件路径和行号。

主要能力

审查按以下七个维度逐项进行，并为每个维度给出状态：Pass（达标）、Needs work（发现问题，需列出）或 N/A（不适用）。

  1. 生产就绪性：检查错误处理（是否检查所有错误、是否用 fmt.Errorf("context: %w", err) 包装、是否向用户暴露可操作的错误信息）、边界情况（空输入、nil 值、缺失配置、网络失败、API 限流、大数据集、分页边界）、安全校验（所有变更类命令在 LoadConfig() 之后、客户端操作之前必须包含安全检查，并验证操作类型正确，仅 dry-run 路径可跳过）、库代码不得向 stdout 打印（pkg/ 只返回数据，输出由 cmd/ 处理）、不得硬编码密钥或客户数据（邮箱使用 @example.invalid）。

  2. 代码质量：遵循 Go 惯用法与 Go Code Review Comments；命名符合 Go 约定（未导出用 camelCase、导出用 PascalCase、接口用 -er 后缀）；文件应小于 500 行；导入顺序为标准库、第三方、内部包；查找可提取的重复代码；导出函数/类型需有文档注释，注释解释“为什么”而非“做什么”；新代码应遵循代码库既有模式。可运行 make lint-strict 捕获问题。

  3. 用户体验：命令命名遵循 dtctl <verb> <resource> 模式，不使用自定义查询标志而用 DQL 透传；表格输出可读、列对齐，JSON/YAML 输出干净；错误信息清晰可操作，在 agent 模式（-A）下为带机器可读代码的结构化 JSON；交互行为（名称解析、消歧提示）正常，--plain 可禁用交互；帮助文本包含 Short、Long 和 Example 字段；资源有合理别名；命令支持 --agent 信封与上下文建议；颜色控制尊重 NO_COLOR、FORCE_COLOR、--plain 和 TTY 检测。

  4. 测试覆盖：新函数有测试，优先表驱动测试；覆盖率目标为整体最低 70%、新包 80%、关键包（pkg/client、pkg/config）90%；测试边界情况而非仅正常路径；分页 mock 服务器必须拒绝无效参数组合，Settings API mock 也必须拒绝 schemaIds/scopes 与 nextPageKey 的组合；若输出格式变化或新增资源，必须更新 golden 文件（golden 测试使用 pkg/resources/* 中的真实生产结构体，不得使用仅测试用的副本）；新资源或复杂工作流需在 test/e2e/ 中添加集成场景。

  5. 文档：PR 标题（及 squash-merge 提交）必须是有效的 conventional commit（feat:、fix:、feat!: 等），release-please 据此推导版本号与发布说明，没有 CHANGELOG.md 需要编辑。新功能需更新 README.md、docs/QUICK_START.md、docs/dev/IMPLEMENTATION_STATUS.md、docs/dev/API_DESIGN.md、docs/TOKEN_SCOPES.md（视情况）。新资源需在 docs/resources/ 添加资源专属文档页，并在 scripts/gen-docs/gen_all.py 中添加 PLAN 条目；命令参考通过 make docs-generate 重新生成而非手工编辑。新增 AI agent 支持需同时更新上述四个文档。

  6. 文档检查：docs/site/ 已退役，仅保留重定向存根，不应在 docs/site/_docs/ 下新增页面；不得手工编辑 <!-- GENERATED:x:start/end --> 内的生成块；新目录资源应出现在 scripts/gen-docs/INDEX.md 的某个页面下而非未映射列表；make docs-check 必须通过（每个文档化的 dtctl 命令可解析、每个标志存在）；相对链接可解析且锚点存在。

  7. PR 描述：标题清晰且符合 conventional commit 风格；摘要说明改了什么以及为什么；用 Closes #NNN 或 Fixes #NNN 引用相关 issue；明确标注破坏性变更；包含测试说明；面向用户的变更提供前后 CLI 输出示例。

使用方式

首先理解变更范围，可运行：

git branch --show-current git log main..HEAD --oneline git diff main...HEAD --stat git diff main...HEAD

若审查远程 PR，先获取：

gh pr view <number> --json title,body,files gh pr diff <number>

在深入代码前，先阅读 PR 描述和所有提交以理解意图。随后按七个维度逐项审查，并运行相关命令验证，例如 make lint-strict、go test ./...、make test-coverage、go test ./pkg/output/ -run TestGolden、make docs-check，以及实际运行命令查看帮助文本、表格输出和 agent 模式效果。

审查完成后按指定格式输出总结：一个包含七个维度状态与备注的表格、按维度列出带 file:line 的问题、非阻塞建议，以及最终结论（Ready to merge 或 Needs revisions 并列出阻塞项）。要求直接、具体，区分阻塞问题与建议，不堆砌赞美。

适用场景

适用于 Go 语言项目（尤其是 dtctl 这类 CLI 工具）在合并 PR 或功能分支前的系统性代码审查，帮助团队以可重复的清单方式覆盖生产就绪性、代码质量、用户体验、测试、文档和 PR 描述等方面。

限制

该技能内容高度针对 dynatrace-oss/dtctl 项目，包含大量项目特定的约定（如 dtctl 命令模式、pkg/ 与 cmd/ 的职责划分、安全检查模式、docs/site/ 退役状态、release-please 流程等），直接用于其他项目时需相应调整。资料未提供该技能的安装方式、收费模式、支持平台或实际效果等信息。