@hupan56/wlkj 2.6.0 → 2.7.0

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

@@ -1,19 +1,41 @@
 ---
 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"
+trigger: "user describes a requirement, asks for PRD, mockup, or invokes /wl-prd-full or /wl-prd-quick"
 ---
 
+
+## 🔧 仓库根定位（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`。
+
 # PRD Generator Skill
 
-## 性能原则（最重要的规则）
+> 📌 **主入口：`/wl-prd-full`（正经需求）/ `/wl-prd-quick`（小改动）命令。** 本 skill 是它们的实现层 + Quest/QoderWork 自然语言路由。
+> 两者功能等价，优先用 `/wl-prd-full` 或 `/wl-prd-quick`（参数提示更全、更稳定）。
+> **模块契约**（输入/输出/校验）：`.qoder/contracts/prd.md`
+> **第一性原理：又快又准**（快=并行+砍模式，准=语义归档+质量锁）
+> **定位：专注"已确定需求"的落地。** 探索/调研/规划/对标已移交 `/wl-insight`，
+> 本 skill 不做 web 搜索、不派多 agent、不做 Gap 分析。基于 context_pack 现状做轻反思 + 跟用户确认。
+
+## 🔒 语言锁（最高优先级）
+
+**全部输出必须简体中文。** 含 PRD 标题、章节名、字段名、表格内容、原型文案、注释。
+禁止任何英文句子（技术专有名词如 API/REQ-ID 可保留英文缩写）。
+违反此锁 = 产出不合格，必须重写。
+
+## 性能原则（最重要的规则 —— 治"太慢/轮次太多"）
 
-1. **最少轮次**: Quick <=5 轮, Reference <=10 轮。不要 60 轮"深度思考"
-2. **一次取全**: 用 context_pack 一次拿全上下文，不要逐个 search（5-6 次变 1 次）
-3. **批量生成**: PRD + 原型一次 Write 写完，不分两轮
-4. **不重复读**: 模板已有正确颜色（vben-style / Vant），不要单独读 style JSON
-5. **并行调用**: 独立操作放一个消息里并行（如同时 Read 2 个文件）
-6. **Quick 跳过**: EVA / 历史 PRD / 网络搜索 / style JSON
+1. **轮次硬上限**：快档 ≤3 轮，完整档 ≤6 轮。超了就是流程跑偏
+2. **一次取全**：context_pack 一次拿全上下文，不要逐个 search（5-6 次变 1 次）
+3. **并行调用**：独立操作放**同一条消息**里并行（取上下文+读历史+读草稿一起发），不要串行
+4. **批量生成**：PRD + 原型一次 Write 写完，不分两轮
+5. **不重复读**：模板已有正确颜色（vben-style / Vant），不要单独读 style JSON
+6. **少打断**：context_pack 已取全 → AI 自己判断，**不要动不动停下来逐条确认**
 
 ## 自取上下文（Quest / QoderWork 无 hook，必须自读）
 
@@ -21,6 +43,17 @@ trigger: "user describes a requirement, asks for PRD, mockup, or invokes /wl-prd
 - `.qoder/.current-task` — 当前活动任务
 - `data/index/.index-meta.json` — 知识图谱新鲜度
 
+### 写 PRD 前：一次取全（context_pack 已含数据库表结构+历史PRD）
+
+**只调 1 次** `context_pack`（第 1-8 段一次全返回），不要逐个调 MCP：
+- 第 4 段 = 历史 PRD（防重复，替代 search_prd）
+- 第 8 段 = 数据库表结构+真实字段（替代 query_schema）
+- 第 5 段 = 相关 API（替代 feature_overview）
+
+**仅当 context_pack 没覆盖到时才额外调**（极少）：
+- 字段枚举值：`mcp__qoder-mysql__query_distinct(table='表名', column='状态列')` — context_pack 给了表结构但没给枚举取值，需要时才调
+- 改表影响：`mcp__qoder-knowledge-graph__table_impact(table='表名')` — 评估改动范围时才调
+
 ## STEP 0: 必须先问平台
 
 ```
@@ -32,71 +65,162 @@ trigger: "user describes a requirement, asks for PRD, mockup, or invokes /wl-prd
 ```
 等用户回答。绝不自动判断。
 
