cgraphx 2.0.3 → 2.0.6

package/dist/.claude-template/skills/iboc-check/filler-prompt.md

@@ -1,18 +1,18 @@
 # filler 子 agent prompt 模板
 
-> 主 agent 通过 Agent tool 调用本文件时,把这份完整内容作为 prompt 传给 `general-purpose` 子 agent,后接任务三件套:`\n\n---\n\n① 需求: <feature-id + 需求目录路径 + 文件前缀>`、`\n\n② 缺失产物: <单元测试规格 / 单元测试报告 / 设计文档 / 收口档案 中缺哪些>`、`\n\n③ 上下文: <git 用户名;对该需求的已知说明,如实现代码位置、备注>`。
+> 主 agent 通过 Agent tool 调用本文件时,把这份完整内容作为 prompt 传给 `general-purpose` 子 agent,后接任务三件套:`\n\n---\n\n① 需求: <feature-id + 需求目录路径 + 文件前缀>`、`\n\n② 缺失产物: <单元测试规格 / 单元测试报告 / 收口档案 中缺哪些>`、`\n\n③ 上下文: <git 用户名;对该需求的已知说明,如实现代码位置、备注>`。
 
 ## 你的角色
 
 你是 filler 子 agent,在**隔离上下文**里补全**单个需求**缺失的文档产物。主 agent 是 controller,只拿到你的最终返回,**看不到你的中间过程**(读文件、跑测试、试错等)。
 
-补账背景:该需求代码已完成,但文档产物(单元测试规格/报告、设计文档、收口档案)在规范建立前没产——你的职责是补齐产物,不是重新开发。
+补账背景:该需求代码已完成,但文档产物(单元测试规格/报告、收口档案)在规范建立前没产——你的职责是补齐产物,不是重新开发。
 
 ## 工作流
 
 ### 1. 复核缺失项
 
-controller 已核过四样,缺失清单在 prompt 里。开工前再验一次文件是否真不存在(防误报);已存在的产物**不重产、不覆盖**。
+controller 已核过缺失项(已按用户勾选的产物范围过滤),缺失清单在 prompt 里。开工前再验一次文件是否真不存在(防误报);已存在的产物**不重产、不覆盖**。
 
 ### 2. 按依赖顺序补全
 
@@ -20,7 +20,6 @@ controller 已核过四样,缺失清单在 prompt 里。开工前再验一次文
 |---|---|
 | 单元测试规格 | `/write-unit-test-spec` |
 | 单元测试报告 | `/write-unit-test-code`(依赖规格;规格是本次刚补的,接着跑) |
-| 设计文档 | `/write-design-doc` |
 | 收口档案 | `/end` |
 
 逐个调用对应 skill,**完整遵循该 skill 自己的规则**——它怎么要求你怎么做:实现缺失的场景 `it.skip` 占位、测试失败如实报告、不写业务实现代码、不修实现 bug、不假装通过。skill 的边界就是你的边界,不越权替它判断。

package/dist/.claude-template/skills/run-api-test/SKILL.md

@@ -36,8 +36,8 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 
 | skill | 关系 | 说明 |
 |---|---|---|
-| `write-api` | 上游 | 产 .bru + 测试规格 + environments;本 skill 消费这些产物跑测试,不调它也不改 .bru |
-| `write-api-doc` | 独立并列 | 不互相调用;本 skill 产测试报告 + JSONL,write-api-doc 产 HTML 接口文档 |
+| `write-api` | 上游 | 产 .bru + 接口测试规格 + environments;本 skill 消费这些产物跑测试,不调它也不改 .bru |
+| `write-api-doc` | 独立并列 | 不互相调用;本 skill 产接口测试报告 + JSONL,write-api-doc 产 HTML 接口文档 |
 | `db-query` | 复用 | R4 核实写接口 DB 副作用;受 db-query 既有只读约束 |
 | `implementation` / `subagent-implement` | 下游 | 测试失败后由用户决定是否调起修 bug |
 | `write-design-doc` | 独立 | 发布后按需产设计文档 |
@@ -58,8 +58,8 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 - 文件名不得包含 `/`、`:`、`*`、`?`、`"`、`<`、`>`、`|`
 
 产物文件名(归用户指定的 feature 目录):
-- Markdown 报告:`docs/features/<feature-id>/<文件前缀>-测试报告.md`
-- JSONL 验证记录:`docs/features/<feature-id>/<文件前缀>-测试验证.jsonl`
+- Markdown 报告:`docs/features/<feature-id>/<文件前缀>-接口测试报告.md`
+- JSONL 验证记录:`docs/features/<feature-id>/<文件前缀>-接口测试验证.jsonl`
 
 格式见 `references/report-format.md`。
 
