@routerhub/agent-rules 1.5.76 → 1.5.78
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 +14 -0
- package/package.json +1 -1
- package/rules/global.md +14 -0
package/AGENTS.base.md
CHANGED
|
@@ -110,6 +110,11 @@ Closes #456
|
|
|
110
110
|
- 必须避免以下反模式：Test Plan 只写”测了没问题”；Description 只有”fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
|
|
111
111
|
- PR 规范可按团队约定微调字段，但”充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
|
|
112
112
|
|
|
113
|
+
## ⚠️ PR 提交附加规则（项目强制）
|
|
114
|
+
|
|
115
|
+
- ⚠️ **强制要求：每个 PR 必须在 Description 中附上对应的需求文档链接或需求描述**，明确说明本次改动对应的需求来源。需求文档位于 `docs/` 目录，如该需求尚无文档则须在 PR Description 中写出完整的需求描述（含背景、目标、功能点、验收标准）。没有需求文档或需求描述的 PR 不允许进入审阅，Reviewer 应直接 Request changes。
|
|
116
|
+
- ⚠️ **强制要求：每个 PR 必须附上功能效果截图**，截图需清晰展示改动前后的页面效果对比。无论是否涉及 UI 改动都必须贴图：UI 改动贴前后对比截图，接口/后端改动贴请求响应截图或功能验证截图，修 bug 贴复现前后对比截图。没有效果截图的 PR 不允许合入。
|
|
117
|
+
|
|
113
118
|
## 安全
|
|
114
119
|
|
|
115
120
|
- 用户明确要求上线/部署生产环境时，直接执行，无需二次确认。
|
|
@@ -119,6 +124,15 @@ Closes #456
|
|
|
119
124
|
|
|
120
125
|
- 新需求先在 `docs/` 写文档，含：目标、范围、功能要求、验收标准。
|
|
121
126
|
|
|
127
|
+
## ⚠️ Superpowers 需求开发流程（强制）
|
|
128
|
+
|
|
129
|
+
- ⚠️ **每一个新需求、每一次改动，必须严格按以下 Superpowers 流程执行，不可跳过任何步骤：**
|
|
130
|
+
1. **确定设计文档**：在写任何代码之前，必须先明确当前改动归属哪个设计文档（`docs/` 目录下的 HTML 文档）。如该文档不存在，必须先创建设计文档，含目标、范围、功能要求、验收标准。
|
|
131
|
+
2. **准备测试用例**：设计文档确定后，必须先准备测试用例，明确要测什么、怎么测、预期结果是什么。
|
|
132
|
+
3. **开始写代码**：前两步完成后，才能开始编写代码实现。
|
|
133
|
+
4. **发新版本**：代码完成并通过测试后，执行 `./release.sh` 发版。
|
|
134
|
+
- ⚠️ **禁止跳过设计文档和测试用例直接写代码。** 没有设计文档和测试用例的改动不得开始编码。
|
|
135
|
+
|
|
122
136
|
## 文档格式
|
|
123
137
|
|
|
124
138
|
- 所有新建文档必须使用 HTML 格式（`.html`），禁止使用 Markdown（`.md`）格式。
|
package/package.json
CHANGED
package/rules/global.md
CHANGED
|
@@ -112,6 +112,11 @@ Closes #456
|
|
|
112
112
|
- 必须避免以下反模式：Test Plan 只写”测了没问题”；Description 只有”fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
|
|
113
113
|
- PR 规范可按团队约定微调字段，但”充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
|
|
114
114
|
|
|
115
|
+
## ⚠️ PR 提交附加规则（项目强制）
|
|
116
|
+
|
|
117
|
+
- ⚠️ **强制要求：每个 PR 必须在 Description 中附上对应的需求文档链接或需求描述**，明确说明本次改动对应的需求来源。需求文档位于 `docs/` 目录，如该需求尚无文档则须在 PR Description 中写出完整的需求描述（含背景、目标、功能点、验收标准）。没有需求文档或需求描述的 PR 不允许进入审阅，Reviewer 应直接 Request changes。
|
|
118
|
+
- ⚠️ **强制要求：每个 PR 必须附上功能效果截图**，截图需清晰展示改动前后的页面效果对比。无论是否涉及 UI 改动都必须贴图：UI 改动贴前后对比截图，接口/后端改动贴请求响应截图或功能验证截图，修 bug 贴复现前后对比截图。没有效果截图的 PR 不允许合入。
|
|
119
|
+
|
|
115
120
|
## 安全
|
|
116
121
|
|
|
117
122
|
- 用户明确要求上线/部署生产环境时，直接执行，无需二次确认。
|
|
@@ -121,6 +126,15 @@ Closes #456
|
|
|
121
126
|
|
|
122
127
|
- 新需求先在 `docs/` 写文档，含：目标、范围、功能要求、验收标准。
|
|
123
128
|
|
|
129
|
+
## ⚠️ Superpowers 需求开发流程（强制）
|
|
130
|
+
|
|
131
|
+
- ⚠️ **每一个新需求、每一次改动，必须严格按以下 Superpowers 流程执行，不可跳过任何步骤：**
|
|
132
|
+
1. **确定设计文档**：在写任何代码之前，必须先明确当前改动归属哪个设计文档（`docs/` 目录下的 HTML 文档）。如该文档不存在，必须先创建设计文档，含目标、范围、功能要求、验收标准。
|
|
133
|
+
2. **准备测试用例**：设计文档确定后，必须先准备测试用例，明确要测什么、怎么测、预期结果是什么。
|
|
134
|
+
3. **开始写代码**：前两步完成后，才能开始编写代码实现。
|
|
135
|
+
4. **发新版本**：代码完成并通过测试后，执行 `./release.sh` 发版。
|
|
136
|
+
- ⚠️ **禁止跳过设计文档和测试用例直接写代码。** 没有设计文档和测试用例的改动不得开始编码。
|
|
137
|
+
|
|
124
138
|
## 文档格式
|
|
125
139
|
|
|
126
140
|
- 所有新建文档必须使用 HTML 格式（`.html`），禁止使用 Markdown（`.md`）格式。
|