@routerhub/agent-rules 1.5.135 → 1.5.137
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.base.md +8 -0
- package/package.json +1 -1
- package/rules/global.md +8 -0
- package/skills/create-pr/SKILL.md +12 -2
- package/skills/loop-review/SKILL.md +1 -0
package/AGENTS.base.md
CHANGED
|
@@ -103,6 +103,8 @@
|
|
|
103
103
|
## Git 规范
|
|
104
104
|
|
|
105
105
|
- 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
|
|
106
|
+
- ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（发版除外：`./release.sh` 会在 main 上生成「发布 vX.Y.Z」提交）。
|
|
107
|
+
- ⚠️ **从主分支拉/建功能分支之前，必须先直接拉取远程主分支（`git pull origin main`）**，确保基于最新的远程主分支拉分支，禁止基于过期的本地主分支创建分支。
|
|
106
108
|
- ⚠️ **可评审 PR 的合并目标永远是仓库默认分支（如 `main`/`master`），不是 `test`**。`test` 分支只用于部署测试环境，只能通过 `/deploy-test` skill 直接 `merge` 更新（见「部署规则」），不发 PR、不走 code review；`test` 分支同样禁止直接提交代码。commit 必须中文，禁止 `git push --force`。
|
|
107
109
|
- ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
|
|
108
110
|
- ⚠️ **提交并推送代码后，若发现与主分支存在冲突，必须主动解决**，不能推送完就算完事、把冲突留给别人处理。
|
|
@@ -120,6 +122,12 @@
|
|
|
120
122
|
1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
|
|
121
123
|
2. **GitHub 静态编译检查**：用 `gh pr checks <PR>` 查看 CI 检查状态（`success`=通过，`failure`=失败，`pending`=进行中）。存在失败项时，必须定位失败根因、修改代码并重新推送，直到全部通过，禁止把静态编译未通过的 PR 抛给 reviewer。
|
|
122
124
|
3. **发新版本**：PR 合并后按项目发布流程发布新版本（本项目统一执行根目录 `./release.sh`，自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。
|
|
125
|
+
- ⚠️ **创建完 PR 后自动走完整闭环流程，未走完不算完成**：创建 PR → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发新版本，五步缺一不可，全程自动执行：
|
|
126
|
+
1. **自动走循环 review**：创建完 PR 后自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束，禁止只跑一轮就收工。
|
|
127
|
+
2. **重新部署到测试环境**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。
|
|
128
|
+
3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：视口 3840px 宽、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并在每张截图上用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
|
|
129
|
+
4. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
|
|
130
|
+
5. **发新版本**：确认没问题后，按上面三步收尾完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
|
|
123
131
|
- ⚠️ **私有仓库的 PR/Issue 正文中插入截图，禁止使用 `raw.githubusercontent.com` 链接，必须使用 `github.com/OWNER/REPO/blob/BRANCH/path?raw=true` 格式。** 原因：`raw.githubusercontent.com` 不识别 GitHub 网页端的登录态（session cookie），GitHub 渲染 PR/Issue 正文图片时走的是 camo 图片代理服务器端匿名拉取——对私有仓库该链接返回 404，导致图片框显示为普通文字链接而非图片；`github.com/.../blob/...?raw=true` 走的是 github.com 主域名，能通过登录态正确鉴权，图片才能正常渲染。凡是「先 `git add -f` 把截图提交进 `screenshots/` 目录、再在 PR 描述里用 Markdown 引用」的流程，图片链接一律拼接为后一种格式。
|
|
124
132
|
|
|
125
133
|
## 安全
|
package/package.json
CHANGED
package/rules/global.md
CHANGED
|
@@ -103,6 +103,8 @@ name: "通用规则"
|
|
|
103
103
|
## Git 规范
|
|
104
104
|
|
|
105
105
|
- 分支用 Git Flow（`feature/`、`bugfix/`、`hotfix/`、`refactor/`、`chore/`、`docs/`、`test/`），英文小写中划线分隔。
|
|
106
|
+
- ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（发版除外：`./release.sh` 会在 main 上生成「发布 vX.Y.Z」提交）。
|
|
107
|
+
- ⚠️ **从主分支拉/建功能分支之前，必须先直接拉取远程主分支（`git pull origin main`）**，确保基于最新的远程主分支拉分支，禁止基于过期的本地主分支创建分支。
|
|
106
108
|
- ⚠️ **可评审 PR 的合并目标永远是仓库默认分支（如 `main`/`master`），不是 `test`**。`test` 分支只用于部署测试环境，只能通过 `/deploy-test` skill 直接 `merge` 更新（见「部署规则」），不发 PR、不走 code review；`test` 分支同样禁止直接提交代码。commit 必须中文，禁止 `git push --force`。
|
|
107
109
|
- ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
|
|
108
110
|
- ⚠️ **提交并推送代码后，若发现与主分支存在冲突，必须主动解决**，不能推送完就算完事、把冲突留给别人处理。
|
|
@@ -120,6 +122,12 @@ name: "通用规则"
|
|
|
120
122
|
1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
|
|
121
123
|
2. **GitHub 静态编译检查**：用 `gh pr checks <PR>` 查看 CI 检查状态（`success`=通过，`failure`=失败，`pending`=进行中）。存在失败项时，必须定位失败根因、修改代码并重新推送，直到全部通过，禁止把静态编译未通过的 PR 抛给 reviewer。
|
|
122
124
|
3. **发新版本**：PR 合并后按项目发布流程发布新版本（本项目统一执行根目录 `./release.sh`，自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。
|
|
125
|
+
- ⚠️ **创建完 PR 后自动走完整闭环流程，未走完不算完成**：创建 PR → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发新版本，五步缺一不可，全程自动执行：
|
|
126
|
+
1. **自动走循环 review**：创建完 PR 后自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束，禁止只跑一轮就收工。
|
|
127
|
+
2. **重新部署到测试环境**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。
|
|
128
|
+
3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：视口 3840px 宽、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并在每张截图上用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
|
|
129
|
+
4. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
|
|
130
|
+
5. **发新版本**：确认没问题后，按上面三步收尾完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
|
|
123
131
|
- ⚠️ **私有仓库的 PR/Issue 正文中插入截图，禁止使用 `raw.githubusercontent.com` 链接，必须使用 `github.com/OWNER/REPO/blob/BRANCH/path?raw=true` 格式。** 原因：`raw.githubusercontent.com` 不识别 GitHub 网页端的登录态（session cookie），GitHub 渲染 PR/Issue 正文图片时走的是 camo 图片代理服务器端匿名拉取——对私有仓库该链接返回 404，导致图片框显示为普通文字链接而非图片；`github.com/.../blob/...?raw=true` 走的是 github.com 主域名，能通过登录态正确鉴权，图片才能正常渲染。凡是「先 `git add -f` 把截图提交进 `screenshots/` 目录、再在 PR 描述里用 Markdown 引用」的流程，图片链接一律拼接为后一种格式。
|
|
124
132
|
|
|
125
133
|
## 安全
|
|
@@ -88,10 +88,19 @@ gh pr create \
|
|
|
88
88
|
### 6. 补充元数据
|
|
89
89
|
|
|
90
90
|
- Assignees：填自己
|
|
91
|
-
- Labels
|
|
92
|
-
- 关联 issue：如有
|
|
91
|
+
- Labels：按类型/模块添加- 关联 issue：如有
|
|
93
92
|
- Milestone：如有
|
|
94
93
|
|
|
94
|
+
### 6.5 创建完 PR 后自动走完整闭环流程（未走完不算完成）
|
|
95
|
+
|
|
96
|
+
⚠️ 创建完 PR 后，禁止只做完步骤 7 收尾就交付。必须自动依次走完下方闭环，全程自动执行，未走完不算完成：
|
|
97
|
+
|
|
98
|
+
1. **自动走循环 review**：自动触发 `/loop-review` skill，反复「拉取 AI review（Claude Opus + GPT 交叉验证）→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」，直到某一轮不再冒出值得修的新问题才结束。
|
|
99
|
+
2. **重新部署到测试环境**：循环 review 走完后，自动触发 `/deploy-test` skill，把最新代码重新部署到测试环境，确保测试的是循环 review 之后的最终代码。
|
|
100
|
+
3. **测试环境验证 + 全程截图标注**：在测试环境用真实数据、真实页面交互测试本次改动（遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」）。测试过程中每一步都截图保留（遵循「⚠️ 截图规范」：视口 3840px 宽、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录），并在每张截图上用**箭头标注**关键改动区域/验证点，让看的人一眼看懂这张图证明了什么。
|
|
101
|
+
4. **确认没问题才算完成**：测试通过、截图与箭头标注齐全、功能符合预期，才算真正完成。禁止测试没跑、截图没标注就宣称完成。
|
|
102
|
+
5. **发新版本**：确认没问题后，回到下方步骤 7 完成冲突检查与静态编译检查，PR 合并后执行根目录 `./release.sh` 发新版本。
|
|
103
|
+
|
|
95
104
|
### 7. 每次修改 PR 后收尾检查（冲突 + 静态编译 + 发版本）
|
|
96
105
|
|
|
97
106
|
⚠️ 创建 PR 后、以及每次 push 新提交/响应 review 意见重新推送后，三步收尾缺一不可，禁止改完 PR 就直接抛给 reviewer 或当作完事。
|
|
@@ -124,5 +133,6 @@ gh pr checks <PR>
|
|
|
124
133
|
- ⚠️ 截图禁止提交到 Git 仓库
|
|
125
134
|
- ⚠️ PR 截图直接内嵌在 Description 正文中（Markdown 图片语法）
|
|
126
135
|
- ⚠️ 每次修改 PR 后（含创建、push 新提交、响应 review 意见）都必须做三步收尾：冲突检查 → 静态编译检查 → PR 合并后发新版本（见步骤 7）
|
|
136
|
+
- ⚠️ **创建完 PR 后必须自动走完整闭环流程（见步骤 6.5）**：创建 PR → 自动循环 review → 重新部署测试环境验证（全程截图 + 箭头标注）→ 确认没问题 → 发新版本，五步缺一不可，未走完不算完成
|
|
127
137
|
- ⚠️ **直接创建正式 PR（非 Draft）**：PR 创建完成即进入可评审状态，可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review
|
|
128
138
|
- 作者不能 Approve 自己的 PR
|
|
@@ -7,6 +7,7 @@ description: >-
|
|
|
7
7
|
「循环到没问题」「review到没问题」「review到干净」「反复review」「重复review」「一直review到干净」「review迭代」「交叉验证循环」。
|
|
8
8
|
「再来一轮review」「下一轮review」「review下一轮」「再review一轮」。
|
|
9
9
|
当用户写完代码提交 PR 后，主动问「要不要走循环 review」时也可触发。
|
|
10
|
+
创建完 PR 后按 PR 闭环流程（AGENTS.base.md「PR 核心要求」章节）**自动触发**，无需用户再开口。
|
|
10
11
|
---
|
|
11
12
|
|
|
12
13
|
# 循环 Code Review（AI 交叉验证循环）
|