@@ -72,7 +72,7 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
       ↓
 用户给的是什么?
       ├─ 指定了需求(feature-id / spec / 需求名)
-      │   → AI 查该需求的 <文件前缀>-api-spec.md,拿到接口清单 + 场景
+      │   → AI 查该需求的 <文件前缀>-接口测试-spec.md,拿到接口清单 + 场景
       │   → 提示用户确认"本次测试需求 X,涉及 N 接口 M 场景,确认?"
       │   → 用户确认后进入 R1
       │
@@ -80,7 +80,7 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
       │   → skill 主动问"测哪个需求?"
       │   → AI 扫 docs/bruno/<服务>*/<需求前缀>/<接口名>/ 哪些存在,列出测过该接口的需求
       │   → 列出来让用户选(若 0 个需求,提示用户先跑 /write-api)
-      │   → 选定后,AI 查该需求 api-spec.md 拿该接口的场景
+      │   → 选定后,AI 查该需求 接口测试-spec.md 拿该接口的场景
       │   → 提示用户确认后进入 R1
       │
       └─ 都没指定
@@ -101,10 +101,10 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 
 - **前置**:触发逻辑锁定一个 feature-id
 - **行为**:按 `references/test-scope.md` 拿到本次测试的 .bru 清单
-  - 查 `<文件前缀>-api-spec.md` 拿接口清单 + 场景 + .bru 路径
+  - 查 `<文件前缀>-接口测试-spec.md` 拿接口清单 + 场景 + .bru 路径
   - 交叉校验 .bru 文件实际存在
   - 显示测试范围给用户确认
-- **校验失败**(api-spec 不存在 / .bru 缺失)→ 报错并退出
+- **校验失败**(接口测试规格不存在 / .bru 缺失)→ 报错并退出
 - **用户取消** → 退出
 - **结果**:得到本次跑的 .bru 清单
 
@@ -131,15 +131,15 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 - **db-query skill 失败** → 该接口记"无法核实" + 状态 `失败-DB副作用`,**不阻塞其他接口**
 - **结果**:逐接口 DB 核实记录写入 JSONL
 
-### R5. 产出测试报告
+### R5. 产出接口测试报告
 
 - **前置**:R3 + R4 完成
 - **行为**:按 `references/report-format.md` 汇总产出
-  - Markdown 报告 `<文件前缀>-测试报告.md`(汇总 + 逐接口结果 + 失败分类 + DB 核实小结 + 下一步建议)
+  - Markdown 报告 `<文件前缀>-接口测试报告.md`(汇总 + 逐接口结果 + 失败分类 + DB 核实小结 + 下一步建议)
     - **按接口聚合**:同接口的场景先展示摘要，再展示详情
     - **展示级别**:主场景/涉及业务规则的异常=详细展示；简单边界=简单展示；失败场景=必须详细展示
     - **约束**:一个接口最多 2 个详细展示的场景
-  - JSONL `<文件前缀>-测试验证.jsonl`(R4 写接口记录 + R5 补齐查询接口记录)
+  - JSONL `<文件前缀>-接口测试验证.jsonl`(R4 写接口记录 + R5 补齐查询接口记录)
   - JSON 中间结果丢弃
 - **报告归属**:归用户指定的 feature 目录,即使接口关联多 feature 也不混
 - **结果**:报告落盘;skill 结束
@@ -148,10 +148,10 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 
 | 场景 | 行为 |
 |---|---|
-| 用户指定需求但 api-spec 不存在 | 报"需求 X 无测试规格,请先跑 /write-api"并退出 |
+| 用户指定需求但接口测试规格不存在 | 报"需求 X 无接口测试规格,请先跑 /write-api"并退出 |
 | 用户指定接口但 .bru 不存在 | 报"接口 Y 无 .bru,请先跑 /write-api"并退出 |
 | 用户指定接口但扫目录发现 0 个需求测过 | 提示"未在 docs/bruno/ 下找到测过接口 Y 的需求,请先跑 /write-api" |
-| api-spec §5 列出的 .bru 实际不存在 | 报"需求 X 接口 Y 场景 Z 的 .bru 缺失,请先跑 /write-api"并退出 |
+| 接口测试规格 §5 列出的 .bru 实际不存在 | 报"需求 X 接口 Y 场景 Z 的 .bru 缺失,请先跑 /write-api"并退出 |
 | 本地服务未启动 | 暂停 + 提示用户启动,等待回车继续 |
 | env 文件缺失 | 报"环境缺失,请先跑 /write-api"并退出,不自动生成 |
 | 服务起了但接口 404 | 记 `失败-HTTP`,标注可能路由未注册或路径不对 |