-| 回答 | 平台 | 项目 | 原型模板 |
-|------|------|------|---------|
-| 1 | Web | fywl-ui | prototype-web.html |
-| 2 | APP | Carmg-H5 | prototype-app.html |
-| 3 | Both | Both | 两个模板 |
+## STEP 1: 归档（两档制 —— PM 只需判断"小改动还是正经需求"）
 
-## 取上下文 — 一次取全（不要逐个搜）
+**prd 只管"已确定需求"的落地。探索类请走 /wl-insight。**
+
+### 归档三道保险
+
+**① 显式关键词**
+| 用户说 | 走哪档 |
+|--------|--------|
+| `快速`/`quick`/`加个字段`/`小改动` | 快档 |
+| （默认/无关键词） | 完整档 |
+| `深度`/`调研`/`对标`/`规划`/`路线图`/`探讨` | **不归 prd** → 提示走 `/wl-insight`（探索已外迁） |
+
+**② AI 语义自动归档（默认）**
+- "加/改/删一个具体小点" → **快档**
+- "新做一个模块/能力/流程" → **完整档**
+
+**③ 歧义必问（拿不准绝不猜）**
+```
+这个需求有两种走法：
+1. 【快档】当小改动，3 步极速出 Mini-PRD（约 2-3 轮）
+2. 【完整档】当正经需求，完整 PRD + 原型（约 4-6 轮）
+你要哪种？(1/2)
+```
+> 需求方向本身没定（"想做但不知道做什么"）→ 提示走 `/wl-insight discover` 先探索。
+
+## STEP 2: 三步流程
+
+### 快档（3 步极速，目标 2-3 轮）
+```
+① context_pack.py 一次取全（1 次调用）
+② 一次 Write：Mini-PRD(prd-quick-template.md) + 微型原型(只画 diff)
+③ "出好了，确认发布吗？" → 确认后归档+push
+跳过：EVA完整检查 / 历史 PRD / style JSON
+```
+
+### 完整档（3 步并行，目标 4-6 轮）
+
+**第 1 步｜并行取全（同一条消息并发，别串行）**
+```
+同一条消息里并行发：
+  ① context_pack.py <关键词> --platform <p>   ← 代码+页面+字段+API+样式一次拿全
+  ② Read 历史相关 PRD
+  ③ Read 业务草稿
+  （若衔接了 insight 报告：同时 Read 该报告，作为现状背景输入）
+```
+然后只读 context_pack 列出的最相关 1-2 个 Vue 文件。
+> ⚠️ 探索/调研/对标已归 /wl-insight，第 1 步**不派多 agent、不做 web 搜索**。
+
+**第 2 步｜轻反思 + 批量确认（核心：基于现状反思，重点是跟用户确认）**
+- AI 先用上下文**自动补全** PRD 的背景/目标/指标/用户画像
+- **基于现状做轻反思**：现状怎么做、本次改什么、预期效果——写进"需求背景/产品现状"章节
+- 只把"上下文真没有、必须 PM 拍板"的 1-2 点，**一次性**问完（编号列表）
+- **不再逐条确认** context_pack 已取全的现有行为/页面/字段 —— AI 自己判断
+- 确认用批量方式（一个编号列表一轮）
+
+**第 3 步｜一次生成 + 3 道质量锁 + 发布**
+```
+一次 Write 写完 PRD + 原型 → 跑 3 道质量锁 → 不过自动修 → 问"发布吗?"
+```
+
+## 🔒 3 道质量锁（治"产出质量不稳"，完整档全跑，快档只跑锁②）
 
+**"准"的保障。eval_prd.py 的 A1/A2/A3 已实现大半，这里提升为流程强制门。**
+
+生成后、发布前：
 ```bash
-python .qoder/scripts/context_pack.py <关键词> --platform <web|app>
+python "$R/.qoder/scripts/eval_prd.py" <draft-prd.md> <prototype.html>
 ```
-返回 7 章节（代码+页面+字段+PRD+API+样式+Wiki）。**只读最相关 1-2 个 Vue 文件**。
+eval_prd < 80% 不准发布，按报告修到 PASS。
 
