@hupan56/wlkj 2.7.11 → 3.0.0

package/templates/qoder/skills/design-review/SKILL.md

@@ -1,82 +1,82 @@
----
-name: design-review
-description: "评审设计交付物的完整性。Review design artifacts for completeness. 用户说'评审设计''设计稿看一下''检查交互稿'时触发。"
-trigger: "user invokes /review design, asks to check design, or designer submits design artifacts"
----
-
-
-## 🔧 仓库根定位（QoderWork 桌面端 vs Qoder IDE/CLI）
-
-**后续脚本里的 `$R` 代表仓库根**，先确定它（QoderWork 桌面端工作目录不是仓库根，相对路径会失效）：
-```bash
-R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
-```
-> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `python .qoder/scripts/install_qoderwork.py`。
-
-# Design Review Skill（设计师 + PM 都可用）
-
-> 🚫 **边界铁律：蓝湖工具（`mcp__lanhu__*`）只能在本 skill（即 `/wl-design-spec 评审`）内部调用。**
-> 用户直接说"用蓝湖对比一下"而没走评审命令时，引导到 `/wl-design-spec 评审`。非侵入式，不裸调。
-
-## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
-
-- `.qoder/.developer` — 当前评审人
-- 设计文件路径由用户指定，或扫 `workspace/members/{dev}/drafts/prototype-*.html`
-- 若 `data/style/{需求名}-design-spec.json` 存在，作为评审基准（优先级最高）
-
-## 两种评审模式
-
-### 模式 A：评审 AI 原型（设计师审 AI 的活）
-
-设计师在 QoderWork 说"评审原型"，AI 拉出 `drafts/prototype-*.html`：
-
-1. 逐项检查（见下方 Checklist）
-2. **对照设计师 spec**：若 data/style/ 有 spec.json，检查原型是否匹配
-3. 输出问题清单（按严重度排序），设计师确认后 PM 说"修订原型"
-
-### 模式 B：评审设计师交付（PM 审设计师的活）
-
-PM 说"评审设计稿"，AI 检查设计师的 spec.json 或原型：
-
-1. 是否跟系统现有风格一致（对照 vben-style-reference.json / Vant 变量）
-2. 图标/颜色是否来自真源
-3. 是否覆盖 PRD 的所有界面需求
-
-## 检查项 (Checklist)
-
-- [ ] 组件规格完整（components.json 或 spec.json）
-- [ ] 交互流程覆盖所有状态（interaction-flow.md）
-- [ ] 技术约束已标注
-- [ ] 响应式/设计 Token 已定义
-- [ ] 符合 PRD 需求
-- [ ] **图标来自真源（data/index/ref-icon.json），无 emoji**（硬性）
-- [ ] 颜色来自真源（Web: ref-vben-style.json；APP: Vant 变量）
-- [ ] **若设计师 spec 存在：原型是否匹配 spec 的布局/配色/组件**（硬性）
-- [ ] 侧边栏/导航/表格/表单等关键区域是否跟系统其他页面一致
-- [ ] **🆕 按钮文案是否用了系统真实文案**（对照 DESIGN.md 的 "Real Button Texts" 段或 entity-registry，别用编的"新增/编辑"）
-- [ ] **🆕 布局是否跟同功能模块的标杆页面一致**（对照 DESIGN.md 的 "Feature Modules" 段）
-- [ ] **🆕 侧边栏宽度是否 = layout_fingerprint 的值**（fywl-ui 是 160px，不是 200px）
-- [ ] **🆕 若 spec 有 `lanhu_source`：原型配色是否忠于蓝湖原图**（调 `mcp__lanhu__get_ai_analyze_design_result` 拉蓝湖 CSS，逐项比原型 `:root` 的值是否一致；不一致=还原度问题）
-- [ ] **🆕 若 spec 有 `icons`：原型图标是否用了蓝湖切图**（别退回 emoji 或通用图标）
-
-**评审时可调 MCP 工具辅助：**
-- `mcp__qoder-knowledge-graph__feature_overview(feature='XX')` → 看这个功能模块的完整画像，对比原型是否遗漏页面/按钮
-- `mcp__qoder-knowledge-graph__get_design_system(platform='web')` → 拿到真实 token/按钮文案/模块标杆做对照
-- **`mcp__qoder-knowledge-graph__get_workflow(module='XX')`** → 查业务操作链（查询→新增→审批→...），检查原型是否覆盖了完整交互流程（而不只是静态页面）
-- **`mcp__coverage_matrix()`** → 查这个功能有没有测试覆盖，如果原型要改的页面有测试，提醒"改动后需回归测试"
-- **`mcp__lanhu__get_ai_analyze_design_result`** → spec 有 lanhu_source 时，拉蓝湖原图 CSS 做还原度比对（蓝湖不可用则跳过此项，不阻塞）
-
-## 输出
-
-报告：PASS 或 列出需修复的问题清单（按 🔴严重/🟡建议 分级）。
-
-## 埋点（评审完成后 AI 必须做）
-
-评审输出报告后，**立即调用 learning 引擎记录本次评审**（让团队学习哪些设计问题最常见）：
-
-```bash
-python "$R/.qoder/scripts/learn.py" record review_done "{\"target\":\"{被评审的原型或spec}\",\"result\":\"PASS或问题数\",\"issues\":[\"严重问题1\",\"建议1\"]}"
-```
-
-> 埋点失败不阻塞评审。数据进个人 journal，管理员聚合到 kg.duckdb 后，可统计"最常出现的设计问题"，反哺 design-import 防再犯。
-若不通过，附上修复建议和参考文件路径，PM 确认后 AI 修订原型。
+---
+name: design-review
+description: "评审设计交付物的完整性。Review design artifacts for completeness. "
+trigger: "user invokes /wl-* command explicitly"
+---
+
+
+## 🔧 仓库根定位（QoderWork 桌面端 vs Qoder IDE/CLI）
+
+**后续脚本里的 `$R` 代表仓库根**，先确定它（QoderWork 桌面端工作目录不是仓库根，相对路径会失效）：
+```bash
+R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
+```
+> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `python .qoder/scripts/setup/install_qoderwork.py`。
+
+# Design Review Skill（设计师 + PM 都可用）
+
+> 🚫 **边界铁律：蓝湖工具（`mcp__lanhu__*`）只能在本 skill（即 `/wl-design 评审`）内部调用。**
+> 用户直接说"用蓝湖对比一下"而没走评审命令时，引导到 `/wl-design 评审`。非侵入式，不裸调。
+
+## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
+
+- `.qoder/.developer` — 当前评审人
+- 设计文件路径由用户指定，或扫 `workspace/members/{dev}/drafts/prototype-*.html`
+- 若 `data/style/{需求名}-design-spec.json` 存在，作为评审基准（优先级最高）
+
+## 两种评审模式
+
+### 模式 A：评审 AI 原型（设计师审 AI 的活）
+
+设计师在 QoderWork 说"评审原型"，AI 拉出 `drafts/prototype-*.html`：
+
+1. 逐项检查（见下方 Checklist）
+2. **对照设计师 spec**：若 data/style/ 有 spec.json，检查原型是否匹配
+3. 输出问题清单（按严重度排序），设计师确认后 PM 说"修订原型"
+
+### 模式 B：评审设计师交付（PM 审设计师的活）
+
+PM 说"评审设计稿"，AI 检查设计师的 spec.json 或原型：
+
+1. 是否跟系统现有风格一致（对照 vben-style-reference.json / Vant 变量）
+2. 图标/颜色是否来自真源
+3. 是否覆盖 PRD 的所有界面需求
+
+## 检查项 (Checklist)
+
+- [ ] 组件规格完整（components.json 或 spec.json）
+- [ ] 交互流程覆盖所有状态（interaction-flow.md）
+- [ ] 技术约束已标注
+- [ ] 响应式/设计 Token 已定义
+- [ ] 符合 PRD 需求
+- [ ] **图标来自真源（data/index/ref-icon.json），无 emoji**（硬性）
+- [ ] 颜色来自真源（Web: ref-vben-style.json；APP: Vant 变量）
+- [ ] **若设计师 spec 存在：原型是否匹配 spec 的布局/配色/组件**（硬性）
+- [ ] 侧边栏/导航/表格/表单等关键区域是否跟系统其他页面一致
+- [ ] **🆕 按钮文案是否用了系统真实文案**（对照 DESIGN.md 的 "Real Button Texts" 段或 entity-registry，别用编的"新增/编辑"）
+- [ ] **🆕 布局是否跟同功能模块的标杆页面一致**（对照 DESIGN.md 的 "Feature Modules" 段）
+- [ ] **🆕 侧边栏宽度是否 = layout_fingerprint 的值**（fywl-ui 是 160px，不是 200px）
+- [ ] **🆕 若 spec 有 `lanhu_source`：原型配色是否忠于蓝湖原图**（调 `mcp__lanhu__get_ai_analyze_design_result` 拉蓝湖 CSS，逐项比原型 `:root` 的值是否一致；不一致=还原度问题）
+- [ ] **🆕 若 spec 有 `icons`：原型图标是否用了蓝湖切图**（别退回 emoji 或通用图标）
+
+**评审时可调 MCP 工具辅助：**
+- `mcp__qoder-knowledge-graph__feature_overview(feature='XX')` → 看这个功能模块的完整画像，对比原型是否遗漏页面/按钮
+- `mcp__qoder-knowledge-graph__get_design_system(platform='web')` → 拿到真实 token/按钮文案/模块标杆做对照
+- **`mcp__qoder-knowledge-graph__get_workflow(module='XX')`** → 查业务操作链（查询→新增→审批→...），检查原型是否覆盖了完整交互流程（而不只是静态页面）
+- **`mcp__coverage_matrix()`** → 查这个功能有没有测试覆盖，如果原型要改的页面有测试，提醒"改动后需回归测试"
+- **`mcp__lanhu__get_ai_analyze_design_result`** → spec 有 lanhu_source 时，拉蓝湖原图 CSS 做还原度比对（蓝湖不可用则跳过此项，不阻塞）
+
+## 输出
+
+报告：PASS 或 列出需修复的问题清单（按 🔴严重/🟡建议 分级）。
+
+## 埋点（评审完成后 AI 必须做）
+
+评审输出报告后，**立即调用 learning 引擎记录本次评审**（让团队学习哪些设计问题最常见）：
+
+```bash
+python "$R/.qoder/scripts/report/learn.py" record review_done "{\"target\":\"{被评审的原型或spec}\",\"result\":\"PASS或问题数\",\"issues\":[\"严重问题1\",\"建议1\"]}"
+```
+
+> 埋点失败不阻塞评审。数据进个人 journal，管理员聚合到 kg.duckdb 后，可统计"最常出现的设计问题"，反哺 design-import 防再犯。
+若不通过，附上修复建议和参考文件路径，PM 确认后 AI 修订原型。