@@ -164,7 +164,7 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 ## 质量检查
 
 跑完后自检:
-- 报告归指定的 feature 目录(`<文件前缀>-测试报告.md` + `<文件前缀>-测试验证.jsonl`)
+- 报告归指定的 feature 目录(`<文件前缀>-接口测试报告.md` + `<文件前缀>-接口测试验证.jsonl`)
 - 写接口 DB 核实到位,不存在"只看 HTTP 200 就算过"的写接口
 - 服务未就绪时没盲跑,没产 connection refused 失败报告
 - 失败接口有原因分类(数据问题 / 代码 bug / 服务问题 / 断言过严)
@@ -177,7 +177,7 @@ description: 在 write-api 生成 .bru 后,跑接口测试 + 核实写接口 DB
 ## 收尾
 
 提示用户:
-1. 测试报告位置(`<文件前缀>-测试报告.md`)
+1. 接口测试报告位置(`<文件前缀>-接口测试报告.md`)
 2. 通过 / 失败 / 跳过汇总
 3. 失败接口清单 + 原因分类
 4. 下一步建议:

package/dist/.claude-template/skills/run-api-test/assets/{template-test-report.md → template-/346/216/245/345/217/243/346/265/213/350/257/225/346/212/245/345/221/212.md}

@@ -1,6 +1,6 @@
 # 接口测试报告模板
 
-适用于 `run-api-test` skill 在 R5 生成。默认输出到 `docs/features/<feature-id>/<文件前缀>-测试报告.md`。
+适用于 `run-api-test` skill 在 R5 生成。默认输出到 `docs/features/<feature-id>/<文件前缀>-接口测试报告.md`。
 
 本模板由 skill 在 R5 填充:汇总 + 逐接口结果 + 失败原因分类 + 下一步建议。
 
@@ -22,7 +22,7 @@
 
 > feature-id: <feature-id>
 > 生成时间: <YYYY-MM-DD HH:MM>
-> 关联测试规格: <文件前缀>-api-spec.md
+> 关联接口测试规格: <文件前缀>-接口测试-spec.md
 > 关联 .bru 集合: docs/bruno/<服务>/<需求前缀>/
 
 ## 1. 汇总
@@ -400,10 +400,10 @@ Content-Type: application/json
 
 ## 6. 产物清单
 
-- 测试规格: `<文件前缀>-api-spec.md`
+- 接口测试规格: `<文件前缀>-接口测试-spec.md`
 - .bru collection: `docs/bruno/<服务>/<需求前缀>/<接口名>/`
 - Markdown 报告: 本文件
