mcpField
W
write-pr

write-pr

github.com/2ykwang开发1991 次安装14 周前更新
代码仓库

关于 write-pr

write-pr 是只读技能，根据当前分支的变更起草 PR 标题和正文。它会分析提交历史、差异、项目惯例及可用的 PR 模板，但不会创建或推送 PR。

主要功能

  1. 01检测基准分支
  2. 02分析提交历史与差异
  3. 03查找项目 PR 模板
  4. 04匹配现有标题惯例
  5. 05起草标题和 PR 正文

适用场景

  1. 01为分支准备 PR 描述
  2. 02填写仓库的 PR 模板
  3. 03使 PR 标题符合项目风格

安装

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

$npx skills add https://github.com/2ykwang/agent-skills --skill write-pr

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

附带文件README.ko.mdREADME.md

详细介绍

编写 PR

将当前分支的更改整理为符合项目现有规范的 PR 标题和正文。分析 Git 历史记录和差异以判断更改意图，不要只看文件名。

适用场景

  • 为当前分支编写或起草拉取请求描述
  • 生成符合项目提交／PR 风格的 PR 标题
  • 根据实际代码更改填写 PR 模板

不适用场景

  • 用户要求实际创建或推送拉取请求
  • 没有领先于基准分支的提交
  • 用户只需要提交消息，而不是 PR 描述

此技能为只读。绝不要运行任何会修改状态的命令：gh pr create、gh pr edit、git push 或任何其他写入操作。

上下文

用户希望根据当前分支的更改，获得可直接使用的 PR 标题和正文。关注意图和影响，而不是原始差异输出。遵循项目现有的 PR 风格。

操作说明

第 1 步：检测基准分支

如果提供了 $ARGUMENTS，将其用作基准分支。

否则，按以下顺序自动检测：

  1. 运行 git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null — 提取分支名称（例如，origin/main → main）
  2. 如果失败，检查 main、master、develop 中哪些分支存在：git branch -r | grep -E 'origin/(main|master|develop)'
  3. 使用找到的第一个匹配项
第 2 步：收集更改信息

按顺序运行这些命令：

git log <base>..<HEAD> --oneline
git diff <base>...<HEAD> --stat
git diff <base>...<HEAD> --shortstat

使用 --shortstat 输出（例如，12 files changed, 340 insertions(+), 50 deletions(-)）判断差异规模：

  • 如果更改文件数 ≤ 20，且插入数与删除数之和 ≤ 500：读取完整差异 git diff <base>...<HEAD>
  • 如果更改文件数 > 20，或插入数与删除数之和 > 500：不要读取完整差异。根据 --stat 输出，找出每个目录／模块中更改最多的文件，并且只读取这些代表性文件
第 3 步：查找 PR 模板

此步骤为必需步骤。不要跳过，也不要假定文件不存在。

使用文件读取工具并行尝试读取以下所有路径：

  • .github/PULL_REQUEST_TEMPLATE.md
  • .github/pull_request_template.md
  • docs/pull_request_template.md
  • PULL_REQUEST_TEMPLATE.md

同时检查 .github/PULL_REQUEST_TEMPLATE/ 目录是否存在；如果存在，列出文件并读取第一个文件。

使用第一个成功返回内容的路径。

如果成功读取模板文件：

  • PR 正文必须严格采用其原有结构
  • 保留所有章节、标题和 HTML 注释（``），并保持其原有位置
  • 在适当位置填写内容；对于无法根据差异确定的章节（例如，Screenshots、Related Issues），保留原有占位文本或 HTML 注释，不要删除或概述
  • 不要调整顺序、合并或省略任何章节

**如果所有路径均无法读取（文件不存在）：**使用以下默认结构：

## Summary


## Changes


## Test Plan
第 4 步：识别 PR 标题风格

运行：

gh pr list --state merged --limit 10 --json title 2>/dev/null

如果 gh 返回结果，分析标题模式（例如，feat: ...、[PROJ-123] ...、Fix: ...）。

如果 gh 因任何原因失败（未安装、身份验证错误、不是 GitHub 仓库），则回退到：

git log --oneline -20

从提交消息中提取主要模式。

如果没有明确的模式，使用 Conventional Commits 格式（type: description）。

步骤 5：撰写 PR 内容

标题：

  • 如果步骤 4 中检测到的风格清晰且一致：生成 1 个标题
  • 如果风格模糊或混杂：生成 2–3 个标题候选项，并清楚标注

PR 正文：

  • 使用步骤 3 中的模板结构
  • 根据步骤 2 中的变更分析填写各个部分
  • 着重说明变更的原因，而不仅仅是变更了哪些文件
  • 如果差异中存在以下内容，请明确标出：
    • 破坏性变更（API／接口变更、移除字段）
    • 新增依赖项
    • 架构或结构变更
  • 不要将原始差异或文件列表直接粘贴到正文中
  • 对于无法填写的部分（例如截图、演示、相关议题）：保留模板中的原始 HTML 注释或占位符，不要删除该部分

输出格式

按以下顺序呈现输出：

标题

<single best title>

（如果存在歧义，请列出备选项，并标注为 Alt 1、Alt 2）

PR 正文

<filled-in PR body — exact template structure preserved>

分支：<base> ← <current> · 提交：N · 变更文件：N

评论

支持 Markdown