package/templates/qoder/skills/prd-generator/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: prd-generator
-description: "生成 PRD + 平台匹配的原型。Generate PRD with platform-aware prototype. 用户说'写个需求''生成PRD''做个原型''保单这块加个功能''写个产品需求文档'时触发。"
-trigger: "user describes a requirement, asks for PRD, mockup, or invokes /wl-prd-full or /wl-prd-quick"
+description: "生成 PRD + 平台匹配的原型。Generate PRD with platform-aware prototype. "
+trigger: "user invokes /wl-* command explicitly"
 ---
 
 
@@ -11,7 +11,7 @@ trigger: "user describes a requirement, asks for PRD, mockup, or invokes /wl-prd
 ```bash
 R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
 ```
-> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `python .qoder/scripts/install_qoderwork.py`。
+> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `python .qoder/scripts/setup/install_qoderwork.py`。
 
 # PRD Generator Skill
 
@@ -43,15 +43,19 @@ R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
 - `.qoder/.current-task` — 当前活动任务
 - `data/index/.index-meta.json` — 知识图谱新鲜度
 
-### 写 PRD 前：一次取全（context_pack 已含数据库表结构+历史PRD）
+### 写 PRD 前：一次取全（prefetch 预测 + 批量预取）
 
-**只调 1 次** `context_pack`（第 1-8 段一次全返回），不要逐个调 MCP：
-- 第 4 段 = 历史 PRD（防重复，替代 search_prd）
-- 第 8 段 = 数据库表结构+真实字段（替代 query_schema）
-- 第 5 段 = 相关 API（替代 feature_overview）
+**写 PRD 第一件事：调 1 次 `prefetch`**（它会预测业务词 + 批量取多词上下文，合并去重）：
+```bash
+ROLE=$(python "$R/.qoder/scripts/report/role.py" 2>/dev/null || echo pm)
+python "$R/.qoder/scripts/kg/kg.py" prefetch "<需求描述>" --platform <p>
+```
+或直接：`python .qoder/scripts/kg/prefetch.py "<需求描述>" --platform <p>`
 