-- JSONL 验证记录: `<文件前缀>-测试验证.jsonl`
+- JSONL 验证记录: `<文件前缀>-接口测试验证.jsonl`
 ```
 
 ## 填写说明

package/dist/.claude-template/skills/run-api-test/references/bru-run.md

@@ -10,7 +10,7 @@ bru run docs/bruno/<服务>/<接口名>/ --env local --output <临时 JSON 路
 
 | 参数 | 说明 |
 |---|---|
-| 路径参数 | R1 清单涉及的接口目录(从 api-spec §5 取),不是全项目 `docs/bruno/` |
+| 路径参数 | R1 清单涉及的接口目录(从接口测试规格 §5 取),不是全项目 `docs/bruno/` |
 | `--env local` | 使用 `docs/bruno/environments/local.bru` 的变量(用户切换时透传 `--env staging` / `--env production`) |
 | `--output <path>` | JSON 中间结果输出路径(临时,跑完即丢,不归档) |
 | `-r` | 递归跑目录下所有 .bru |

package/dist/.claude-template/skills/run-api-test/references/db-verification.md

@@ -16,7 +16,7 @@ R1 清单里若没有写接口,**整个 R4 跳过**,直接 R5。
 
 - 写接口的 `.bru` — 含 docs 段业务说明 + tests 段 DB 副作用预期注释(write-api S3 写的)
 - 跑测试后的响应 — R3 JSON 中间结果里的响应体
-- 接口语义 — 从 api-spec §2 或代码拿(预期应该写什么)
+- 接口语义 — 从接口测试规格 §2 或代码拿(预期应该写什么)
 - DB 状态 — 通过 `db-query` 查实际数据
 
 ### AI 动作
@@ -42,7 +42,7 @@ R1 清单里若没有写接口,**整个 R4 跳过**,直接 R5。
 
 ### 输出
 
-每个写接口的每个跑过场景,输出一条 JSON,写入 `<文件前缀>-测试验证.jsonl`(字段格式见 `report-format.md` § JSONL 字段)。
+每个写接口的每个跑过场景,输出一条 JSON,写入 `<文件前缀>-接口测试验证.jsonl`(字段格式见 `report-format.md` § JSONL 字段)。
 
 ## 失败处理
 

package/dist/.claude-template/skills/run-api-test/references/report-format.md

@@ -1,11 +1,11 @@
-# R5 测试报告规范
+# R5 接口测试报告规范
 
 ## 产物(两类)
 
 | 产物 | 路径 | 用途 |
 |---|---|---|
-| Markdown 报告 | `docs/features/<feature-id>/<文件前缀>-测试报告.md` | 给人看:汇总 + 逐场景详细结果 + 失败汇总 + DB 核实小结 + 下一步建议 |
-| JSONL 验证记录 | `docs/features/<feature-id>/<文件前缀>-测试验证.jsonl` | AI 逐接口 DB 验证记录,供下游 skill 程序化处理 |
+| Markdown 报告 | `docs/features/<feature-id>/<文件前缀>-接口测试报告.md` | 给人看:汇总 + 逐场景详细结果 + 失败汇总 + DB 核实小结 + 下一步建议 |
+| JSONL 验证记录 | `docs/features/<feature-id>/<文件前缀>-接口测试验证.jsonl` | AI 逐接口 DB 验证记录,供下游 skill 程序化处理 |
 
 **JSON 中间结果**(R3 `bru run --output` 产的)临时,**不归档**——跑完即丢。
 
@@ -17,7 +17,7 @@
 
 ## Markdown 报告章节
 
-完整骨架见 `assets/template-test-report.md`。AI 生成时按以下章节填:
+完整骨架见 `assets/template-接口测试报告.md`。AI 生成时按以下章节填:
 
 ### §1. 汇总
 
@@ -91,7 +91,7 @@
 
 ### §6. 产物清单
 
-固定四项:测试规格、.bru collection、Markdown 报告(本文件)、JSONL 验证记录。
+固定四项:接口测试规格、.bru collection、Markdown 报告(本文件)、JSONL 验证记录。
 
 ## JSONL 字段
 
@@ -111,7 +111,7 @@
 
 查询接口 `db_verification.required = false, conclusion = "not_required"`。
 
-完整示例见 `assets/template-test-verify.jsonl`。
+完整示例见 `assets/template-接口测试验证.jsonl`。
 
 ## 状态枚举
 

package/dist/.claude-template/skills/run-api-test/references/service-readiness.md

@@ -4,7 +4,7 @@
 
 按以下优先级检测,**任一通过即视为就绪**:
 
-1. **测试规格声明的服务地址** — `<文件前缀>-api-spec.md` §1 接口清单声明的"服务地址"(由 write-api S2 生成)能 TCP 连通
+1. **接口测试规格声明的服务地址** — `<文件前缀>-接口测试-spec.md` §1 接口清单声明的"服务地址"(由 write-api S2 生成)能 TCP 连通
 2. **bruno env 的 baseUrl** — `docs/bruno/environments/local.bru` 里的 `baseUrl`(或对应服务端口变量)能 TCP 连通
 
 两者都失败 → 视为未就绪,进入暂停等待。

package/dist/.claude-template/skills/run-api-test/references/test-scope.md

@@ -2,9 +2,9 @@
 
 ## 输入
 
-R1 的输入由 SKILL.md 触发逻辑(三分支)锁定一个 feature-id 后,从该 feature 的测试规格文档拿:
+R1 的输入由 SKILL.md 触发逻辑(三分支)锁定一个 feature-id 后,从该 feature 的接口测试规格文档拿:
 
-- 路径:`docs/features/<feature-id>/<文件前缀>-api-spec.md`
+- 路径:`docs/features/<feature-id>/<文件前缀>-接口测试-spec.md`
 - §1 接口清单:方法 + 路径 + 是否写接口
 - §2 测试场景:每接口要测的场景名(正常/缺字段/不存在等)
 - §5 接口映射:场景 → 接口 → .bru 文件路径
@@ -17,7 +17,7 @@ R1 的输入由 SKILL.md 触发逻辑(三分支)锁定一个 feature-id 后,从
 |---|---|
 | 全部存在 | 进入用户确认环节 |
 | 部分缺失 | 报"需求 X 接口 Y 场景 Z 的 .bru 缺失,请先跑 /write-api"并退出 |
-| 全部缺失(该 feature 没跑过 write-api) | 报"需求 X 无测试规格或 .bru 全缺失,请先跑 /write-api"并退出 |
+| 全部缺失(该 feature 没跑过 write-api) | 报"需求 X 无接口测试规格或 .bru 全缺失,请先跑 /write-api"并退出 |
 
 **理由**:跑测试前确保 .bru 都在,避免跑到一半才发现缺文件,浪费已跑的测试时间。
 
@@ -38,7 +38,7 @@ R1 的输入由 SKILL.md 触发逻辑(三分支)锁定一个 feature-id 后,从
 确认后回车继续,或 Ctrl+C 取消。
 ```
 
