mcpField
D
describe-pr

describe-pr

github.com/parcadei开发3.9k501 次安装39 周前更新
代码仓库

关于 describe-pr

describe-pr 是用于生成符合仓库规范的 Pull Request 描述的技能。它读取本地模板、收集 PR 变更与元数据、处理验证清单，并保存和更新描述。

主要功能

  1. 01读取仓库的 PR 模板
  2. 02查找并检查 Pull Request
  3. 03审阅差异、提交和推理记录
  4. 04执行模板中的验证步骤
  5. 05保存并更新 PR 描述

适用场景

  1. 01为待处理的 PR 编写描述
  2. 02变更后更新现有 PR 描述
  3. 03更新 PR 前检查验证步骤

安装

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

$npx skills add https://github.com/parcadei/continuous-claude-v3 --skill describe-pr

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

详细介绍

生成 PR 描述

你的任务是按照仓库的标准模板生成全面的拉取请求描述。

操作步骤：

  1. 阅读 PR 描述模板：

    • 首先，检查 thoughts/shared/pr_description.md 是否存在
    • 如果不存在，告知用户需要在 thoughts/shared/pr_description.md 创建 PR 描述模板
    • 仔细阅读模板，了解所有章节和要求

  2. 确定要描述的 PR：

    • 检查当前分支是否关联了 PR：gh pr view --json url,number,title,state 2>/dev/null
    • 如果当前分支没有 PR，或者当前处于 main/master 分支，则列出开放的 PR：gh pr list --limit 10 --json number,title,headRefName,author
    • 询问用户要描述哪个 PR

  3. 检查是否已有描述：

    • 检查 thoughts/shared/prs/{number}_description.md 是否已存在
    • 如果存在，阅读该文件，并告知用户你将对其进行更新
    • 考虑自上次撰写描述以来发生了哪些变化

  4. 全面收集 PR 信息：

    • 获取完整的 PR 差异：gh pr diff {number}
    • 如果遇到未设置默认远程仓库的错误，指导用户运行 gh repo set-default 并选择相应的仓库
    • 获取提交历史：gh pr view {number} --json commits
    • 查看基础分支：gh pr view {number} --json baseRefName
    • 获取 PR 元数据：gh pr view {number} --json url,title,number,state

4b. 收集推理历史（如果有）：

  • 检查推理文件是否存在：ls .git/claude/commits/*/reasoning.md 2>/dev/null
  • 如果存在，汇总这些文件：bash "$CLAUDE_PROJECT_DIR/.claude/scripts/aggregate-reasoning.sh" main
  • 这会展示最终方案确定前尝试过的方法
  • 保存输出，以便纳入 PR 描述

  1. 全面分析更改：（深入思考代码更改、其架构影响及潜在影响）

    • 仔细阅读完整的差异
    • 为了解上下文，阅读差异中提及但未显示的文件
    • 理解每项更改的目的和影响
    • 区分面向用户的更改与内部实现细节
    • 查找破坏性更改或迁移要求

  2. 处理验证要求：

    • 查找模板「如何验证」部分中的所有检查项
    • 对于每个验证步骤：
      • 如果是可以运行的命令（例如 make check test、npm test 等），则运行该命令
      • 如果通过，将复选框标记为已选中：- [x]
      • 如果失败，保持未选中，并注明失败内容：- [ ]，附上说明
      • 如果需要手动测试（UI 交互、外部服务），则保持未选中，并注明需由用户执行
    • 记录所有无法完成的验证步骤

  3. 生成描述：

    • 根据模板填写每个部分：
      • 根据分析回答每个问题或填写每个章节
      • 具体说明解决的问题和所做的更改
      • 在相关处重点说明对用户的影响
      • 在适当的章节中加入技术细节
      • 撰写简洁的变更日志条目
    • 如果找到了推理文件（来自步骤 4b）：
      • 在「如何验证」之前添加一个「## 尝试过的方法」章节
      • 纳入汇总后的推理内容，展示失败的尝试及从中获得的经验
      • 这有助于审核者了解整个过程，而不仅仅是最终结果
    • 确保处理所有检查项（标记为已完成或说明原因）

  4. 保存描述：

    • 将完成的描述写入 thoughts/shared/prs/{number}_description.md
    • 向用户展示生成的描述

  5. 更新 PR：

    • 直接更新 PR 描述：gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md
    • 确认更新成功
    • 如果仍有未选中的验证步骤，提醒用户在合并前完成这些步骤

重要说明：

  • 此命令适用于不同的仓库——始终阅读本地模板
  • 内容要详尽但简洁，便于快速浏览
  • 说明「为什么」和「是什么」同样重要
  • 突出说明任何不兼容变更或迁移注意事项
  • 如果 PR 涉及多个组件，请按组件组织说明
  • 始终尽可能尝试运行验证命令
  • 明确说明哪些验证步骤需要手动测试

评论

支持 Markdown