-**仅当 context_pack 没覆盖到时才额外调**（极少）：
-- 字段枚举值：`mcp__qoder-mysql__query_distinct(table='表名', column='状态列')` — context_pack 给了表结构但没给枚举取值，需要时才调
+prefetch 一次返回 8 段（含历史PRD/数据库表/真实字段/API/Wiki），等于把多个业务词的查询合并。**prefetch 之后严禁再串行 search/find/grep**（这是轮次爆炸的根因——查一个词不命中就换词再查 6+ 次）。
+
+**仅当 prefetch 明确没覆盖到时才补调一次**（极少）：
+- 字段枚举值：`mcp__qoder-mysql__query_distinct(table='表名', column='状态列')` — prefetch 给了表结构但没给枚举取值，需要时才调
 - 改表影响：`mcp__qoder-knowledge-graph__table_impact(table='表名')` — 评估改动范围时才调
 
 ## STEP 0: 必须先问平台
@@ -130,11 +134,17 @@ R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
 
 **"准"的保障。eval_prd.py 的 A1/A2/A3 已实现大半，这里提升为流程强制门。**
 
-生成后、发布前：
+生成后、发布前，**先跑角色+契约前置门，再跑质量分**：
 ```bash
-python "$R/.qoder/scripts/eval_prd.py" <draft-prd.md> <prototype.html>
+# 门 1+2: 角色边界(当前角色能否产 prd?) + 契约校验(@contract 头是否合规?)
+# 软提示不阻塞, 越权/无契约头会提示但仍可发布
+python "$R/.qoder/scripts/common/check_publish.py" prd <draft-prd.md>
+
+# 门 3: 质量分 (eval_prd 内部也会跑契约校验, 这里是质量评分)
+python "$R/.qoder/scripts/report/eval_prd.py" <draft-prd.md> <prototype.html>
 ```