-**为什么不能省**:AI 反查"接口关联哪些需求"、读 api-spec 拿场景等过程中可能理解偏差;用户确认环节让用户兜底,避免跑错需求或跑错接口集合。
+**为什么不能省**:AI 反查"接口关联哪些需求"、读接口测试规格拿场景等过程中可能理解偏差;用户确认环节让用户兜底,避免跑错需求或跑错接口集合。
 
 ## 输出
 
@@ -57,8 +57,8 @@ docs/bruno/common/login/正常.bru
 
 | 情况 | 处理 |
 |---|---|
-| 用户指定需求但 api-spec.md 不存在 | 报"需求 X 无测试规格,请先跑 /write-api"并退出 |
+| 用户指定需求但 接口测试-spec.md 不存在 | 报"需求 X 无接口测试规格,请先跑 /write-api"并退出 |
 | 用户指定接口但接口目录不存在 | 报"接口 Y 无 .bru,请先跑 /write-api"并退出 |
 | 用户指定接口但扫目录发现 0 个需求测过 | 提示"未在 docs/bruno/ 下找到测过接口 Y 的需求,请先跑 /write-api" |
-| api-spec §5 列出的 .bru 实际不存在 | 报"需求 X 接口 Y 场景 Z 的 .bru 缺失,请先跑 /write-api"并退出 |
+| 接口测试规格 §5 列出的 .bru 实际不存在 | 报"需求 X 接口 Y 场景 Z 的 .bru 缺失,请先跑 /write-api"并退出 |
 | 用户确认环节用户取消 | 退出,不进入 R2 |

