Skills pr-comment-fix

按 GitCode PR 检视意见修改代码。需 GITCODE_TOKEN。Use when 用户要修改 PR 检视意见。

install

source · Clone the upstream repo

git clone https://github.com/openclaw/skills

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/autoxj/pr-comment-fix" ~/.claude/skills/clawdbot-skills-pr-comment-fix && rm -rf "$T"

manifest: skills/autoxj/pr-comment-fix/SKILL.md

source content

GitCode PR 检视意见修复

执行顺序：

fetch

写出 JSON → 按模板汇总并请用户选范围 → 确认后再改代码 → 本地验证并输出修复总结表 → 用户需要时再

reply

resolve

。

何时使用

用户希望 根据 PR 上的代码检视意见改本地代码（不是「检视 PR 出报告」一类只读检视）。
须由用户提供 GitCode PR 页面链接（
```
--pr-url
```
）；不支持仅填 owner/repo/编号，不做基于 git 的自动匹配。

认证

Token：
```
GITCODE_TOKEN
```
环境变量，或用户消息中提供；也可用脚本参数
```
--token
```
。
请求头：
```
PRIVATE-TOKEN
```
（与现有 GitCode skills 一致）。
未配置时提示前往 GitCode 个人访问令牌创建并设置变量。

依赖

Python 3.7+，仅标准库（脚本
```
scripts/pr_comment_fix_tool.py
```
）。
工作区应能打开 待修改的仓库（与 PR 变更一致）。

流程（严格顺序）

1. 拉取上下文 JSON（必须先做）

SKILL_ROOT：本

SKILL.md

所在目录。

python <SKILL_ROOT>/scripts/pr_comment_fix_tool.py fetch -o "<路径>/pr_comment_fix_context.json" --pr-url "<GitCode PR 完整 URL>"

fetch
仅接受
--pr-url
：URL 路径含
```
/pull/
```
、
```
/pulls/
```
或
```
merge_requests/
```
均可解析。请从浏览器复制 PR 所在仓库 的页面链接（fork 场景下一般打开上游仓库里的 PR）。

脚本写出

pr_comment_fix_context.json

（或打印到 stdout），其中包含：

```
owner
```
、
```
repo
```
、
```
pr_number
```
、
```
pr_html_url
```
unresolved_diff_comments
：每条含 seq
、
```
discussion_id
```
、
```
body
```
、
```
diff_file
```
、
```
resolved
```
等 API 原始字段（须保留
discussion_id
供后续回复/改状态）
by_file
：按文件分组，同一文件内评论已按 行号相关字段从大到小 排序（便于从文件末尾往前改）

筛选规则：仅包含 未解决 行评（

resolved

不为真；缺省视为未解决）。

若 JSON 含

warnings

（如缺少

discussion_id

），须告知用户：对应条目无法使用脚本的

reply

resolve

。

停步点：
```
fetch
```
成功并已有
```
pr_comment_fix_context.json
```
后，下一步只能是步骤 2（汇总并按模板输出、再询问用户）。不得直接进入读文件、打补丁或「顺手改一处」。

2. 汇总并按模板输出、再确认范围（未收到明确答复前不得改代码）

读取 JSON：以
```
unresolved_diff_comments
```
为准（可与 by_file
对照），统计条数 N。
必须先用下面表格向用户展示全部待处理项（序号与 JSON 中
```
seq
```
一致；行号取自接口字段，如
```
line
```
/
```
original_line
```
/
```
position
```
等，无则写「见讨论/无行号」；问题用
```
body
```
的简要概括或首行，勿整段粘贴）：
序号文件行号问题
1
diff_file
…
…
… … … …
询问用户处理范围：
```
全部
```
/
```
是
```
、部分序号如
```
1,3
```
、
```
不修
```
/
```
跳过
```
。
用户回复可解析后再进入步骤 3；不明则再问。发出表格与询问后须等待用户下一条消息，在此之前不得编辑代码。
「不修」→ 结束，不改代码。

3. 按文件修复（仅在步骤 2 确认后执行）

依据

pr_comment_fix_context.json

中的 by_file
与 unresolved_diff_comments
修复：

顺序：以 by_file
为准；同一文件内 按数组顺序（已 从后往前）逐条处理，减少行号漂移。
定位：以 API 行号相关字段与 diff_file
为准；修改前 先读当前文件对应行，勿盲信过时行号。
路径：
```
diff_file
```
相对仓库根解析；若找不到，再尝试去前缀或让用户确认根目录。
大改：单条预估改动 >20 行、或 改签名/结构、或 跨 ≥2 个文件 → 先给 修改方案，用户确认后再动代码。
合并同一次修改：同一文件、同一意图的多条意见尽量合并为一次编辑。

4. 本地验证与修复总结

每批或全部修改完成后：

语法/解析：对改动过的文件做可行检查（如
```
python -m py_compile
```
）。
导入与符号：无未定义引用。
范围：仅动用户确认范围内的代码。
若项目有固定检查命令（
```
ruff
```
/
```
eslint
```
/
```
make test
```
等），在可行时执行。

必须先输出「修复总结表」（与步骤 2 中条目对应；处理方式写本次实际做了什么；未动的项不要编造）：

序号	文件	行号	问题	处理方式
1	…	…	（与步骤 2 对应）	（简述：如何改、是否仅说明未改）
…	…	…	…	…

5. 修后闭环（仅当用户需要时）

顺序固定为：

修改与验证完成后，询问是否 生成回复草稿（针对已处理的条目）。
若需要 → 生成草稿 → 用户确认 → 询问是否发送。
若发送 → 使用脚本 reply
（见下）调用官方接口：回复 Pull Request 评论。
发送完成后，询问是否 修改检视解决状态；若需要 → 使用 resolve
子命令：修改检视意见解决状态。

不得在未获用户确认时代为发送评论或修改远端状态。

回复单条讨论

python <SKILL_ROOT>/scripts/pr_comment_fix_tool.py reply -c "<pr_comment_fix_context.json>" --seq <seq> --body "<正文>"
# 或 --discussion-id <id> --body "..."

将讨论标为已解决

python <SKILL_ROOT>/scripts/pr_comment_fix_tool.py resolve -c "<pr_comment_fix_context.json>" --seq <seq> --resolved 1

若

resolve

报错，对照官方文档核对请求体。

脚本子命令一览

子命令	作用
`fetch`	拉取未解决 `diff_comment` ，写上下文 JSON
`reply`	`POST .../pulls/{n}/discussions/{discussion_id}/comments`
`resolve`	`PUT .../pulls/{n}/comments/discussions/{id}`

完整参数见：

python scripts/pr_comment_fix_tool.py --help

。