-## 五种模式
-
-### Reference（默认 — 直接说需求）
-1. 问平台
-2. context_pack 一次取全
-3. 读 1-2 个 Vue 文件
-4. 一次性确认发现
-5. **一次 Write** PRD + 原型
-6. EVA 评估 + 确认发布
-
-### Quick（快速 — "快速""加个字段""小改动"）
-1. 问平台
-2. context_pack 一次取全
-3. **一次 Write** Mini-PRD + 微型原型
-4. 一句话确认 → push
-> 跳过：EVA / 历史 PRD / 搜索 / style JSON
-
-### Discuss（探讨 — "探讨""聊聊""分析"）
-1. 听需求
-2. 问关键问题（痛点/谁用/现状/目标）
-3. 给 2-3 个方向建议
-> 不出文件。聊完说"出PRD"转 Reference
-
-### Brainstorm（头脑风暴）
-1. 问平台
-2. SCAMPER + 多 agent 调研
-3. 生成 PRD + 原型
-
-### Planning（规划）
-1. 问平台
-2. 现状 + 理想态 + Gap + MVP
-3. 生成 PRD + 原型
+AI 在跑 eval_prd 前，自己先做内容自检（快档只查锁②）：
 
-## 原型规则
+| 锁 | 查什么 | 不过怎么办 |
+|----|--------|-----------|
+| **锁① 背景锁** | 背景回答了"为什么做 + 目标指标"？非空泛？ | 打回，补"业务驱动力 + 可量化目标" |
+| **锁② 字段锁** | PRD 字段都来自 context_pack 真实字段清单？无发明字段？ | 标红发明字段，对照真实代码替换/删除 |
+| **锁③ 闭环锁** | 每个功能点都有验收标准(Given-When-Then)？ | 缺验收的功能点补全 |
 
-- 从模板开始（`.qoder/templates/prototype-{web|app}.html`），模板已有正确颜色
-- **不要单独读 vben-style-reference.json** — 模板里 CSS 变量已配好
-- 只改 diff 部分，新功能高亮
-- 单 HTML 文件，可交互
-- Web: 桌面布局 + 侧边栏；APP: 375px + 底部 tab
+> 锁② 直接复用 eval_prd 的 A1 结果（A1 已校验字段真实性）。AI 把 A1 报告的"可疑字段"在发布前显式标给 PM 确认，不重复造校验。
+
+### 锁② 零命中时的降级（全新功能，索引无现成字段）
+
+context_pack 字段段返回"无直接相关字段"时，**字段锁不报错，降级为显式声明**：
+- 字段规格表每个字段标来源：`既有`（context_pack）/ `复用`（同类页同名字段）/ `新增`（本次定义）。
+- eval_prd A1 会跳过 `新增` 行不扣分 —— **新增字段必须打标记**，否则被当可疑字段。
+- `新增` 字段仍要写全：字段名(camelCase)/中文标题/类型/校验规则。
+
+### 🛡️ 故障降级（脚本崩了怎么走）
+
+**脚本崩 ≠ PRD 写不了。** 索引/工具是"准"的加速器，不是写 PRD 的前提。常见异常及降级：
+
+| 故障 | 降级动作 |
+|------|---------|
+| context_pack 零命中（全新业务） | 照常写，字段标 `新增`，诚实告诉 PM"索引无先例，字段需确认"。**绝不编字段** |
+| 索引文件缺失（A1=0 分） | 提示 `/wl-init --fix`；仍可出 PRD，锁②改人工标注 |
+| eval_prd 缺原型 | 只评 A1+A3，A2 跳过。快档允许只出 PRD |
+| eval_prd 本身崩 | 不阻塞，用 3 道锁自检代替，记"自动评分暂不可用" |
+| eval_prd <80% | 完整档修到 ≥80%；快档只看锁②，不阻塞 |
+| fill_prototype 崩 | 读模板手写起步，颜色只取 context_pack 第6段真源 |
+| REQ-ID 分配器失败 | 扫最大号+1，文件名带 `-manual`，push 时 team_sync 校验唯一 |
+| team_sync SYNC_CONFLICT | AI 按脚本给的命令自行解决，不让用户碰 git |
+
+> 完整降级表（含平台答错、归档失败等）见 `.qoder/commands/wl-prd-full.md` 的「故障降级表」。
+
+## 取上下文 — 一次取全（不要逐个搜）
+
+```bash
+python "$R/.qoder/scripts/context_pack.py" <关键词> --platform <web|app>
+```
+返回 7 章节（代码+页面+字段+PRD+API+样式+Wiki）。**只读最相关 1-2 个 Vue 文件**。
 
 ## PRD 模板
 
