@hupan56/wlkj 2.6.0 → 2.7.0

package/templates/qoder/skills/wl-insight/SKILL.md

@@ -1,81 +1,201 @@
----
-name: wl-insight
-description: "反馈分析 + 数据指标复盘。Feedback analysis + metrics review. 用户说'用户反馈''数据怎么样''转化漏斗''留存分析''痛点''北欧星指标''A/B 结果'时触发。"
-trigger: "用户说'用户反馈''数据怎么样''转化''留存''痛点''指标''洞察''/wl-insight'"
----
-
-# wl-insight — 反馈分析 + 指标复盘
-
-两类分析（用户没指定就问要做哪种）：
-
-## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
-
-- `.qoder/.developer` — 当前分析师
-- `.qoder/learning/feedback.jsonl` — 历史反馈记录（可能为空）
-- 用户需提供：反馈原文 / 指标数据（CSV、表格、口述均可）
-- 若用户既没给反馈也没给数据：先问"你是要分析用户反馈，还是看业务指标？数据在哪？"
-
-## 类型 1：feedback（反馈分析）
-
-输入：用户反馈原文（一条或多条）
-
-分析步骤：
-1. **分类**：feature_request / bug / UX / performance / praise / question
-2. **情感**：正面 / 中性 / 负面
-3. **痛点提取**：频率 × 严重度 排序，Top 10 带原文引用
-4. **建议**：每个高频痛点对应一个改进方向（可挂到 /wl-task）
-
-输出结构：
-```
-# 反馈分析报告 - <日期>
-
-## 概览
-- 总条数 / 正负比 / Top3 分类
-
-## 痛点 Top 10
-| 排名 | 痛点 | 频次 | 严重度 | 代表原文 | 建议动作 |
-|------|------|------|--------|---------|---------|
-
-## 可落地改进
-- 建议 A → 可建任务（说"建任务"触发 /wl-task）
-- 建议 B → ...
-```
-
-## 类型 2：metrics（指标复盘）
-
-输入：业务指标数据
-
-分析维度：
-- **北极星指标**：当前值 + 趋势 + 分解（拆到可执行子指标）
-- **留存**：D1 / D7 / D30，与行业基准对比
-- **漏斗**：每步转化率，找最大流失点
-- **A/B 实验**：显著性 + 效果量 + 结论
-- **OKR 对齐**：当前进度 vs 目标
-- **异常归因**：突增/突降的可能原因
-
-输出结构：
-```
-# 指标复盘 - <日期/周期>
-
-## 北极星
-值 / 趋势 / 距目标差距
-
-## 关键漏斗
-各步转化 + 瓶颈标注
-
-## 留存
-D1/D7/D30 + 同比
-
-## 结论与建议
-- 加速 X / 止血 Y / 实验 Z
-```
-
-## 类型 3：all（综合）
-
-交叉引用 feedback + metrics：反馈里的痛点是否反映在指标异动上。
-
-## 输出 + 保存
-
-保存到 `workspace/members/{dev}/drafts/wl-insight-{type}-{YYYY-MM-DD}.md`。
-
-> insight 报告默认不 push（属于个人分析草稿）。用户说"发出去/同步"才跑 team_sync push。
+---
+name: wl-insight
+description: "需求探索 + 外部调研 + 未来规划。流水线的'上游探索站'，负责发现需求、对标竞品、做 Gap 分析和 roadmap。把'该做什么、为什么做'想清楚，结论交给 /wl-prd-full 落地。用户说'调研一下''竞品分析''接下来做什么''路线图''探讨一下需求''我发现个机会''规划下个版本'时触发。"
+trigger: "用户说'调研''竞品''对标''规划''路线图''roadmap''探讨需求''接下来做什么''发现个机会''下个版本做什么''/wl-insight'"
+---
+
+
+## 🔧 仓库根定位（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`。
+
+# wl-insight — 需求探索（7 站之前的「探索站」· 产品工位）
+
+> 这是 `/wl-insight` 命令的 skill 入口（让 QoderWork 的 `/` 列表也能用）。
+> 完整执行规则见命令 `.qoder/commands/optional/wl-insight.md`。
+> **模块契约**（输入/输出/校验）：`.qoder/contracts/insight.md`
+> **第一性原理：看未来，不编造。** 探索有方法论（OST/JTBD/Gap），结论必须锚定现状（context_pack）。
+> **与 prd 的分工**：insight 想清楚"该做什么、为什么做"；prd 落地"具体怎么做"。
+
+## 🔒 语言锁（最高优先级）
+
+**全部输出必须简体中文。** 含报告标题、章节名、字段名、结论、建议。
+禁止任何英文句子（技术专有名词如 MCP/API/JTBD 可保留英文缩写）。
+违反此锁 = 产出不合格，必须重写。
+
+---
+
+## 🎯 定位：流水线的最上游
+
+```
+insight（探索/调研/规划）→ [用户确认转PRD] → prd（落地）→ task → code → test → commit
+  ↑ 看未来，出洞察报告           ↑ 专注"已确定需求"，含轻反思+确认
+```
+
+**insight 不产 PRD，不画原型，不分配 REQ-ID。** insight 的产出是**洞察报告**（.md）。
+报告写完，提示用户"要把某个机会转成 PRD 吗？" → 是 → 自动进 `/wl-prd-full` 参考模式（mode: reference）。
+
+---
+
+## 🚦 动作路由（看用户说啥 → 走哪个类型）
+
+| 用户说什么 | 类型 | 做什么 |
+|-----------|------|--------|
+| "我发现个机会""现状有个痛点""能不能做 XX" / `discover` | **discover** | 需求发现：从现状痛点/竞品空白找机会（OST 的 outcome+opportunity 层） |
+| "调研一下竞品""对标 XX""行业都怎么做" / `research` | **research** | 外部调研：竞品对标+行业趋势+技术方案（web 搜索 + 多 agent 多视角） |
+| "接下来做什么""下个版本规划""路线图""MVP 范围" / `plan` | **plan** | 未来规划：Gap 分析+MVP 范围+roadmap（OST 的 solution 层） |
+| 模糊 / 拿不准 | 先问意图 | "你是想发现新需求、调研外部、还是规划未来？" |
+
+---
+
+## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
+
+- `.qoder/.developer` — 当前探索者（报告归属）
+- **现状锚点**：`python "$R/.qoder/scripts/context_pack.py" <关键词> --platform <web|app>`（必跑，探索不能脱离现状凭空想）
+- `.qoder/learning/feedback.jsonl` — 历史 insight 报告索引（可能为空）
+- 相关历史 PRD：`data/docs/prd/`（看已经做了什么，避免重复）
+
+---
+
+## 🔒 三道前置检查（任何动作前先做）
+
+1. **身份检查**：`.developer` 缺失 → 停下，提示先 `/wl-init`，不继续。
+2. **现状锚点**：任何探索前先跑 `context_pack.py`。**不锚定现状的探索 = 凭空臆想，禁止。**
+3. **报告归属**：报告必须写到 `workspace/members/{dev}/drafts/`，用 `.developer` 归属。
+
+---
+
+## 核心方法论（融合业界高分框架，不照搬）
+
+insight 把三个业界成熟框架**融合成本项目能用的探索流**，每个类型对应 OST（Opportunity Solution Tree）的一层：
+
+```
+        ┌─ Outcome（业务目标）──── discover 探索 ────┐
+        │                                            │
+OST     ├─ Opportunity（用户机会/痛点）─ discover ──┤  → insight 产出前三层
+        │                                            │
+        ├─ Solution（方案候选）──────── plan 规划 ──┘
+        │
+        └─ Experiment（验证）──────── 交给 prd 落地后，由 /wl-test 验证
+```
+
+### ① Opportunity Solution Tree（Teresa Torres）— 主骨架
+- 4 层：**Outcome → Opportunity → Solution → Experiment**
+- insight 负责**前三层**：把"业务目标"拆成"用户机会"，再推演"方案候选"
+- 第 4 层 Experiment 交给 prd 落地后由 test 验证
+- **为什么用它**：防止"想到一个点子就开做"，强制先想清"这个机会服务于哪个业务目标"
+
+### ② Jobs-to-be-Done（JTBD）— discover 的发现视角
+- 问"用户雇佣这个产品/功能来完成什么 job"，而不是"加什么功能"
+- 用于 discover：把"我想加个导出按钮"还原成"用户要完成'月底交报表'这个 job"
+- **为什么用它**：避免掉进"功能列表"思维，回归需求本质
+
+### ③ Gap 分析（现状→理想态）— plan 的规划工具
+- 现状（context_pack 取真实代码/页面）vs 理想态（竞品/行业标准）→ 差距 → MVP + roadmap
+- 用于 plan：把"未来想做成什么样"拆成"本期做什么 / 下期做什么"
+- **为什么用它**：让规划有据可依，不是拍脑袋排期
+
+> 三者不冲突，按类型组合用。详细执行规则见 `.qoder/commands/optional/wl-insight.md`。
+
+---
+
+## 三类型怎么做（概要，详见命令定义）
+
+**discover（需求发现）—— 用 JTBD + OST 前两层：**
+1. 跑 context_pack 锚定现状
+2. 用 JTBD 还原"用户要完成什么 job"，列出痛点/机会
+3. 每个机会对应一个业务 outcome（OST 第 1-2 层）
+4. 输出机会清单，问用户"哪个值得深入？"
+
+**research（外部调研）—— 多 agent 多视角 + web 搜索：**
+1. 派 2-4 个多 agent，每个一个视角（竞品/行业趋势/技术方案/用户场景）
+2. 每 agent 做 web 搜索，写 `research-agent-{N}-{视角}.md` 中间产物
+3. 合并成调研报告，列对标发现 + Gap + 机会信号
+4. 中间产物最后必须清理（见命令定义的清理规则）
+
+**plan（未来规划）—— Gap 分析 + OST 第 3 层：**
+1. 现状（context_pack）vs 理想态（research 结论或用户描述）→ Gap 表
+2. Gap 排优先级（业务价值 × 可行性）
+3. 拆 MVP（本期）+ roadmap（后续版本，标依赖）
+4. 输出方案候选（OST Solution 层）
+
+---
+
+## 🔒 与用户确认（贯穿所有类型，最重要）
+
+**探索的结论必须跟用户确认，不是 AI 单方面输出。** 每个类型结束都要：
+1. 把发现/结论**一次性编号列清**（不逐条问）
+2. 问用户："这个分析对吗？哪个要调整？"
+3. 用户确认后才写报告；用户有异议 → 调整后重确认（最多 2 轮，不无限循环）
+4. 报告写完，**主动提示出口衔接**（见下）
+
+---
+
+## 出口衔接：报告 → PRD（关键）
+
+insight 报告末尾**永远**给一句：
+
+```
+要把握住哪个机会？说"转 PRD"我把它作为现状输入，进 /wl-prd-full 参考模式落地成可执行 PRD。
+```
+
+用户说"转 PRD"或指定某个机会 → 触发：
+```
+/wl-prd-full 参考：{报告路径}#{机会编号}
+```
+prd 以 reference 模式（mode: reference）承接，读取 insight 报告作为现状背景，走"轻反思+批量确认"流程落地。
+
+> **insight 不直接生成 PRD**。探索和落地是两道工序，分开做才不会混在一起。
+
+---
+
+## 🧩 QoderWork 增强：外部数据源（可选 · 无连接器则自动回退）
+
+> 依赖 **QoderWork 桌面端连接器**（Settings → Connectors & MCP）。
+> **纯 Qoder IDE / CLI 没有连接器 → 本段不生效，insight 用 context_pack + web 搜索足够。**
+> 探测方式：仅当运行环境提供了「Browser / MCP 工具」可调用时才用。
+
+若连接器可用，insight 的 research 类型可增强（非必须，纯锦上添花）：
+- **Browser 连接器**：抓竞品页面截图/交互，作为对标证据（比 web 搜索摘要更实）
+- **MCP server**（如飞书/Notion）：从 IM 收集的用户原声/需求池拉数据，作为 discover 的机会来源
+- **IM Channel（飞书）**：把 insight 报告发到飞书群，让团队补充意见
+
+> 回退保证：无连接器**绝不影响 insight 主流程**，只补一句 `[外部数据源未启用：非 QoderWork 或未授权连接器]` 提示。
+> context_pack + web 搜索永远是兜底，纯 Qoder 完全可用。
+
+---
+
+## Storage（存储规则）
+
+```
+报告目录 → workspace/members/{developer}/drafts/
+  ├── insight-{type}-{YYYY-MM-DD}.md          ← 洞察报告（主产物）
+  └── research-agent-{N}-{视角}.md            ← research 类型的多 agent 中间产物（合并后删）
+```
+- **报告不进 data/docs/prd/**（避免撞 REQ-ID、避免 eval_prd 误扫）
+- 同天同类型重跑覆盖当天（要最新结果），不同天各自独立
+- research 中间产物 `research-agent-*.md` 合并后**必须删**（team_sync 的 staging allowlist 也拒绝这类文件名）
+
+---
+
+## 完成后同步
+
+insight 报告**默认不 push**（个人探索草稿）。用户说"发出去/同步/分享给团队"才：
+```bash
+python "$R/.qoder/scripts/team_sync.py" push
+```
+
+---
+
+## 输出规则
+
+- 报告用结构化 markdown（标题/表格/清单），便于后续 prd 读取
+- 每个发现/机会/Gap 都要附**证据来源**（context_pack 命中的文件 / web 搜索的链接 / 用户口述）
+- **禁止编造数据**：没有证据的结论标"【待验证】"，不假装有据
+- 任何脚本非 0 退出 → 原样转述错误，不吞
+
+详细执行规则见 `.qoder/commands/optional/wl-insight.md`。

package/templates/qoder/skills/wl-prd-full/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: wl-prd-full
+description: "完整档 PRD + 原型（13 章，正经需求）。新模块/新业务/新流程用这个。支持 参考:<insight报告> 衔接探索站。用户说'写个需求''生成PRD''做个原型''保单这块加个功能''写个产品需求文档'或输入 /wl-prd-full 时触发。先问平台！"
+trigger: "用户描述正经需求、要 PRD、要原型、要 mockup，或直接 /wl-prd-full"
+---
+
+
+## 🔧 仓库根定位（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`。
+
+# wl-prd-full — 完整档 PRD + 原型（/wl-prd-full 命令入口）
+
+> 这是 `/wl-prd-full` 命令的 skill 入口。QoderWork 的 `/` 列表读 skills，
+> 所以本 skill 让 QoderWork 也能用 `/wl-prd-full`，与 Qoder IDE 保持一致。
+> 完整工作流见同名 command 文件 `.qoder/commands/wl-prd-full`，
+> 功能实现层见 `.qoder/skills/prd-generator/SKILL.md`。
+> **第一性原理：又快又准。**
+
+## ⚠️ STEP 0: 必须先问平台（任何分析前）
+
+```
+这个需求是针对哪个平台？
+1. Web 管理端 (fywl-ui) - Ant Design Vue + VxeGrid 风格
+2. APP 移动端 (Carmg-H5) - Vant 风格
+3. 两端都要
+请选择 (1/2/3):
+```
+**绝不自动判断。绝不假设。绝不跳过。永远先问。等用户回答。**
+
+| 回答 | 平台 | 搜索 flag | 原型模板 |
+|------|------|-----------|----------|
+| 1 / Web / PC / 管理端 | Web | `--platform web` | prototype-web.html |
+| 2 / APP / H5 / 移动端 | APP | `--platform app` | prototype-app.html |
+| 3 / 都要 / 两端 | Both | 都跑 | 两个模板，两份原型 |
+
+## 衔接 insight（参考模式）
+
+**若用户说"按 insight 报告做 PRD""转 PRD"或带 `参考：<报告路径>`：**
+Read 指定 insight 报告 → 把现状锚定 + 选中的机会/Gap 作为 PRD 现状背景输入 → 走完整档流程。
+> 衔接语义：`/wl-prd-full 参考：{报告路径}#{机会编号}`
+
+## 完整流程（详细见 command 文件）
+
+1. **并行取全上下文**：先读当前角色（`python "$R/.qoder/scripts/role.py"` 输出 pm/design/dev/test/admin 之一），按角色传 `--role`，让上下文匹配角色视角：
+   ```bash
+   ROLE=$(python "$R/.qoder/scripts/role.py" 2>/dev/null || echo pm)
+   python "$R/.qoder/scripts/kg.py" context <词> --platform <p> --role "$ROLE"
+   ```
+   > 不硬编码 pm：dev 写 PRD 能拿到代码视角、设计师拿到页面+风格视角，比统一 PM 视角更"准"。
+2. **轻反思 + 批量确认**：AI 自动补全背景/目标/指标，只把真缺失的 1-2 点一次性问完
+3. **一次生成 + 3 道质量锁**：PRD（prd-full-template.md，13 章）+ 原型一次 Write → 背景锁/字段锁/闭环锁 → eval_prd → 不过自动修
+4. **发布 + 归档 + 同步**（3 合 1）：collect_prds → team_sync push → archive_prd
+
+## 🔒 3 道质量锁
+
+- **锁① 背景锁**：背景回答了"为什么做+目标指标"
+- **锁② 字段锁**：字段来自真实代码（复用 eval_prd A1），无发明
+- **锁③ 闭环锁**：每个功能点有验收标准(Given-When-Then)
+
+## REQ-ID 分配（并发安全）
+
+```bash
+python -c "import sys; sys.path.insert(0,'.qoder/scripts'); from common.reqid import allocate_req_id; n=allocate_req_id(); print('REQ-%d-%03d' % (__import__('datetime').date.today().year, n))"
+```

package/templates/qoder/skills/wl-prd-quick/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: wl-prd-quick
+description: "小改动极速出 Mini-PRD（6 章）。加字段/加按钮/改文案/加导出等零星需求专用。用户说'加个字段''加个导出按钮''改下文案''快速出个需求'时触发。先问平台！"
+trigger: "用户说小改动/加字段/加按钮/改文案/快速出 PRD，或直接 /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`。
+
+# wl-prd-quick — 小改动极速出 Mini-PRD（/wl-prd-quick 命令入口）
+
+> 这是 `/wl-prd-quick` 命令的 skill 入口。QoderWork 的 `/` 列表读 skills，
+> 所以本 skill 让 QoderWork 也能用 `/wl-prd-quick`，与 Qoder IDE 保持一致。
+> 完整工作流见同名 command 文件 `.qoder/commands/wl-prd-quick.md`，
+> 功能实现层见 `.qoder/skills/prd-generator/SKILL.md`（快档分支）。
+
+## ⚠️ STEP 0: 必须先问平台（任何分析前）
+
+```
+这个需求是针对哪个平台？
+1. Web 管理端 (fywl-ui) - Ant Design Vue + VxeGrid 风格
+2. APP 移动端 (Carmg-H5) - Vant 风格
+3. 两端都要
+请选择 (1/2/3):
+```
+**绝不自动判断。问完就停。**
+
+## 适用范围（只管小改动）
+
+✅ 加/删/改字段、按钮、文案、导出、校验规则
+❌ 新模块/新业务/新流程/多页面联动 → 走 `/wl-prd-full`
+
+## 3 步极速流程（详细见 command 文件）
+
+1. 先读当前角色再取上下文（不硬编码 pm，让 dev/设计师拿到匹配视角）：
+   ```bash
+   ROLE=$(python "$R/.qoder/scripts/role.py" 2>/dev/null || echo pm)
+   python "$R/.qoder/scripts/kg.py" context <词> --platform <p> --role "$ROLE"
+   ```
+2. 一次 Write：Mini-PRD（prd-quick-template.md，6 章）+ 微型原型（只画 diff）
+3. "出好了，确认发布吗？" → 归档 + push
+
+> mode 标记 `<!-- mode: quick -->`，跳过 EVA 完整检查。只跑字段锁。

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

@@ -0,0 +1,34 @@
+---
+name: wl-prd-review
+description: "评审 PRD 完整性与质量（7 项 checklist + EVA 评分）。用户说'评审PRD''检查需求文档''PRD质量怎么样''这个 PRD 合格吗''帮我看看这个需求文档'时触发。"
+trigger: "用户说要评审/检查/审核 PRD 质量，或直接 /wl-prd-review"
+---
+
+
+## 🔧 仓库根定位（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`。
+
+# wl-prd-review — 评审 PRD 质量（/wl-prd-review 命令入口）
+
+> 这是 `/wl-prd-review` 命令的 skill 入口。
+> 完整工作流见同名 command 文件 `.qoder/commands/wl-prd-review.md`，
+> 评审实现细节见 `.qoder/skills/prd-review/SKILL.md`。
+> **定位：评审已有 PRD，不产出新 PRD。**
+
+## 评审做什么
+
+拿到一份 PRD，检查它够不够格发布/交付下游：
+1. **7 项 checklist**：用户故事清晰 / 验收可测 / 优先级已标 / 模块已识别 / 非功能已列 / 边界已考虑 / 依赖已识别
+2. **EVA 客观评分**：`python "$R/.qoder/scripts/eval_prd.py" <PRD> [原型]`，≥80% 才 PASS
+3. **合并报告**：PASS → 可发布；不 PASS → 修复清单
+
+## 定位要评审的 PRD
+
+用户给路径 → 直接 Read；没给 → 扫 `data/docs/prd/` + `workspace/members/*/drafts/` 列出最近 PRD 让用户选。
+
+详细流程见 `.qoder/commands/wl-prd-review.md`。