@routerhub/agent-rules 1.5.137 → 1.5.138
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 +3 -2
- package/package.json +1 -1
- package/rules/global.md +3 -2
package/AGENTS.base.md
CHANGED
|
@@ -122,12 +122,13 @@
|
|
|
122
122
|
1. **与主分支冲突检查**:按上一条规则执行(`gh pr view <PR> --json mergeable -q .mergeable`),有冲突必须先解决。
|
|
123
123
|
2. **GitHub 静态编译检查**:用 `gh pr checks <PR>` 查看 CI 检查状态(`success`=通过,`failure`=失败,`pending`=进行中)。存在失败项时,必须定位失败根因、修改代码并重新推送,直到全部通过,禁止把静态编译未通过的 PR 抛给 reviewer。
|
|
124
124
|
3. **发新版本**:PR 合并后按项目发布流程发布新版本(本项目统一执行根目录 `./release.sh`,自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`)。
|
|
125
|
-
- ⚠️ **创建完 PR 后自动走完整闭环流程,未走完不算完成**:创建 PR → 循环 review → 重新部署测试环境验证 → 确认没问题 →
|
|
125
|
+
- ⚠️ **创建完 PR 后自动走完整闭环流程,未走完不算完成**:创建 PR → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发 PR 链接给用户 → 发新版本,六步缺一不可,全程自动执行:
|
|
126
126
|
1. **自动走循环 review**:创建完 PR 后自动触发 `/loop-review` skill,反复「拉取 AI review(Claude Opus + GPT 交叉验证)→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」,直到某一轮不再冒出值得修的新问题才结束,禁止只跑一轮就收工。
|
|
127
127
|
2. **重新部署到测试环境**:循环 review 走完后,自动触发 `/deploy-test` skill,把最新代码重新部署到测试环境,确保测试的是循环 review 之后的最终代码。
|
|
128
128
|
3. **测试环境验证 + 全程截图标注**:在测试环境用真实数据、真实页面交互测试本次改动(遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」)。测试过程中每一步都截图保留(遵循「⚠️ 截图规范」:视口 3840px 宽、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录),并在每张截图上用**箭头标注**关键改动区域/验证点,让看的人一眼看懂这张图证明了什么。
|
|
129
129
|
4. **确认没问题才算完成**:测试通过、截图与箭头标注齐全、功能符合预期,才算真正完成。禁止测试没跑、截图没标注就宣称完成。
|
|
130
|
-
5.
|
|
130
|
+
5. **把 PR 链接发给用户**:确认没问题后,先把 PR 链接发送给用户(`gh pr view <PR> --json url -q .url`),让用户能直接打开查看,再执行发版。
|
|
131
|
+
6. **发新版本**:确认没问题、PR 链接已发送后,按上面三步收尾完成冲突检查与静态编译检查,PR 合并后执行根目录 `./release.sh` 发新版本。
|
|
131
132
|
- ⚠️ **私有仓库的 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 引用」的流程,图片链接一律拼接为后一种格式。
|
|
132
133
|
|
|
133
134
|
## 安全
|
package/package.json
CHANGED
package/rules/global.md
CHANGED
|
@@ -122,12 +122,13 @@ name: "通用规则"
|
|
|
122
122
|
1. **与主分支冲突检查**:按上一条规则执行(`gh pr view <PR> --json mergeable -q .mergeable`),有冲突必须先解决。
|
|
123
123
|
2. **GitHub 静态编译检查**:用 `gh pr checks <PR>` 查看 CI 检查状态(`success`=通过,`failure`=失败,`pending`=进行中)。存在失败项时,必须定位失败根因、修改代码并重新推送,直到全部通过,禁止把静态编译未通过的 PR 抛给 reviewer。
|
|
124
124
|
3. **发新版本**:PR 合并后按项目发布流程发布新版本(本项目统一执行根目录 `./release.sh`,自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`)。
|
|
125
|
-
- ⚠️ **创建完 PR 后自动走完整闭环流程,未走完不算完成**:创建 PR → 循环 review → 重新部署测试环境验证 → 确认没问题 →
|
|
125
|
+
- ⚠️ **创建完 PR 后自动走完整闭环流程,未走完不算完成**:创建 PR → 循环 review → 重新部署测试环境验证 → 确认没问题 → 发 PR 链接给用户 → 发新版本,六步缺一不可,全程自动执行:
|
|
126
126
|
1. **自动走循环 review**:创建完 PR 后自动触发 `/loop-review` skill,反复「拉取 AI review(Claude Opus + GPT 交叉验证)→ 逐条读真实代码判断哪些值得修 → 值得修的改、不值得修/误报的 Won't fix 切断 → push 触发新一轮 review」,直到某一轮不再冒出值得修的新问题才结束,禁止只跑一轮就收工。
|
|
127
127
|
2. **重新部署到测试环境**:循环 review 走完后,自动触发 `/deploy-test` skill,把最新代码重新部署到测试环境,确保测试的是循环 review 之后的最终代码。
|
|
128
128
|
3. **测试环境验证 + 全程截图标注**:在测试环境用真实数据、真实页面交互测试本次改动(遵循「⚠️ 页面功能验证铁律」「⚠️ 用户视角测试铁律」)。测试过程中每一步都截图保留(遵循「⚠️ 截图规范」:视口 3840px 宽、`fullPage` 全页、URL 可见、存盘到 `docs/` 对应子目录),并在每张截图上用**箭头标注**关键改动区域/验证点,让看的人一眼看懂这张图证明了什么。
|
|
129
129
|
4. **确认没问题才算完成**:测试通过、截图与箭头标注齐全、功能符合预期,才算真正完成。禁止测试没跑、截图没标注就宣称完成。
|
|
130
|
-
5.
|
|
130
|
+
5. **把 PR 链接发给用户**:确认没问题后,先把 PR 链接发送给用户(`gh pr view <PR> --json url -q .url`),让用户能直接打开查看,再执行发版。
|
|
131
|
+
6. **发新版本**:确认没问题、PR 链接已发送后,按上面三步收尾完成冲突检查与静态编译检查,PR 合并后执行根目录 `./release.sh` 发新版本。
|
|
131
132
|
- ⚠️ **私有仓库的 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 引用」的流程,图片链接一律拼接为后一种格式。
|
|
132
133
|
|
|
133
134
|
## 安全
|