-| 模式 | 模板 | mode 标记 |
+| 档位 | 模板 | mode 标记 |
 |------|------|----------|
-| Reference/Brainstorm/Planning | `.qoder/templates/prd-full-template.md` | `<!-- mode: reference/brainstorm/planning -->` |
-| Quick | `.qoder/templates/prd-quick-template.md` | `<!-- mode: quick -->` |
+| 快档 | `.qoder/templates/prd-quick-template.md` | `<!-- mode: quick -->` |
+| 完整档(默认) | `.qoder/templates/prd-full-template.md` | `<!-- mode: reference -->` |
 
-> 模板头部已含 mode 标记。生成 PRD 时**只改 mode 值，别删标记**——
-> syncgate/eval_prd 靠它识别模式（Quick 跳过 EVA，其他全跑）。
+> planning/brainstorm 两个 mode 标记**已随探索能力迁至 /wl-insight**，prd 不再主动产出。
+> 模板头部已含 mode 标记。生成时**只改 mode 值，别删标记**——
+> syncgate/eval_prd 靠它识别模式（quick 跳过 EVA 完整检查，其余全跑）。
 
-## 质量自检（10 项，Quick 跳过）
+## 质量自检（10 项，快档跳过）
 1. 背景回答"为什么" 2. 目标可量化 3. 用户画像具体
 4. 业务规则完整 5. 异常覆盖(2+) 6. 验收可测(Given-When-Then)
 7. 数据事件完整 8. PRD 无技术实现 9. 优先级标注 10. 排期合理
+
+## 原型规则
+
+- 从模板开始（`.qoder/templates/prototype-{web|app}.html`），模板已有正确颜色与 mixed-nav 多级菜单骨架
+- 先跑 `python "$R/.qoder/scripts/fill_prototype.py" <关键词> --platform <web|app>` 拿 80% 草稿;
+  它会按目标项目的 `layout_fingerprint` 自动填示例菜单骨架和真实字段,你只微调 20%
+- 颜色/布局指纹见 fill_prototype 输出的"设计 Token"段(布局模式/主色/侧边栏宽度)
+- **菜单层级**: 若需求描述了侧边栏/菜单结构(如"一级→二级,右侧三四级"),
+  严格按它填 `{{TOP_MENU}}`/`{{SIDEBAR_MENU}}`/`{{TABS}}` —— 模板是 mixed-nav
+  多级骨架,不要退化成扁平单级 sidebar
+- 只改 diff 部分，新功能高亮
+- 单 HTML 文件，可交互
+- Web: mixed-nav(顶部一级+左侧二级三级+标签页);APP: 375px + 底部 tab
+
+## STEP：自动归档到个人时间线（可选增强 · 失败不影响 PRD）
+
+PRD 写入 drafts 后，**顺手归档一份**到当前成员的按时间文件夹，方便人翻查"我那天做了啥"：
+
+```bash
+python "$R/.qoder/scripts/archive_prd.py" <刚生成的PRD文件路径>
+```
+
+> 归档产物：`workspace/members/{你的名字}/archive/{YYYY-MM-DD}/REQ-{编号}-{中文标题}.md`
+> 同时更新 `archive/_index.md`（按周/月汇总）和当天 `_index.md`。
+
+**规则：**
+- 只**复制**不移动，drafts 原件保留，data/docs/prd/ 完全不碰 → 不影响搜索/撞号检测
+- 归属看当前操作者（.developer），不看"产品负责人"字段 → 开发/测试/产品都能用
+- 脚本内部全程 try/except，**失败只 print 一句，绝不阻塞 PRD 生成**
+- 多端 PRD（Web + APP 各一份）可一次传多个路径批量归档
+
+**非侵入**：用户没用 PRD 命令时本步骤完全不触发，QODER 原生流程零影响。

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

@@ -4,6 +4,15 @@ description: "评审 PRD 完整性与质量。Review PRD for completeness and qu
 trigger: "user invokes /review prd, asks to review/check PRD quality, or PM submits PRD"
 ---
 
+
+## 🔧 仓库根定位（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`。
+
 # PRD Review Skill
 
 ## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
@@ -31,6 +40,14 @@ trigger: "user invokes /review prd, asks to review/check PRD quality, or PM subm
 
 跑一次 EVA 门禁给出客观分数：
 ```bash
-python .qoder/scripts/eval_prd.py <PRD路径> [原型HTML路径]
+python "$R/.qoder/scripts/eval_prd.py" <PRD路径> [原型HTML路径]
 ```
 分数 ≥80% 才能发布。低于 80% 把 EVA 报告的问题合并进上面的清单。