-eval_prd < 80% 不准发布，按报告修到 PASS。
+- check_publish 越权提示 → 软提示(如 dev 产 prd 会提示"建议产品经理"),不阻塞
+- eval_prd < 80% 不准发布，按报告修到 PASS
 
 AI 在跑 eval_prd 前，自己先做内容自检（快档只查锁②）：
 
@@ -173,7 +183,7 @@ context_pack 字段段返回"无直接相关字段"时，**字段锁不报错，
 ## 取上下文 — 一次取全（不要逐个搜）
 
 ```bash
-python "$R/.qoder/scripts/context_pack.py" <关键词> --platform <web|app>
+python "$R/.qoder/scripts/kg/context_pack.py" <关键词> --platform <web|app>
 ```
 返回 7 章节（代码+页面+字段+PRD+API+样式+Wiki）。**只读最相关 1-2 个 Vue 文件**。
 
@@ -196,7 +206,7 @@ python "$R/.qoder/scripts/context_pack.py" <关键词> --platform <web|app>
 ## 原型规则
 
 - 从模板开始（`.qoder/templates/prototype-{web|app}.html`），模板已有正确颜色与 mixed-nav 多级菜单骨架
-- 先跑 `python "$R/.qoder/scripts/fill_prototype.py" <关键词> --platform <web|app>` 拿 80% 草稿;
+- 先跑 `python "$R/.qoder/scripts/report/fill_prototype.py" <关键词> --platform <web|app>` 拿 80% 草稿;
   它会按目标项目的 `layout_fingerprint` 自动填示例菜单骨架和真实字段,你只微调 20%
 - 颜色/布局指纹见 fill_prototype 输出的"设计 Token"段(布局模式/主色/侧边栏宽度)
 - **菜单层级**: 若需求描述了侧边栏/菜单结构(如"一级→二级,右侧三四级"),
