---
name: pr-release-loop
description: >-
  PR 发布完整闭环（循环 review 之后的收尾）——创建 PR 后按 AGENTS.base.md「⚠️ 创建完 PR 后自动走完整闭环流程」自动走完
  循环 review → 重新部署测试环境 → 测试环境复测 → 确认 → 发 PR 链接 → 发新版本 六步。核心防线：**循环 review 走完后，
  必须重新部署到测试环境并复测，确认没问题之后才能发链接/发版**——这是最容易漏掉的一环（review 会改代码，跳过复测=拿旧代码下结论）。
  触发场景包括但不限于：
  「PR闭环」「闭环走完」「完整闭环」「六步闭环」「走完整流程」「收尾」「发布闭环」「发布收尾」「循环review完再部署测一遍」「测试环境再测一遍」。
  以及「创建PR后的完整流程」「走完循环review流程」「循环review完之后」。
  当循环 review 显示「无值得修的新问题」、进入收尾阶段时，**自动触发本 Skill**，无需用户再开口。
---

# PR 发布完整闭环（循环 review 之后的收尾）

⚠️ **本 Skill 已触发。在用户回复中第一句话必须输出：「🔧 已触发 `pr-release-loop`，进入循环 review 之后的发布收尾闭环…」然后严格按照以下步骤执行，不得跳过。**

创建 PR 之后，自动把完整闭环走完。**重点不是「做六件事」本身，而是第 3、4 步是重活、最容易在「收尾惯性」中被省略**——循环 review 走完时往往急着交付，直接把「重新部署测试环境 + 复测」跳过去了。本 Skill 就是那道闸。

## ⚠️ 核心铁律（违反即错误）

- ⚠️ **循环 review 结束 ≠ 完成。** review 期间会 push 新 commit，**只有把最新代码重新部署到测试环境、在测试环境复测通过，才算真正完成**。跳过复测直接用旧代码下结论 = 白 review。
- ⚠️ **完成定义清单（终局前必须逐项自查并输出）：**
  1. ✅ 循环 review 走完（`/loop-review`，直到某一轮不再冒出值得修的新问题）
  2. ✅ 最新代码已提交并推送到 PR 分支
  3. ✅ 已通过 `/deploy-test` 重新部署到测试环境（部署的是 review 之后的最终代码）
  4. ✅ 测试环境用真实数据 + 真实交互复测通过（每张截图浏览器真实视口全页、箭头标注、URL 可见）
  5. ✅ 与主分支无冲突（`gh pr view <PR> --json mergeable -q .mergeable` = `MERGEABLE`）
  6. ✅ GitHub 静态编译通过（`gh pr checks <PR>` 无 `failure`）
  7. ✅ PR 链接已发送给用户
  8. ✅ 发新版本（`./release.sh`）
- ⚠️ **循环 review 走完后，显式输出「✅ 循环 review 完成，进入发布收尾闭环」，然后逐项执行下面第 2～8 步，禁止在循环 review 结束后直接发链接/发版。** 若发现某一步没做（典型：忘了重新部署、复测是旧数据），必须停下来补齐再继续，禁止把「漏掉的第 3/4 步」带进交付。

## 核心流程

### 1. 确认循环 review 已完成

```bash
REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
PR=$(gh pr view --json number -q '.number')
CUR=$(git rev-parse HEAD)
LATEST=$(bash "$(git rev-parse --show-toplevel)/.claude/skills/loop-review/scripts/check-review.sh" "$REPO" "$PR")
echo "最新 review 审查 commit: $LATEST"
echo "当前 HEAD: $CUR"
```

与 `check-review.sh` 返回的最新 review 审查 commit 对比：若等于当前 HEAD，说明 bot 已审查到最新代码（循环 review 已对该 commit 收敛）；若为空或更早，说明 bot 还没审到最新 push，循环 review 尚未完成。

⚠️ 不要用 `gh pr view --json comments -q '.comments | length'`（评论总数）判断闭环——评论数与「循环 review 是否收敛」无对应关系，验证不了。判断依据是「最新 review 是否针对当前 HEAD」，即 `/loop-review` 步骤 1 的同一套逻辑。若循环 review 还没走完，**先补跑 `/loop-review`，不得跳过**。

### 2. 确保最新代码已推送

循环 review 期间若有改动，确保已提交并推送到 PR 分支。若 review 过程中没有新增 commit，且已满足「无值得修的新问题」，则跳过本步（不必为了触发而空 push）。

```bash
# ⚠️ git status 即使存在未提交改动也返回 0，直接 git status && git push 会把「还有未提交改动」误判成「已推送」。
# 必须用 --porcelain 显式检查工作区/暂存区是否干净，脏则中止推送。
if [ -n "$(git status --porcelain)" ]; then
  echo "❌ 工作区存在未提交改动，请先 commit 后再 push"
  git status
  exit 1
fi
git push origin "$(git branch --show-current)"
```

### 3. 重新部署到测试环境（最容易漏的一步）

⚠️ 必须触发 `/deploy-test` skill，**把「当前功能分支的最新代码」合并到 test 并部署**，确保测试的就是 review 之后的最终代码。

> 为什么必须重部署：循环 review 的每次修复都 push 了新 commit。如果不重部署，测试环境跑的还是 review 之前的旧代码，等于用旧代码验证新改动，结论无效。

### 4. 测试环境复测 + 全程截图标注

- 在测试环境用**真实数据 + 真实交互**测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。
- 每步截图保留（遵循「⚠️ 截图规范」：浏览器真实视口宽（需要更清晰时提高 DPR）、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
- 若本次改动是纯后端/基础设施，按「非 UI / 后端 / 基础设施改动的效果截图获取方法」把 curl 响应渲染成暗色终端 HTML 截图。

### 5. 确认没问题才算完成

测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。**禁止测试没跑、截图没标注就宣称完成。**

### 6. 冲突检查 + 静态编译检查（三步收尾）

用 `gh pr view <PR> --json mergeable -q .mergeable` 检查冲突（`CONFLICTING` 必须先解决），用 `gh pr checks <PR>` 检查 CI（有 `failure` 必须修复重推）。两者都通过后才发链接/发版。

### 7. 发 PR 链接给用户

```bash
gh pr view <PR> --json url -q .url
```

一般按下流程：循环 review 全部通过 → 部署测试环境复测 → 确认后**先发 PR 链接，再发版**。

### 8. 发新版本

PR 合并后按项目发布流程执行根目录 `./release.sh` 发新版本（自动完成 patch 号 +1、更新 `package.json`、`git commit`/`push`、打 tag、`npm publish`）。

## 判断边界

- ⚠️ **如果循环 review 走完但没有重新部署测试就发链接/发版 → 直接违背闭环，必须停下并报告缺失项**（你没说过「跳过复测」，这属于该做而没做）。
- ⚠️ **用户明确说「不用部署测试」「跳过复测，直接发版」等显式指令** → 按用户指令执行，不必拦（但要在交付时说明「本次跳过了测试环境复测」）。
- ⚠️ **纯文档/无逻辑改动（如只改 README）** → 可以跳过复测，但发链接/发版前仍要完成冲突+编译检查。

## 相关

- 循环 review 细节：`loop-review` skill
- 部署测试环境：`deploy-test` skill
- 创建 PR / 截图上传：`create-pr` skill
- 验证证据产出：`visual-report` skill