package/dist/.claude-template/skills/run-ui-test/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: run-ui-test
+description: 在 write-ui-test 生成用例规格后,通过 Playwright MCP 驱动浏览器执行 UI 功能测试——逐用例操作页面 + 预期验证点截图(按功能点命名)+ 出报告。触发时由用户指定需求;用例规格缺失报错退出。执行前五道关:playwright MCP 可用 → 需求锁定 → 执行模式与入口 URL 人工给 → 服务就绪人工确认 → 数据前提人工备齐;登录由 agent 用用例记录的账号自己走,验证码/SSO 暂停找人。不验库(写操作也只验 UI 表现);失败只报告不修代码不用例不重跑,交用户决定。不调 write-ui-test、不改用例规格。Use when 用户要求跑 UI 功能测试 / 界面上验一下需求 / 跑下页面测试 / run-ui-test;write-ui-test 跑完后用户要求执行。
+---
+
+# Run UI Test
+
+## 定位
+
+打靶 skill:在 `write-ui-test` 生成用例规格之后,通过 Playwright MCP 驱动浏览器执行 + 截图 + 出报告。不改用例、不修代码、不重跑,失败交用户决定。
+
+`write-ui-test` 负责"造弹药",`run-ui-test` 负责"打靶"。两者独立,同一份用例规格可被多次复用(改代码或改用例后重跑)。
+
+与接口测试的分工:**接口测试验接口契约与数据层(查库),本流程只验页面表现与交互(渲染/跳转/提示/回显),不验库**——两层各司其职。
+
+## HARD-GATE
+
+- **不验库** —— 写操作用例也只验 UI 表现,数据层正确性归 `/run-api-test`
+- **失败只报告** —— 不修代码、不改用例、不自动重跑,交用户决定
+- **MCP 缺失不盲跑** —— 当前会话无 playwright MCP 工具 → 输出安装指引并退出
+- **数据前提未备齐不跑** —— 用例规格 §3 清单逐项请用户确认,未备齐暂停等待
+- **报告永远归一个 feature 目录** —— 归用户触发时指定的需求目录,不混
+
+## Trigger
+
+**使用此 skill 当**:
+- 用户完成 `/write-ui-test` 后,要求"跑 UI 功能测试""界面上验一下"
+- 用户说"run-ui-test""跑下需求 X 的页面测试"
+- 代码改完后,用户要重跑验证修复
+
+**不要使用此 skill 当**:
+- 生成用例 → 用 `/write-ui-test`(本 skill 假设用例规格已存在)
+- 接口测试 → 用 `/run-api-test`
+- 视觉回归 / 跨浏览器兼容 / 性能测试 → 非本流程目标,不接
+- 修代码 / 改用例 → 用户手动或走 `/implementation`(本 skill 只测不修)
+
+## 与既有 skill 边界
+
+| skill | 关系 | 说明 |
+|---|---|---|
+| `write-ui-test` | 上游 | 产用例规格;本 skill 消费它跑测试,不调它也不改用例 |
+| `run-api-test` | 平行(推荐先跑) | 接口层验证 + 查库;本流程不重复验库;先接口后 UI 仅推荐顺序,非硬前置 |
+| `implementation` / `subagent-implement` | 下游 | 测试失败后由用户决定是否调起修 bug |
+
+## 依赖
+
+- 用例规格已存在(由 `/write-ui-test` 生成,在 `docs/features/<feature-id>/ui功能测试/<文件前缀>-ui功能测试-spec.md`)
+- 目标项目已安装 Playwright MCP(R0 校验,缺失给安装指引)
+- 服务已由人工启动(本地或已部署测试环境);入口 URL 明确(用例规格记录或用户给)
+- 用例规格 §3 数据前提已由人工备齐
+
+## feature-id 与文件前缀规则
+
+复用既有规则(同 `/write-api` / `/run-api-test` 的算法):
+
+- feature-id 格式:`YYYY-MM-DD-[业务ID-]<标题>`
+- 文件前缀:有业务ID = `<业务ID>-<标题>`,无业务ID = `<标题>`
+- 文件名不得包含 `/`、`:`、`*`、`?`、`"`、`<`、`>`、`|`
+
+产物文件名(归用户指定的 feature 目录):
+
+- 测试报告:`docs/features/<feature-id>/ui功能测试/<文件前缀>-ui功能测试报告.md`
+- 截图:`docs/features/<feature-id>/ui功能测试/<功能点名>.png`(同功能点多张追加 `-2`/`-3`)
+
+格式见 `references/report-format.md`。
+
+## 触发逻辑(用户给的是什么?)
+
+```
+用户触发 /run-ui-test
+      ↓
+用户给的是什么?
+      ├─ 指定了需求(feature-id / spec / 需求名)
+      │   → 查该需求的 ui功能测试/<文件前缀>-ui功能测试-spec.md
+      │   → 不存在 → 报"需求 X 无 UI 用例规格,请先跑 /write-ui-test"并退出
+      │
+      └─ 未指定
+          → 主动问"请指定需求(feature-id/spec/需求名)"
+          → 拿到后回到上面分支
+```
+
+**关键约束**:锁定一个 feature-id,报告归该 feature 目录;用例清单必须显示给用户确认后才执行。
+
+## 工作流
+
+按 R0-R6 顺序执行,报告规范见 `references/report-format.md`。
+
+### R0. Playwright MCP 就绪
+
+- **行为**:确认当前会话可用 playwright MCP 工具(浏览器导航/点击/输入/截图能力)
+- **缺失** → 输出安装指引并退出,不盲跑:
+  ```
+  claude mcp add playwright npx @playwright/mcp@latest
+  ```
+  (安装后重启会话再触发本 skill;本 skill 不替目标项目写 MCP 配置)
+
+### R1. 锁定需求与用例范围
+
+- **前置**:R0 通过
+- **行为**:按触发逻辑读用例规格;显示用例清单(功能点名 + 步骤摘要)给用户确认
+- **用户取消** → 退出
+
+### R2. 执行参数确认
+
+- **行为**:
+  - **运行模式**:问用户 headed(可视)还是无头——由人工定,不默认
+  - **入口 URL**:默认读用例规格 §1 记录值;用户触发时给了新值 → 以用户为准;两处都没有 → 向用户要。**不得隐式假设**
+
+### R3. 服务就绪 + 数据前提确认
+
+- **行为**:暂停请用户确认两项:
+  1. 服务已启动(本地或已部署测试环境),入口 URL 可访问
+  2. 用例规格 §3 数据前提清单已逐项备齐(全人工备)
+- **任一不满足** → 等待,不执行、不盲跑
+
+### R4. 登录
+
+- **前置**:用例规格 §4 标注需要登录
+- **行为**:agent 用 §4 记录的测试账号自己走登录动线
+- **卡住**(验证码/SSO/账号失效)→ 暂停请人工介入;人工处理完继续
+- **无需登录** → 跳过本步
+
+### R5. 逐用例执行
+
+- **行为**:按用例规格 §2 逐条执行:
+  1. 按操作步骤驱动页面
+  2. 验证预期表现(只验 UI,不查库)
+  3. 预期验证点截图,存 `ui功能测试/<功能点名>.png`
+- **单条失败** → 记录状态与原因,**继续下一条**,不阻塞
+- **浏览器 / MCP 崩溃** → 记「失败-环境」;能继续则继续,不能则停止执行出报告,如实标注未完成部分
+
+### R6. 产出测试报告
+
+- **前置**:R5 完成
+- **行为**:按 `references/report-format.md` 汇总产出 `<文件前缀>-ui功能测试报告.md`(汇总 + 逐用例结果 + 失败汇总 + 下一步建议 + 产物清单)
+- **报告归属**:归用户指定的 feature 目录
+- **同需求重复触发**:覆盖该需求报告,不增量合并
+
+## 状态枚举
+
+| 状态 | 含义 |
+|---|---|
+| `通过` | 步骤执行通 + 预期表现验证通 |
+| `失败-预期不符` | 步骤执行通,但 UI 表现与预期不符(疑似功能 bug) |
+| `失败-元素缺失` | 页面结构不符/定位不到元素(改版或实现缺失) |
+| `失败-环境` | 服务中途不可用 / 浏览器或 MCP 异常 |
+| `失败-登录` | 登录无法完成(账号/验证码/SSO) |
+| `跳过` | 用户取消该用例 / 前置不满足主动跳过 |
+
+## 异常速查
+
+| 场景 | 行为 |
+|---|---|
+| 用例规格缺失 | 报"需求 X 无 UI 用例规格,请先跑 /write-ui-test"并退出 |
+| playwright MCP 不可用 | 输出安装指引(`claude mcp add playwright npx @playwright/mcp@latest`)并退出 |
+| 入口 URL 不明 | 向用户要,不隐式假设 |
+| 服务未就绪 | 暂停等待人工启动,不盲跑 |
+| 数据前提未备齐 | 暂停等待人工准备 |
+| 登录卡住(验证码/SSO) | 暂停请人工介入 |
+| 单条用例失败 | 记状态 + 原因,继续其他用例 |
+| 浏览器 / MCP 崩溃 | 记「失败-环境」,出报告如实标注,不产误导性结论 |
+| 同需求重复触发 | 覆盖该需求报告,不增量合并 |
+
+## 质量检查
+
+跑完后自检:
+- 报告归指定的 feature 目录 `ui功能测试/`,截图同目录按功能点命名
+- 每条用例都有状态(六枚举之一),失败用例有原因分类
+- 全程没查库、没修代码、没改用例、没自动重跑
+- 五道前置关都过了才执行,没盲跑(MCP/URL/服务/数据)
+- 登录失败时暂停找了人,没硬闯
+- 用户确认环节有执行(用例清单显示给用户)
+
+## 收尾
+
+提示用户:
+1. 测试报告位置(`<文件前缀>-ui功能测试报告.md`)与截图目录
+2. 通过 / 失败 / 跳过汇总
+3. 失败用例清单 + 原因分类
+4. 下一步建议:
+   - 失败-预期不符 → 疑似功能 bug,走 `/implementation` 修,修完重跑 `/run-ui-test`
+   - 失败-元素缺失 → 确认页面结构是否改版;用例过时 → 走 `/write-ui-test` 重新派生
+   - 失败-环境 → 服务/浏览器问题,恢复后重跑
+   - 失败-登录 → 核对用例规格 §4 的测试账号
+
+不主动调用 `/implementation` 或其他下游 skill。不写 knowledge 文件。不修改用例规格 / spec / plan / 代码。

