mcpField
I
implement-pr

implement-pr

github.com/falcondev-oss开发2134 次安装5 天前更新
代码仓库

关于 implement-pr

Implement PR 是开发技能，帮助将代码变更从关联事项推进到验证、审查和可合并的拉取请求。它通过明确契约、针对性检查和迭代审查反馈组织流程。

主要功能

  1. 01分配关联工作事项
  2. 02明确范围与验收证据
  3. 03实现针对性变更和测试
  4. 04运行仓库验证检查
  5. 05使用子 Agent 审查差异
  6. 06跟进 CI 与审查直至就绪

适用场景

  1. 01将关联问题推进为拉取请求
  2. 02依据保留行为检查变更
  3. 03准备通过审查且 CI 通过的拉取请求

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/falcondev-oss/skills --skill implement-pr

安装后在 Claude Code 中输入/implement-pr确认已加载。

附带文件agents/openai.yaml

详细介绍

实现 PR

全程负责这项更改，直到 PR 通过检查并可供审查。完成的标准是 PR 已准备好合并，而不是代码已经写完。

1. 认领关联工作

使用 gh issue view <number> --json title,body,labels,state,comments 阅读每个关联的 GitHub issue。

对于每个关联的工单或工作项，在实施前记录认领信息：使用跟踪器的负责人字段，将该项分配给当前已认证用户。如果无法分配，则使用跟踪器明确提供的认领或进行中机制。

2. 明确约定

运行 git fetch origin <base-branch>，确保规划基于最新的基础分支。编辑前，阅读请求、关联工单或规范、仓库说明以及相关代码。将简短的工作约定和任务清单写入 Git 忽略文件（如果单独运行 git check-ignore -q .claude/tasks.md 这一命令并以 0 退出，则使用 .claude/tasks.md）。完成项目后勾选，并在发现新事项时添加；压缩上下文后，重新阅读该文件，而不是依赖摘要。如果代码已存在（在迭代循环后调用），则根据现有差异编写约定。约定包含以下五个部分：

  • 结果： 必须实现的可观察行为。
  • 保留： 必须保持不变的行为和接口。对于以提升性能为目标的工作，还要包括性能要求。
  • 范围： 请求允许更改的文件、包和系统。
  • 证据： 用于证明目标和保留行为的针对性检查；对于以提升性能为目标的工作，还要包括基准测试。
  • 完成标准： PR、必需的 CI，以及所要求的审查状态。

通过检查或低成本实验，核实仓库和外部事实。默认选择应遵循现有模式。

3. 实施最小且完整的更改

遵循仓库惯例并复用既有接口。只添加约定要求的行为。从最底层的更改边界到最高层的使用方，都要确保类型准确。

了解约定中的待解决问题所需的信息，然后开始编辑。一旦继续阅读也不会改变计划，就完成阅读并开始实施。

在稳定的行为接口处添加有针对性的测试。跳过仅用于记录已删除行为、重复类型检查或复述实现细节的测试。

对于视觉或交互功能，使用浏览器、Android 模拟器或 iOS 模拟器检查受影响的状态和响应式行为。为 PR 留存所需证据。

4. 验证

审查前，运行仓库文档中针对受影响包的完整测试、类型检查、Lint 和构建命令，包括聚合 check 脚本未包含的测试套件。在 PR 中记录命令和结果。审查后或修复 CI 问题后，只重新运行修复涉及的检查；CI 会运行完整矩阵。

5. 审查冷启动

审查成本随差异内容的规模而变化。每位审查者都是全新的后台子代理，会收到差异命令、契约文件路径，以及其审查维度所需的内容；$spec-review 还会收到关联的工单。每个子代理的完成通知都是唤醒信号。

基准分支。 再次运行 git fetch origin <base-branch>，并针对 origin/<base-branch> 比较差异。工作树的本地基准分支落后于远程分支，会把无关提交纳入差异。审查差异命令为 git diff origin/<base-branch>...HEAD。

深度。 使用 git diff --shortstat origin/<base-branch>...HEAD 衡量差异规模：

  • 轻量： 删除、重命名或调整配置、文案或文档，且未新增行为的变更行数少于约 50 行。只运行 $bug-review。
  • 全面： 其他所有情况，以及任何涉及身份验证、权限、资金、持久化数据或迁移、并发或公共接口的差异，无论规模大小。运行 $bug-review、$spec-review 和 $simplicity-review。

将发现视为假设：

  1. 根据契约和当前代码核实每项发现。
  2. 修复所有有效且在范围内的发现。只有差异未触及的代码才属于范围外；差异新增行中的缺陷属于范围内。
  3. 记录误报和范围外发现，不改动现有变更。
  4. 重新运行受修复影响的检查。
  5. 仅重新派发其发现推动了修复的审查者，并提供修复代码块（git diff <reviewed-sha>..HEAD）以及其先前的发现和你的判定。重复此过程，直到某一轮没有提出新问题，同时不得超过各审查者的轮数上限。

轮数上限。 $bug-review 和 $spec-review：3 轮；若安全问题（身份验证、权限、数据泄露、注入）推动了修复，则为 5 轮。$simplicity-review：1 轮。

完成条件：契约文件中已为每项发现记录判定（已修复、误报或范围外）。

6. 提交 PR 并跟进

提交完整变更，将其推送，然后使用 $file-pr 技能创建 PR。

使用 $babysit-pr 技能跟进，直到所需 CI 和审查自动化检查全部通过。处理审查反馈；每次修复后，重新运行受其影响的验证。

只有在 PR 已可合并或仍有外部阻碍时才结束，并输出 PR URL。

评论

支持 Markdown