+
+## 评审完成埋点
+
+评审出结论（无论 PASS/打回）后埋点，供 /wl-status 统计评审活跃度：
+```bash
+python "$R/.qoder/scripts/learn.py" record review_done "{\"prd\": \"<PRD文件名>\", \"verdict\": \"<PASS|打回>\", \"score\": <EVA分数或空>}"
+```
+> 失败静默忽略。

package/templates/qoder/skills/prompt-enrich/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: prompt-enrich
+description: "提问润色(第0步): 用户每条消息后先跑极速润色(<10ms), 定位业务上下文, 输出润色结果给用户确认, 再走原命令。触发: 每条含业务词的用户消息。"
+trigger: "用户每条消息(含业务关键词时)"
+always_apply: true
+---
+
+
+## 🔧 仓库根定位（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`。
+
+# prompt-enrich — 提问润色（每个命令的第 0 步）
+
+> **这是什么**：用户提问后,先极速判断这句话命中哪些业务上下文,输出一个「润色后的提示词」给用户确认,再走原命令。
+> **不是什么**：不是独立命令,是内置在每条消息处理前的第 0 步。
+
+## 🚦 执行规则（每条用户消息都适用）
+
+收到用户消息后,**在做任何其它事之前**,先判断:
+
+### 第 0 步：极速润色（必须最先做）
+
+```bash
+python "$R/.qoder/scripts/enrich_prompt.py" "<用户原话>" --json
+```
+
+- 脚本纯内存查表,实测 **< 50ms**(冷启动含索引加载;热态 < 10ms)
+- 不跑重检索(那个留到确认后)
+
+**看返回的 `is_business` 字段**：
+
+| is_business | 意思 | 你怎么做 |
+|-------------|------|----------|
+| `false` | 非业务消息(谢谢/继续/确认润色等) | **跳过润色**,直接处理用户请求 |
+| `true` | 业务消息 | **输出润色块**,等用户确认 |
+
+### is_business=true 时，输出润色块（严格按这个格式）
+
+```
+🔎 极速润色（Xms）— 直接用或回复「改:xxx」调整
+─────────────────────────────────────
+业务词: insurance, approval, abnormal...
+相关代码: 19 处 (abnormal, anomaly, approval, exception...)
+相关 API: /insurance
+─────────────────────────────────────
+将以此上下文继续。回复「好」接受，或「改: <你的调整>」。
+```
+
+**然后停下，等用户回复。** 不要继续往下做命令。
+
+### 用户确认后
+
+| 用户回复 | 你怎么做 |
+|---------|----------|
+| 「好」「继续」「接受」「确认」或任意无"改"字 | 接受润色,继续走原命令(prd/code/test...) |
+| 「改: 不要保险,只要批改」 | 按用户调整的上下文继续 |
+| 「不要润色」 | 跳过润色,用原话继续 |
+
+---
+
+## 关键约束
+
+1. **必须最先做**：润色是第 0 步,排在平台询问、搜索、读文件之前。
+   例外：`/wl-init`、`/wl-search` 这种纯工具命令可跳过润色(它们不产契约)。
+2. **极速**：只用 enrich_prompt.py,不用 context_pack(那是确认后的事)。
+3. **可改可拒**：润色结果是建议,用户有最终决定权。
+4. **不改变意图**：润色只补上下文,不改用户要做的事(还是 /wl-prd-full /wl-code 等)。
+
+## 与其它命令的关系
+
+润色是**横切关注点**,所有产契约的命令(prd/design/spec/code/test)都先过它:
+
+```
+用户: /wl-prd-full 保险批改那个异常统计页加个审批按钮
+  ↓
+第0步: enrich_prompt → 输出润色块 → 用户确认
+  ↓
+第1步起: /wl-prd-full 原流程（用确认后的上下文跑 context_pack）
+```
+
+## 为什么用脚本而不是靠 AI 自己想
+
+- **快**：纯内存查表纳秒级,AI 自己推理要秒级
+- **准**：复用 common/terms.py 的中文分词 + keyword-index,跟 /wl-search 同源
+- **一致**：每次润色逻辑一样,不依赖 AI 心情