package/dist/.claude-template/skills/run-ui-test/references/report-format.md

@@ -0,0 +1,77 @@
+# R6 UI 功能测试报告规范
+
+## 产物
+
+| 产物 | 路径 | 用途 |
+|---|---|---|
+| Markdown 报告 | `docs/features/<feature-id>/ui功能测试/<文件前缀>-ui功能测试报告.md` | 给人看:汇总 + 逐用例结果 + 失败汇总 + 下一步建议 |
+| 截图 | `docs/features/<feature-id>/ui功能测试/<功能点名>.png` | 预期验证点留证,报告内相对路径引用 |
+
+**不产 JSONL**——本流程不验库,无程序化消费方。
+
+## 报告归属规则
+
+报告永远归用户触发时指定的需求目录。同需求重复触发 → 覆盖,不增量合并。
+
+## Markdown 报告章节
+
+### §1. 汇总
+
+| 指标 | 值 |
+|---|---|
+| 总用例数 | N |
+| 通过 | N |
+| 失败 | N |
+| 跳过 | N |
+| 通过率 | % |
+| 运行模式 | headed / 无头 |
+| 入口 URL | … |
+
+### §2. 逐用例结果 ⭐ 核心
+
+每用例一节。失败用例必须详细(步骤执行到哪一步、预期 vs 实际、截图);通过用例可简写。
+
+```markdown
+### 用例 1:新建客户 —— ✅ 通过
+
+步骤全部执行,预期验证通过。截图:![新建客户](新建客户.png)
+
+### 用例 2:编辑客户 —— ❌ 失败-预期不符
+
+- 执行到:步骤 3(点「保存」)
+- 预期:提示「保存成功」,列表联系电话更新为 13900139000
+- 实际:提示「保存成功」,但列表联系电话仍显示旧值;刷新后才更新
+- 截图:![编辑客户](编辑客户.png)
+- 原因分类:失败-预期不符(疑似保存后列表未重新拉取)
+```
+
+### §3. 失败汇总
+
+| 状态 | 数量 | 用例 |
+|---|---|---|
+| 失败-预期不符 | N | 用例名 |
+| 失败-元素缺失 | N | 用例名 |
+| 失败-环境 | N | 用例名 |
+| 失败-登录 | N | 用例名 |
+| **合计** | **N** | |
+
+无失败则写「本次无失败用例」。
+
+### §4. 下一步建议
+
+按失败类型给建议,不自动调下游 skill:
+
+- 失败-预期不符 → 疑似功能 bug,走 `/implementation` 修,修完重跑 `/run-ui-test`
+- 失败-元素缺失 → 确认页面结构是否改版;用例过时 → 走 `/write-ui-test` 重新派生
+- 失败-环境 → 服务/浏览器问题,恢复后重跑
+- 失败-登录 → 核对用例规格 §4 的测试账号
+
+### §5. 产物清单
+
+固定三项:用例规格、本报告、截图(列文件名)。
+
+## 状态枚举(与 SKILL.md 一致)
+
+`通过` / `失败-预期不符` / `失败-元素缺失` / `失败-环境` / `失败-登录` / `跳过`
+
+**前置暂停不记入报告,不算失败**(MCP 缺失/服务未就绪/数据未备齐时 skill 在 R0/R3 暂停,根本没进 R5)。

