mcpField
T
to-pr

to-pr

github.com/yahyabedirhan开发269 次安装1 天前更新
代码仓库

关于 to-pr

to-pr 是用于为当前任务创建或更新 Pull Request 描述的技能，指导收集相关上下文、组织描述、通过 GitHub CLI 发布并提供文件评审链接。

主要功能

  1. 01检查是否已有 Pull Request
  2. 02收集任务与差异上下文
  3. 03按指定模板组织描述
  4. 04使用 gh 更新 PR
  5. 05生成变更文件链接

适用场景

  1. 01为已完成的分支工作创建 PR
  2. 02实现变更后修订 PR 描述
  3. 03编写面向评审者的变更概览

安装

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

$npx skills add https://github.com/yahyabedirhan/skills --skill to-pr

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

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

LICENSE.humanlayer
references/
describe_pr_final_answer.md
pr_description_template.md
show-me.md

详细介绍

原文在翻译后有更新，译文可能不是最新。

描述 Pull Request

为当前任务创建或更新 Pull Request，并用简洁的描述帮助审阅者了解变更缘由和实现概况。

工作流程

  1. 阅读描述模板：

    Read({SKILLBASE}/references/pr_description_template.md)

  2. 确认或创建 Pull Request：

    • 使用 gh pr view --json url,number,title,state,baseRefName,headRefName 2>/dev/null 检查当前分支是否已有 PR。
    • 如果没有 PR，检查 git status --short --branch 和当前分支上的提交。
    • 需要时提交与任务相关的变更，为分支设置上游并推送，然后为其创建 PR。遵循仓库的 Git 安全协议。
    • 仅当当前分支没有相关工作，且没有可安全创建的当前分支 PR 时，才请用户选择一个 PR。

  3. 收集解释变更所需的上下文：

    • 阅读工单和任何相关任务资料。
    • 阅读完整的 PR 差异，以及足够的周边代码，以理解行为和职责归属。
    • 使用 gh pr view 收集 PR 元数据和变更文件。
    • 阅读 {SKILLBASE}/references/show-me.md，了解 PR 正文中使用的可视化大纲规范。

  4. 使用模板撰写 PR 描述：

    • 变更原因必须恰好用一句话说明。
    • 需要特别注意的事项写 1 至 3 条要点。优先说明给审阅者的警告、迁移、兼容性限制、有意省略的内容或出乎意料的决策。没有特别事项时写 - None.。
    • 变更大纲应采用紧凑、受 /show-me 启发的结构化视图，而非散文或逐文件变更日志。
    • 只包含有助于解释此 PR 的视图：
      • SQL 表和端点契约变更，以及业务逻辑伪代码。
      • 关键数据结构／类型变更。
      • 展示职责变更的浅层文件树。
      • React 组件树变更，包括重要的 Hook、状态和包边界。
      • 调用树、调用栈、控制流或数据流变更。
    • 展示现有结构的变更时，优先使用 diff 代码块。若大部分内容都是新增的，或差异标记会模糊职责归属或顺序，则展示完整的目标结构。
    • 每个视图都应聚焦于审阅者需要了解的内容。省略未发生变更的类别。
    • 以 需要留意的事项 作为最后一节，说明“变更内容”之外的信息：你独自做出的决策、意外情况、PR 未包含的内容，以及后续事项；每项都标记为工单、维护者待办或无需处理。保留四行，空项写 None.，以表明已考虑过这些事项。需要特别注意的事项只讨论变更本身。
    • 若 PR 完成了某张工单，使用 Closes #n；若工单仍需维护者尝试（QA），使用 Refs #n，以免合并 PR 时提前关闭工单。
    • 可选：若已知工单编号／URL、相关计划／文档 URL 或其他相关链接，可将其包含在标题部分；否则省略该部分。

  5. 保存并发布描述：

    • 将描述保存到 .scratch/pr-{number}/description.md：.scratch/ 已加入 gitignore，且 GitHub 会保存已发布的描述，因此保存或重写该文件不会留下需要提交的内容。
    • 使用 gh pr edit {number} --body-file {output-path} 更新 PR。
    • 确认更新成功。

  6. 报告完成情况：

    • 阅读 {SKILLBASE}/references/describe_pr_final_answer.md。
    • 使用该最终答复模板，提供 PR URL、已保存的描述文件路径，以及简洁的变更文件列表。
    • 为每个变更文件提供两个审查链接，链接基于推送后 PR 当前的 head commit（gh pr view {number} --json url,headRefOid,files），以便更新后的 PR 链接指向新的 head。根据 PR 的 url 获取 {owner}/{repo}：
      • 最终版本： https://github.com/{owner}/{repo}/blob/{headRefOid}/{path}，GitHub 会以 Markdown 格式呈现。
      • 差异： {pr_url}/files#diff-{hash}，其中 {hash} 是路径的 SHA-256 值（在 printf %s '{path}' | shasum -a 256 中计算，或在 Linux 上使用 sha256sum）。
    • 变更文件较多时，为关键文件添加链接，其余文件仅列出路径。

始终阅读并遵循 {SKILLBASE}/references/pr_description_template.md。PR 正文不得超出该模板的范围。

像与他人交谈一样写作：避免使用术语和俚语，语言简单、连贯、简洁。

提及 issue 或 pull request 时，使用其标题，不要只写编号：#12 Add login，而不是单独写 #12。标题、正文以及告知用户的任何内容均遵循此规则。

评论

支持 Markdown