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

pr-review

编程与开发

查看项目

更新于 10-21 16:05

技能介绍

用途

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，符合 RFC 2606）。

  2. 代码质量：遵循 Go 惯用法（Effective Go 与 Go Code Review Comments）、命名规范（未导出用 camelCase、导出用 PascalCase、接口用 -er 后缀）、文件应小于 500 行、导入顺序（标准库、第三方、内部）、避免复制粘贴、导出函数/类型需有文档注释、注释解释“为什么”而非“什么”、新代码应遵循代码库既有模式。可运行 make lint-strict 捕获问题。

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

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

  5. 文档：始终要求 PR 标题（及 squash-merge 提交）为有效的 conventional commit（feat: ...、fix: ...、feat!: ... 表示破坏性变更），release-please 据此推导版本号和 GitHub Release 说明，无需编辑 CHANGELOG.md。新功能需更新 README.md、docs/QUICK_START.md、docs/dev/IMPLEMENTATION_STATUS.md、docs/dev/API_DESIGN.md、docs/TOKEN_SCOPES.md（如需要额外 API 权限）。新资源需在 docs/resources/ 添加资源专属文档页，并在 scripts/gen-docs/gen_all.py 中添加 PLAN 条目；命令参考需通过 make docs-generate 重新生成而非手工编辑。新增 AI agent 支持需同时更新上述四个文档。

  6. 文档检查：docs/site/ 已退役，仅保留重定向存根，不应在 docs/site/_docs/ 下新增页面；不得手工编辑 <!-- GENERATED:x:start/end --> 内的生成块，若目录变化需运行 make docs-generate 并提交输出；新目录资源应出现在 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 描述和所有提交以理解意图。然后逐维度审查，每项报告状态。审查完成后按指定格式输出总结，包含维度状态表、发现的问题（带文件:行号）、非阻塞建议和最终结论（Ready to merge / Needs revisions）。要求直接、具体，区分阻塞问题与建议，不要用赞美填充审查。

适用场景

适用于需要系统化审查 Go 项目 PR 的场景，尤其是 dtctl 这类 CLI 工具。当用户要求审查 PR、检查代码是否可合并、或对功能分支做质量把关时使用。

限制

该技能针对 dtctl 项目的具体约定（如安全检查模式、文档生成流程、覆盖率目标、golden 测试等）设计，其他项目使用时相关检查项可能不适用。资料未提供该技能的安装方式、收费信息或平台支持范围。