@@ -211,7 +221,7 @@ python "$R/.qoder/scripts/context_pack.py" <关键词> --platform <web|app>
 PRD 写入 drafts 后，**顺手归档一份**到当前成员的按时间文件夹，方便人翻查"我那天做了啥"：
 
 ```bash
-python "$R/.qoder/scripts/archive_prd.py" <刚生成的PRD文件路径>
+python "$R/.qoder/scripts/report/archive_prd.py" <刚生成的PRD文件路径>
 ```
 
 > 归档产物：`workspace/members/{你的名字}/archive/{YYYY-MM-DD}/REQ-{编号}-{中文标题}.md`

package/templates/qoder/skills/prd-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: prd-review
-description: "评审 PRD 完整性与质量。Review PRD for completeness and quality. 用户说'评审PRD''PRD质量怎么样''检查一下这个需求文档'时触发。"
-trigger: "user invokes /review prd, asks to review/check PRD quality, or PM submits PRD"
+description: "评审 PRD 完整性与质量。Review PRD for completeness and quality. "
+trigger: "user invokes /wl-* command explicitly"
 ---
 
 
@@ -11,7 +11,7 @@ trigger: "user invokes /review prd, asks to review/check PRD quality, or PM subm
 ```bash
 R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
 ```
-> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `python .qoder/scripts/install_qoderwork.py`。
+> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `python .qoder/scripts/setup/install_qoderwork.py`。
 
 # PRD Review Skill
 
@@ -40,7 +40,7 @@ R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
 
 跑一次 EVA 门禁给出客观分数：
 ```bash
-python "$R/.qoder/scripts/eval_prd.py" <PRD路径> [原型HTML路径]
+python "$R/.qoder/scripts/report/eval_prd.py" <PRD路径> [原型HTML路径]
 ```
 分数 ≥80% 才能发布。低于 80% 把 EVA 报告的问题合并进上面的清单。
 
@@ -48,6 +48,6 @@ python "$R/.qoder/scripts/eval_prd.py" <PRD路径> [原型HTML路径]
 
 评审出结论（无论 PASS/打回）后埋点，供 /wl-status 统计评审活跃度：
 ```bash
-python "$R/.qoder/scripts/learn.py" record review_done "{\"prd\": \"<PRD文件名>\", \"verdict\": \"<PASS|打回>\", \"score\": <EVA分数或空>}"
+python "$R/.qoder/scripts/report/learn.py" record review_done "{\"prd\": \"<PRD文件名>\", \"verdict\": \"<PASS|打回>\", \"score\": <EVA分数或空>}"
 ```
 > 失败静默忽略。