finalizing-pr

完成 PR

通过运行质量检查、简化代码，并在 PR 不存在时创建一个 PR，为当前分支做好合并准备。

完全自主执行 —— 不要停下来或暂停以请求确认。从当前状态直接推进到可合并的 PR，无需人工干预。将任何未决问题或歧义记录在 PR 的对话评论中（位于 Conversation 标签页下），而不是因此阻塞。

工作流

按顺序执行以下步骤。在前台运行所有子 Agent（而非后台），除非另有说明——在继续之前等待每个子 Agent 完成。子 Agent 模型：每次启动时使用与本会话相同的模型（model: inherit / 省略任何模型覆盖）。除非用户明确要求，否则不要切换到其他或更快的模型。

注意： 对于小型更改（文档微调、仅测试微调、单行修改或其他微型更改），可以跳过步骤 1、2、3、6、7 和 8。

1. 构建并安装

在子 Agent 中运行 make all，以确保构建和安装是最新的。在继续之前等待完成。

make all

2. 更新内部文档

在后台子 Agent 中运行 /updating-internal-docs 技能，以自动修复内部文档问题。指示其将所有建议的修复应用到与本地更改相关的内部文档问题上。

3. 简化更改

运行 simplifying-local-changes 子 Agent，以清理和简化代码更改。在继续之前等待完成。

4. 运行自动修复

在子 Agent 中运行自动修复，以修复格式和 lint 问题。在继续之前等待完成。

make autofix

5. 运行检查（第一遍）

在子 Agent 中运行 /checking-changes 技能（使用 make check）以验证更改。等待完成，然后在继续之前修复发现的任何问题。在此步骤中，除了 make check 之外不要运行其他检查。

6. 审查更改

运行 reviewing-local-changes 子 Agent 以审查更改。等待完成并阅读审查输出。

7. 处理审查反馈

审查步骤 6 的建议。对于每条建议：

• 如果有效且能提升代码质量：实施该更改
• 如果不适用或会导致过度工程：跳过并简要说明理由

8. 运行检查（第二遍）

在子 Agent 中运行 /checking-changes 技能，并使用 E2E_CHECK=true make check，以同时运行已更改的 e2e 测试。等待完成，然后在继续之前修复发现的任何问题。快照不匹配可以忽略（它们需要手动更新）。

9. 创建或更新 PR

注意： 如果当前位于 develop 分支，请先按照 wiki/pull-requests.md 中的命名约定创建一个新分支。

检查当前分支是否已存在 PR：

gh pr view --json number,title,url

如果不存在 PR，请按照 wiki/pull-requests.md 中的指南（请务必阅读！）以及 /reviewing-pr-description 技能中的标题/描述指引创建一个 PR。添加适当的标签，并根据 .github/pull_request_template.md 填写正文。

关联相关问题： 对于此 PR 解决的任何已知 GitHub 问题，在 PR 描述中添加 - Closes #12345。

必需标签：

类别	选项
影响	impact:users（影响用户行为）或 impact:internal（不改变用户行为）
更改类型	change:feature、change:bugfix、change:chore、change:refactor、change:docs、change:spec、change:other

注意：标记为 change:spec（仅用于规格/设计文档）的 PR 可豁免影响标签要求。

# Push branch to origin first (required for gh pr create in non-interactive mode)
git push -u origin HEAD

# Create the PR
gh pr create --base develop --title "[type] Description" --body "$(cat <<'EOF'
## Describe your changes

- Change 1
- Change 2

## GitHub Issue Link (if applicable)

- Closes #12345

## Testing Plan

- [x] Unit Tests (JS and/or Python)
EOF
)" --label "impact:users,change:feature"

如果已存在 PR，请根据当前更改检查描述是否需要更新。

10. 上传中间文件

如果存在相关的中间文件（work-tmp/ 中的规格、计划、实现说明，或 specs/ 中未跟踪的文件），请运行 /sharing-pr-agent-artifacts 技能，将它们推送到 wiki，并在 PR 中评论附上链接。

11. AI 审查与修复循环

运行 AI 审查与修复循环，最多 5 次。每次审查后，始终运行 fixing-pr，以便等待 CI 并处理评论，然后如果该次审查已批准则退出：

for iteration 1 to 5:
    1. Trigger AI review by applying the "ai-review" label
    2. Run the `fixing-pr` subagent in foreground to wait for CI, fix failures, and address review comments
    3. Check the latest AI review verdict
    4. If it is "approved" → exit loop

触发 AI 审查：

gh pr edit --add-label "ai-review"

检查 AI 审查结论：

AI 审查以来自 github-actions 机器人的 PR 审查形式发布结果。其中包含一个隐藏标记：

要找到最新的 AI 审查并提取结论：

PR_NUM=$(gh pr view --json number -q '.number')

# Get the verdict from the latest AI review
gh api --paginate "repos/streamlit/streamlit/pulls/${PR_NUM}/reviews" \
  | jq -s '[.[][] | select(.user.login == "github-actions[bot]" and (.body | contains("<!-- streamlit-ai-review")))] | sort_by(.submitted_at) | last | .body' \
  | grep -A2 "## Verdict"

结论部分包含一个粗体关键词，表示结果：

• **APPROVED** → 退出循环，PR 已就绪
• **CHANGES_REQUESTED** → 继续迭代，处理反馈

在得到 APPROVED 结论后，不要再开始另一次迭代，即使 fixing-pr 推送了后续的 CI 修复。这些提交由 CI 覆盖，但不由 AI 审查覆盖。

12. 最终 AI 审查

在审查循环之后，应用一次 ai-final-review。等待此分支出现 queued 或 in_progress 状态的 ai-pr-review.yml 运行，然后启动 /fixing-pr —— 如果尚未排队，它会立即返回：

gh pr edit --add-label "ai-final-review"

gh run list --branch "$(git branch --show-current)" --workflow ai-pr-review.yml --status queued
gh run list --branch "$(git branch --show-current)" --workflow ai-pr-review.yml --status in_progress

运行一次 /fixing-pr，以便等待 CI 并处理评论。无论第 11 步是已批准还是用尽了迭代次数，都请仅执行这一次。不要再次应用 ai-final-review。在 /fixing-pr 之后，提交并推送剩余的更改。

13. 发布 Agent 指标

将 Agent 指标发布到 PR 正文：

uv run python scripts/log_agent_metrics.py --post