shepherd-pr

审查 PR

自主审查 PR 评论和构建状态，在能够以高置信度（>=80%）处理的情况下解决问题，其余则标记为需人工审查。

工作流

注意：本仓库要求你使用 node 24。在运行任何命令之前，请使用 nvm 切换到 node 24：

nvm use 24

1. 收集上下文

# Get PR number for current branch
gh pr view --json number,headRefName,url

# Get review threads with resolution status
gh api graphql -f query='
  query($owner: String!, $repo: String!, $number: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $number) {
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            comments(first: 50) {
              nodes {
                body
                path
                line
                author { login }
                createdAt
                databaseId
              }
            }
          }
        }
      }
    }
  }
'

仅筛选未解决的讨论串。

2. 对每条未解决的评论进行分类

阅读所引用的代码并进行调查。分类为：

A. 误报 / 已解决 — 该问题在当前代码中已不存在。

• 回复说明原因，引用具体代码或提交。
• 解决该讨论串。

B. 琐碎修复（>=80% 置信度） — 显而易见的机械性修复。不涉及设计决策或意见分歧。例如：拼写错误、缺少空值检查、变量名错误、差一错误、缺少导入。

• 进行修复。
• 回复说明所做的更改。
• 解决该讨论串。

C. 需要人工输入（<80% 置信度） — 设计问题、重大重构或修复方案不明确。

• 不要解决。
• 添加到会话结束摘要中。

3. 回复并解决讨论串

回复评论：

gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies \
  -f body="<your reply>"

解决讨论串：

gh api graphql -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: {threadId: $threadId}) {
      thread { isResolved }
    }
  }
' -f threadId="$THREAD_ID"

始终先推送修复，然后回复，再解决相关讨论串（按此顺序）。

4. 检查构建状态

gh pr checks --json name,status,conclusion

按类别调查失败：

Lint 错误 — 运行 pnpm lint-current。如果是机械性问题（格式、导入顺序、未使用的变量）则修复。如果 lint 规则本身有问题则标记。

类型错误 — 从仓库根目录运行 pnpm typecheck。修复简单的类型不匹配。如果修复需要架构决策则标记。

单元测试失败 — 在相关工作区运行 pnpm test run。如果测试预期因有意的代码更改而明显过时则修复。如果失败揭示了实际 bug 或设计问题则标记。

E2E 快照失败 — 确定 PR 的代码更改 是否应该 导致视觉差异：

• 如果是（UI 更改、样式更新）：添加 update-snapshots 标签以触发自动更新工作流：

  gh pr edit --add-label "update-snapshots"
  

• 如果否：标记为意外回归，供人工审查。

神秘/意外失败 — 不要尝试修复。连同错误输出一起标记供人工审查。

5. 提交并推送修复

git add <specific files>
git commit -m "Address PR review feedback

- <summary of changes>"
git push

仅暂存特定文件。永远不要强制推送。永远不要使用 git add -A。

6. 会话结束摘要

始终以以下内容结束：

## PR review summary

### Resolved
- <thread>: <what was done>

### Fixed
- <description of fix>

### Needs your input
- <thread>: <why it needs human judgment>

### Build status
- <status of each check, any actions taken>

省略空的部分。

指南

• 保守阈值：仅在 >=80% 确信修复正确且无争议时才采取行动。
• 永远不要解决提出设计问题或意见分歧的评论。
• 永远不要在不先回复的情况下解决。
• 在断定评论为误报之前，阅读实际代码。
• 验证修复不会破坏类型（pnpm typecheck）或 lint（pnpm lint-current）。
• 除非更改明显是有意的，否则不要修改测试预期。