@routerhub/agent-rules 1.5.119 → 1.5.120

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.
Files changed (4) hide show
  1. package/AGENTS.base.md +4 -0
  2. package/package.json +1 -1
  3. package/rules/global.md +4 -0
  4. package/skills/create-pr/SKILL.md +25 -0
package/AGENTS.base.md CHANGED
@@ -95,6 +95,10 @@
95
95
  - ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `![](CDN_URL)` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
96
96
  - ⚠️ 创建 PR 使用 `/create-pr` skill（自动生成中文内容 + 效果截图 + CDN 上传）。
97
97
  - ⚠️ **创建 PR 后，必须先检查与主分支（默认分支）是否有冲突**：用 `gh pr view <PR> --json mergeable -q .mergeable` 检查（`MERGEABLE`=无冲突可合并，`CONFLICTING`=存在冲突，`UNKNOWN`=GitHub 尚未判定，稍后复查）。若存在冲突，必须先解决冲突再交付 review——`git merge origin/main`（或 `git rebase origin/main`）→ 解决冲突文件 → 测试通过 → 推送，确保 PR 处于可合并状态，禁止把带冲突的 PR 抛给 reviewer。
98
+ - ⚠️ **创建 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后发新版本**，三步收尾缺一不可：
99
+ 1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
100
+ 2. **GitHub 静态编译检查**：用 `gh pr checks <PR>` 查看 CI 检查状态（`success`=通过，`failure`=失败，`pending`=进行中）。存在失败项时，必须定位失败根因、修改代码并重新推送，直到全部通过，禁止把静态编译未通过的 PR 抛给 reviewer。
101
+ 3. **发新版本**：PR 合并后按项目发布流程发布新版本（本项目统一执行根目录 `./release.sh`，自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。
98
102
  - ⚠️ **私有仓库的 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 引用」的流程，图片链接一律拼接为后一种格式。
99
103
 
100
104
  ## 安全
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@routerhub/agent-rules",
3
- "version": "1.5.119",
3
+ "version": "1.5.120",
4
4
  "description": "Shared Copilot agent rules and guidelines for RouterHub projects",
5
5
  "main": "AGENTS.base.md",
6
6
  "bin": {
package/rules/global.md CHANGED
@@ -95,6 +95,10 @@ name: "通用规则"
95
95
  - ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `![](CDN_URL)` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
96
96
  - ⚠️ 创建 PR 使用 `/create-pr` skill（自动生成中文内容 + 效果截图 + CDN 上传）。
97
97
  - ⚠️ **创建 PR 后，必须先检查与主分支（默认分支）是否有冲突**：用 `gh pr view <PR> --json mergeable -q .mergeable` 检查（`MERGEABLE`=无冲突可合并，`CONFLICTING`=存在冲突，`UNKNOWN`=GitHub 尚未判定，稍后复查）。若存在冲突，必须先解决冲突再交付 review——`git merge origin/main`（或 `git rebase origin/main`）→ 解决冲突文件 → 测试通过 → 推送，确保 PR 处于可合并状态，禁止把带冲突的 PR 抛给 reviewer。
98
+ - ⚠️ **创建 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后发新版本**，三步收尾缺一不可：
99
+ 1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
100
+ 2. **GitHub 静态编译检查**：用 `gh pr checks <PR>` 查看 CI 检查状态（`success`=通过，`failure`=失败，`pending`=进行中）。存在失败项时，必须定位失败根因、修改代码并重新推送，直到全部通过，禁止把静态编译未通过的 PR 抛给 reviewer。
101
+ 3. **发新版本**：PR 合并后按项目发布流程发布新版本（本项目统一执行根目录 `./release.sh`，自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）。
98
102
  - ⚠️ **私有仓库的 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 引用」的流程，图片链接一律拼接为后一种格式。
99
103
 
100
104
  ## 安全
package/skills/create-pr/SKILL.md CHANGED
@@ -94,6 +94,30 @@ gh pr create \
94
94
  - 关联 issue：如有
95
95
  - Milestone：如有
96
96
 
97
+ ### 7. 创建 PR 后收尾检查（冲突 + 静态编译 + 发版本）
98
+
99
+ ⚠️ 创建 PR 后，三步收尾缺一不可，禁止创建完 PR 就直接抛给 reviewer。
100
+
101
+ **① 与主分支冲突检查**：
102
+ ```bash
103
+ gh pr view <PR> --json mergeable -q .mergeable
104
+ ```
105
+ - `MERGEABLE`=无冲突可合并
106
+ - `CONFLICTING`=存在冲突：`git merge origin/$DEFAULT_BRANCH`（或 `git rebase origin/$DEFAULT_BRANCH`）→ 解决冲突文件 → 测试通过 → 推送
107
+ - `UNKNOWN`=GitHub 尚未判定，稍后复查
108
+
109
+ **② GitHub 静态编译检查**：
110
+ ```bash
111
+ gh pr checks <PR>
112
+ ```
113
+ - `success`=通过，`failure`=失败，`pending`=进行中
114
+ - 存在失败项：定位失败根因 → 修改代码 → 重新推送，直到全部通过
115
+ - 禁止把静态编译未通过的 PR 抛给 reviewer
116
+
117
+ **③ 发新版本**：
118
+ - PR 合并后按项目发布流程发布新版本
119
+ - 本项目统一执行根目录 `./release.sh`（自动完成 patch 版本号 +1、更新 package.json、`git commit`/`push`、打 tag、`npm publish`）
120
+
97
121
  ## 重要规则
98
122
 
99
123
  - ⚠️ 一个 PR 只做一件事
@@ -101,5 +125,6 @@ gh pr create \
101
125
  - ⚠️ 必须附截图作为可视化证据
102
126
  - ⚠️ 截图禁止提交到 Git 仓库
103
127
  - ⚠️ PR 截图直接内嵌在 Description 正文中（Markdown 图片语法）
128
+ - ⚠️ 创建 PR 后必须做三步收尾：冲突检查 → 静态编译检查 → PR 合并后发新版本（见步骤 7）
104
129
  - 先开 Draft PR，准备好再标记 Ready for review
105
130
  - 作者不能 Approve 自己的 PR