package/dist/.claude-template/skills/subagent-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: subagent-implement
-description: 复杂 plan 的子 agent 实现流程 — 主 agent 作为 controller,按依赖批次派 implementer 子 agent 实现 + 按风险做 spec 审查,所有任务完成后派 final quality reviewer 整体审查。Use when 执行计划/跑计划/按 plan 实现/派子 agent 实现/复杂实现/多任务实现/系统化实现/subagent 实现。
+description: 大规模 plan 的子 agent 实现流程 — 主 agent 作为 controller,按依赖批次派 implementer 子 agent 实现 + 按风险做 spec 审查,所有任务完成后派 final quality reviewer 整体审查。Use when 执行计划/跑计划/按 plan 实现/派子 agent 实现/复杂实现/多任务实现/系统化实现/subagent 实现。
 ---
 
 # Subagent-Implement
@@ -9,7 +9,8 @@ description: 复杂 plan 的子 agent 实现流程 — 主 agent 作为 controll
 
 - **主 agent 是统帅不是先锋**:只协调、把关、收口;实现全部派隔离上下文的 implementer 子 agent。
 - **质量靠结构,不靠自觉**:四件套注入让执行者无法漂移,sanity check 把每任务关,quality-reviewer 把最终关。
-- **门槛**:有 plan(或明确任务清单)+ ≥3 个任务 + 跨多文件域,或主 agent 上下文装不下。单文件/单模块/1-2 个任务 → 走 `implementation`;任务强耦合(后任务依赖前任务实时反馈)→ 走 `implementation`。
+- **门槛**:有 plan(或明确任务清单)+ 需求规模达「明显大」(跨 ≥3 个相互独立的模块、预估变更文件 ≥10、任务可独立派任),或主 agent 上下文装不下。单点/单模块/小规模变更 → 走 `implementation`;任务强耦合(后任务依赖前任务实时反馈)→ 走 `implementation`。反例:小全栈需求(加 1 字段 + 改 1 接口 + 1 页面展示,跨 3 域)→ `implementation`,不进本流程。
+- **拆细防线**:plan 任务明显过细(大量「改 1 字段 / 加 1 参数」级微任务)→ 先向用户提出合并建议再派任。
 
 ## 流程