@hupan56/wlkj 2.6.0 → 2.7.0

package/templates/qoder/commands/wl-prd-review.md

@@ -0,0 +1,104 @@
+---
+name: wl-prd-review
+description: "评审 PRD 完整性与质量（7 项 checklist + EVA 评分）。"
+argument-hint: "[可选: PRD文件路径]  不给则列出最近 PRD 让用户选"
+auto-approve: true
+allowed-tools: [Read, Bash]
+---
+
+# /wl-prd-review - 评审 PRD 完整性与质量
+
+User input: $ARGUMENTS
+
+> **定位：评审已有 PRD，不产出新 PRD。** 拿到一份 PRD，检查它够不够格发布/交付下游。
+> 产出的 PRD 要评审，跑这个；要从头写 PRD，走 `/wl-prd-full` 或 `/wl-prd-quick`。
+
+---
+
+## 🔧 环境自检（QoderWork 桌面端 vs Qoder IDE/CLI）
+
+**QoderWork 桌面端的工作目录是临时会话目录，不是仓库根！** 相对路径会失效。
+```bash
+# 确定仓库根 R:
+R=$(python ~/.qoderwork/repo_root.py)   # QoderWork 桌面端
+R=.                                      # IDE/CLI（工作目录就是仓库）
+```
+
+---
+
+## STEP 0: 定位要评审的 PRD
+
+**若 $ARGUMENTS 给了文件路径** → 直接 Read 该 PRD。
+
+**若没给路径** → 扫仓库的这两个目录，列出最近的 PRD 让用户选：
+```bash
+# 已归档的可发布 PRD
+dir /b "$R\data\docs\prd\REQ-*.md"
+# 还在草稿区的
+dir /b "$R\workspace\members\*\drafts\REQ-*.md"
+```
+列出最近 5-10 份（带 REQ-ID 和标题），让用户选要评审哪份。
+
+---
+
+## STEP 1: 7 项人工评审 Checklist
+
+读完 PRD 后，逐项检查：
+
+- [ ] **用户故事清晰**：每类用户要做什么，说清楚了
+- [ ] **验收标准可测**：每个功能点有 Given-When-Then，能照着测
+- [ ] **优先级已标**：功能点标了 P0/P1/P2/P3
+- [ ] **模块/领域已识别**：属于哪个业务模块明确
+- [ ] **非功能性需求已列**：性能/兼容/安全等（适用的话）
+- [ ] **边界情况已考虑**：每个功能 ≥2 个异常场景（空数据/超长/并发/权限等）
+- [ ] **依赖已识别**：依赖的其他模块/API/上下游说清了
+
+---
+
+## STEP 2: 跑 EVA 客观评分
+
+给 PRD 打客观分数（这是评审的硬依据，在仓库根下执行）：
+```bash
+cd "$R" && python .qoder/scripts/eval_prd.py <PRD路径> [原型HTML路径]
+```
+
+| 维度 | 权重 | 检查内容 |
+|------|------|----------|
+| A1 现实锚定 | 40 分 | 字段/API 在索引命中比例（有没有发明字段） |
+| A2 风格保真 | 30 分 | 原型颜色来自真源（无原型则跳过） |
+| A3 模板完整 | 30 分 | 章节齐全比例 |
+
+**≥ 80% 才 PASS**。低于 80% 把 EVA 报告的问题合并进 STEP 3 的修复清单。
+
+> 注意 mode 标记：quick PRD（`<!-- mode: quick -->`）会跳过 EVA 完整检查；reference/full PRD 跑全套。评审时尊重 mode 差异——quick PRD 不该用 13 章标准苛求。
+
+---
+
+## STEP 3: 合并报告
+
+把 STEP 1 的 checklist 结果 + STEP 2 的 EVA 分数合并成评审报告：
+
+**若 PASS**（checklist 全过 + EVA ≥80%）：
+```
+✅ PRD 评审通过
+- EVA 分数: XX/100
+- 7 项检查: 全部通过
+建议：可发布（跑 /wl-prd-full 或 /wl-prd-quick 的发布流程），或直接建任务。
+```
+
+**若不 PASS**：
+```
+❌ PRD 需修复，问题清单：
+1. [必须] 验收标准缺 Given-When-Then（功能 X）
+2. [必须] A1 命中率仅 45%，疑似发明字段：abcField, xyzStatus
+3. [建议] 边界情况只考虑了空数据，缺超长/并发场景
+...
+修复后重新评审：/wl-prd-review <PRD路径>
+```
+
+---
+
+## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
+
+- `.qoder/.developer` — 当前评审人
+- `data/index/.index-meta.json` — 图谱新鲜度（影响 A1 现实锚定能否校验；过期则 A1 可能漏报）

package/templates/qoder/commands/wl-prd.md

@@ -1,321 +1,27 @@
 ---
 name: wl-prd
-description: "Generate PRD with prototype matching project style"
-argument-hint: "[mode] [description]  modes: reference/brainstorm/plan/quick"
+description: "[已废弃] 旧的单命令已拆分。请用 /wl-prd-full /wl-prd-quick /wl-prd-review"
 auto-approve: true
-allowed-tools: [Read, Glob, Grep, Bash, Write, Edit, Agent]
 ---
 
-# /wl-prd - Generate PRD + Prototype
+# /wl-prd - 已废弃（拆分为 3 个独立命令）
 
-User input: $ARGUMENTS
+> ⚠️ **本命令已废弃。** `/wl-prd` 的单命令 + 参数路由（`快速`/`深度`/`探讨`）已拆成 3 个独立命令，
+> **只准 `/wl-prd-xx` 形式触发**。请改用：
 
-## ⚠️ STEP 0: MANDATORY PLATFORM SELECTION (MUST DO FIRST!)
+| 你要做什么 | 用哪个命令 |
+|-----------|-----------|
+| 写正经需求（新模块/新业务/新流程），完整 13 章 PRD + 原型 | **`/wl-prd-full`** |
+| 小改动（加字段/加按钮/改文案），极速 Mini-PRD | **`/wl-prd-quick`** |
+| 评审已有 PRD 的质量 | **`/wl-prd-review`** |
 
-**Before ANY search, ANY file read, ANY analysis — ask this question.**
-**NEVER auto-detect. NEVER assume. NEVER skip. ALWAYS ASK.**
+## 旧用法对照
 
-```
-这个需求是针对哪个平台？
+| 旧用法（已废弃） | 新用法 |
+|----------------|--------|
+| `/wl-prd 快速：<需求>` | `/wl-prd-quick <需求>` |
+| `/wl-prd <需求>`（默认） | `/wl-prd-full <需求>` |
+| `/wl-prd 参考：<报告>`（衔接 insight） | `/wl-prd-full 参考：<报告>` |
+| `/wl-prd 深度` / `/wl-prd 探讨` | `/wl-prd-full`（探索类已归 `/wl-insight`） |
 
-1. **Web 管理端** (fywl-ui) - Ant Design Vue + VxeGrid 风格
-2. **APP 移动端** (Carmg-H5) - Vant 风格
-3. **两端都要**
-
-请选择 (1/2/3):
-```
-
-WAIT for the answer. Platform determines everything downstream:
-
-| Answer | Platform | Project | Search Flag | Prototype Template |
-|--------|----------|---------|-------------|--------------------|
-| 1 / Web / PC / 管理端 | Web | fywl-ui | `--platform web` | .qoder/templates/prototype-web.html |
-| 2 / APP / H5 / 移动端 | APP | Carmg-H5 | `--platform app` | .qoder/templates/prototype-app.html |
-| 3 / 都要 / 两端 | Both | Both | run both | both templates, 2 prototypes |
-
-## Mode Detection
-
-| 怎么说 | 做什么 | 出 PRD？ |
-|--------|--------|---------|
-| `/wl-prd 写个XX需求` | **直接生成** PRD + 原型 | ✅ |
-| `/wl-prd 深度 XX需求` 或 "深入分析""全面调研""规划" | **先分析后生成**：现状+Gap+多角度(SCAMPER)→PRD+原型 | ✅ |
-| `/wl-prd 快速 加个字段` 或 "快速""小改动" | **Mini-PRD**：精简格式，跳过 EVA | ✅ |
-| `/wl-prd 探讨 XX怎么做` 或 "聊聊""分析一下" | **纯讨论**：理需求、给方向，不出文件 | ❌ |
-
-### 命令很简单
-
-```
-/wl-prd <你的需求>              ← 默认，直接出 PRD
-/wl-prd 深度 <你的需求>          ← 先分析(现状/Gap/创新角度)再出 PRD
-/wl-prd 快速 <你的需求>          ← 小改动，Mini-PRD
-/wl-prd 探讨 <你的需求>          ← 纯聊天，不出文件
-```
-
-> **"深度"模式** = 原 Brainstorm + Planning 合并：
-> - 先跑现状分析 + Gap 分析 + SCAMPER 多角度
-> - 再生成 PRD + 原型
-> - 适合：大需求/新领域/想创新/季度规划
-
-### 模式路由规则
-
-1. **显式参数优先**：`/wl-prd 深度 XX` `/wl-prd 快速 XX` `/wl-prd 探讨 XX`
-2. **关键词推断**：
-   - "深入""全面""规划""调研""创新""头脑风暴" → 深度
-   - "快速""加个""小改动" → 快速
-   - "探讨""聊聊""分析一下" → 探讨
-3. **默认**：不带关键词 → 直接生成
-
-### 什么时候用哪个模式？
-
-- **不知道怎么做** → 探讨（先聊清楚再决定要不要出PRD）
-- **照着已有的做类似的** → 参考（默认）
-- **想创新/没思路** → 头脑风暴
-- **大方向/季度规划** → 规划
-- **小功能/Bug fix** → 快速
-
-### Discuss 转 Reference 的标记（审计用）
-
-Discuss 结束、用户说"出PRD"时，AI 必须输出：
-```
-[MODE-SWITCH: discuss→reference]
-```
-然后按 Reference 模式流程生成。
-
-### 全模式标记规则（生成 PRD 时必须遵守）
-
-**每种模式生成的 PRD，第一行必须是 `<!-- mode: <模式名> -->` 标记**：
-```markdown
-<!-- mode: reference -->   (或 brainstorm / planning / quick)
-# 标题...
-```
-
-各模式标记值与 EVA 门禁行为：
-
-| 模式 | mode 标记 | EVA 处理 | 说明 |
-|------|----------|---------|------|
-| Reference | `<!-- mode: reference -->` | 全跑 (A1+A3) | 默认完整 PRD |
-| Brainstorm | `<!-- mode: brainstorm -->` | 全跑 | 创新方案 PRD |
-| Planning | `<!-- mode: planning -->` | 全跑 | 规划路线图 PRD |
-| Quick | `<!-- mode: quick -->` | **跳过 EVA** | Mini-PRD 精简, A3 字段检查不适用 |
-| Discuss | （不出文件, 无标记） | — | 纯讨论 |
-
-> 标记从模板继承（模板已有正确默认值）。生成时**只改 mode 值，别删标记**。
-> syncgate 和 eval_prd 都靠这个标记识别模式；缺失标记会按 full 模板检查（对 Quick 会误杀）。
-> 向后兼容：旧 PRD 无标记时，eval_prd 回退到内容识别（看 Mini-PRD/零星需求字样）。
-
-### Brainstorm 中间文件清理
-
-Brainstorm 模式可能生成 `brainstorm-agent-*.md` 中间调研文件。
-生成最终 PRD 后**必须删除这些中间文件**：
-```bash
-rm -f workspace/members/*/drafts/brainstorm-agent-*.md
-```
-team_sync 的 staging allowlist 也会拒绝 `brainstorm-agent-*` 文件名。
-
-The agent files define the detailed workflow for each mode. When
-dispatching a sub-agent, ALWAYS include in the dispatch prompt:
-the chosen platform, the user requirement, and the current developer name.
-For simple requirements you may run the mode workflow inline instead of
-dispatching — the steps are the same.
-
-### 模式不确定时的兜底（必须遵守）
-
-**推断流程（每次必走）**：
-1. AI 根据用户关键词推断出一个候选模式
-2. **置信度自检**：问自己"这个需求是否可能属于另一个模式？"
-   - 若可能（≥2 模式沾边，如既像"分析"又像"规划"）→ **必须问用户**
-   - 若无明显歧义 → 直接用候选模式
-3. 默认走 Reference 仅当用户明确给出需求描述且无探讨/创新/规划信号时
-
-**歧义确认话术（统一问法，降低不一致）**：
-```
-这个需求我理解为 [X 模式]（会：[X 的产出]）。
-也可以走 [Y 模式]（会：[Y 的产出]）。
-你要哪种？
-```
-
-**铁律**：宁可多问一句，不要错模式。错模式的 PRD 是废纸——EVA 门禁只管格式不管方向，格式过了的废 PRD 照样能发布。
-
-## Storage
-
-Draft -> workspace/members/{developer}/drafts/REQ-{ID}-{desc}.md
-Confirmed -> workspace/specs/prd/REQ-{ID}-{desc}.md
-Prototype (single platform) -> workspace/members/{developer}/drafts/prototype-{feature}.html
-Prototype (Both) -> prototype-{feature}-web.html AND prototype-{feature}-app.html
-
-REQ-ID rule: **必须**调用原子分配器获取新 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))"
-```
-分配器在文件锁内读 data/index/req-counter.json + 递增 + 写回, 保证并发安全。
-首次使用若计数器不存在, 会自动 migrate_from_existing() 扫现有 PRD 初始化。
-Never reuse an existing number. push 时 team_sync 会校验 REQ-ID 唯一性。
-
----
-
-## Discuss Mode (探讨模式 — 纯讨论，不出 PRD/原型)
-
-> 触发：用户说"探讨""聊聊""分析一下""我想做个XX但不知道怎么做"
-> 或需求很模糊，需要先理清思路时。
-
-### 做什么
-1. **听需求**：让用户把想法说完，不要急着出方案
-2. **问关键问题**（一次问完，不要一条一条问）：
-   - 要解决什么问题？（业务痛点）
-   - 谁用？（角色/场景）
-   - 现在怎么做的？（现状）
-   - 期望怎样？（目标）
-3. **给方向建议**：基于现有代码（跑 context_pack 了解现状）给出 2-3 个可行方向
-4. **不生成 PRD、不生成原型、不分配 REQ-ID**
-5. 讨论结束后问："要按这个方向出 PRD 吗？" → 用户说是 → 转 Reference 模式
-
-### 不做什么
-- ❌ 不写 PRD 文件
-- ❌ 不画原型
-- ❌ 不分配 REQ-ID
-- ❌ 不跑 EVA 评估
-- ❌ 不 push
-
----
-
-## Reference Mode (DEFAULT)
-
-### Step 1: Get ALL Context in ONE Call (fast path)
-```bash
-python .qoder/scripts/context_pack.py <业务关键词> --platform <web|app> [--type table|form|dashboard]
-```
-One command returns: related code files + same-type page examples +
-real field specs + related PRDs + APIs + style/icon/template pointers.
-Then read the top 2-3 most similar Vue files it lists.
-(Fallback: individual search_index.py calls if you need to drill deeper.)
-
-### Step 2: Read History PRD
-Read related PRDs found by `--prd` from data/docs/prd/.
-
-### Step 3: Read Business Drafts
-Read data/docs/drafts/ for business context.
-
-### Step 4: Style Tokens
-- Web: read data/index/vben-style-reference.json (pre-distilled design tokens)
-- APP: Vant variables (see Prototype Rules below)
-- Only open data/style/ PDFs if a needed token is missing from the JSON.
-- If PDF conflicts with real code, CODE WINS.
-
-### Step 5: Confirm Findings (BATCHED)
-Present ALL findings in ONE numbered list (existing behavior, related pages,
-fields, business rules, assumptions). Ask the user to confirm or correct
-in a single round. Only ask follow-up questions for genuinely ambiguous points.
-Do NOT ask one question per finding.
-
-### Step 6: Generate PRD + Prototype
-
-**PRD**: Auto-detect product type, use template, run 10-point quality check
-(see prd-generator skill).
-
-**Prototype** (KEY FEATURE):
-1. Determine prototype type (table/form/detail/modal)
-2. Start from the platform template (.qoder/templates/prototype-web.html or prototype-app.html)
-3. Fill placeholders with real fields/columns extracted from existing code
-4. Changed/new points highlighted (highlight-new class)
-5. Clickable, fillable, hover effects; single self-contained file
-6. Save per Storage rules above (Both -> 2 files with -web/-app suffix)
-
-### Step 7: EVA Gate + Confirm Publish + Auto Sync
-Before asking to publish, run the quality gate:
-```bash
-python .qoder/scripts/eval_prd.py <draft-prd.md> <prototype.html>
-```
-If it FAILs (<80%), fix the reported issues (missing sections / invented
-fields / non-canonical colors) and re-run until PASS. Then ask user to
-confirm publishing to workspace/specs/prd/.
-After publishing (and also after saving drafts/prototypes), run:
-```bash
-# 1. 归档到 data/docs/prd/ (立刻可搜, 不用等周五 cron)
-python .qoder/scripts/collect_prds.py
-# 2. 推送到团队
-python .qoder/scripts/team_sync.py push
-```
-This silently commits & pushes the PM's outputs to the team repo.
-The user NEVER needs to know git. If the script prints SYNC_CONFLICT,
-YOU (the AI) resolve the git conflict following its instructions —
-do not ask the user to run git commands.
-
----
-
-## Brainstorm Mode
-
-1. SCAMPER 7 dimensions + 5-Why root cause analysis (inline)
-2. Dispatch N sub-agents (default 2-4, scale with topic size) using
-   .qoder/agents/prd-research.md — each gets a distinct perspective
-   (competitor / user / tech / risk), web research only
-3. Each agent writes workspace/members/{developer}/drafts/brainstorm-agent{N}-{perspective}.md
-4. MERGE all agent reports into one summary, present to user,
-   then DELETE the per-agent brainstorm-agent*.md files
-5. Generate PRD + prototype matching target platform style (Step 6 above)
-
----
-
-## Planning Mode
-
-Follow .qoder/agents/prd-planning.md:
-1. Current state analysis (read code, platform-aware search)
-2. Ideal state research (web search)
-3. Gap analysis table
-4. Current plan (MVP) + Future plan
-5. ONE confirmation round on the full report (adjust at most twice, don't loop forever)
-6. Output plan-{topic}.md AND (if user wants to proceed) PRD + prototype via Step 6
-
----
-
-## Quick Mode (极速 — 3 步完成)
-
-> 触发："快速""quick""加个字段""小改动""加个按钮"
-> 小功能专用。砍掉所有非必要步骤。
-
-Follow .qoder/agents/prd-quick.md:
-1. **一次取全**：`context_pack.py`（1 次调用，不要再单独 search）
-2. **一次生成**：Mini-PRD + 微型原型（直接 Write，不分步）
-3. **一次确认**：问用户"可以吗"→ 确认后 push
-
-> Quick 模式**跳过**：EVA 评估、历史 PRD、网络搜索、style JSON 查颜色。
-> 原型直接从模板改 diff，模板已含正确颜色。
-
----
-
-## Data Reading Matrix
-
-| Mode | Read Code | Read PRD | Web Search | Read Style | Generate Prototype |
-|------|-----------|----------|------------|------------|-------------------|
-| Reference | YES | YES | YES | YES | YES match |
-| Brainstorm | STYLE ONLY* | NO | YES | YES | YES new |
-| Planning | YES | YES | YES | YES | YES diff |
-| Quick | YES | NO | NO | YES | YES micro |
-
-*Brainstorm: business research happens on the web, but the prototype style
-MUST come from real code. Before generating any new-feature prototype:
-run `--style <type> --platform <p>`, read 1-2 closest real pages, and for
-dashboard/看板/大屏 requirements read data/index/chart-style-reference.json
-(two in-system idioms: 大屏深蓝风 = dashboard/monitor, 浅色卡片风 =
-dashboard/workbench). Never invent a generic admin look.
-
----
-
-## Prototype Rules
-
-1. Style priority: real .vue code > vben-style-reference.json / Vant tokens > PDF spec
-2. Only change the diff, everything else identical to existing page
-3. Interactive: buttons, forms, tables must work
-4. Single file: one HTML with all CSS and JS
-5. Templates already contain the correct design tokens — do not invent colors
-
-### Web (fywl-ui) tokens — from data/index/vben-style-reference.json
-- Primary: `hsl(212 100% 45%)` via `--primary` CSS variable
-- Destructive: `hsl(359.33 100% 65.1%)`, Success: `hsl(144 57% 58%)`
-- Background: `hsl(216 20.11% 95.47%)` deep / #ffffff card
-- Font: PingFang SC / Microsoft YaHei, 14px
-- Table: VxeGrid style, fixed header, stripe
-- Form: labelWidth 80-120px, grid 2-4 columns
-
-### APP (Carmg-H5) tokens — Vant 3
-- `--van-primary-color: #1989fa`, success #07c160, warning #ff976a, danger #ee0a24
-- max-width: 375px, bottom tab bar, mobile layout
+> 旧参数路由模式不再支持。输入 `/wl-prd-` 可看到 3 个新命令。

package/templates/qoder/commands/wl-search.md

@@ -1,52 +1,88 @@
 ---
 name: wl-search
-description: "Search code index by keyword or API. Auto-approve. Returns compact results."
-argument-hint: "[keyword] or --api [path] or --list or --modules"
+description: "查代码/业务/API/字段/PRD + 知识图谱(影响分析/覆盖矩阵/功能画像/业务流程/多跳遍历)的唯一入口。"
+argument-hint: "[keyword] or --api [path] or subcommand. 全系13个能力见下表"
 auto-approve: true
-allowed-tools: [Read, Bash]
+allowed-tools: [Read, Bash, mcp__qoder-knowledge-graph]
 ---
 
-# /wl-search - Search Code Index
+# /wl-search - 搜索代码 & 知识图谱
 
 User input: $ARGUMENTS
 
-## THIS IS THE ONLY WAY TO SEARCH CODE
+## 🔧 环境自检（QoderWork 桌面端 vs Qoder IDE/CLI）
 
-When user asks about ANY code/business/API, use this command.
-It calls search_index.py which returns compact results (~200 bytes).
-DO NOT grep the entire codebase.
+**先确定仓库根 R**（QoderWork 桌面端工作目录不是仓库根，相对路径会失效）：
+```bash
+R=$(python ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
+```
+> 后续脚本统一用 `python "$R/.qoder/scripts/xxx.py"`。
 
-## Execution
+## 双轨：MCP 优先（仅 QoderWork）/ kg.py 兜底（全系列通用）
 
-Run exactly this command:
-```
-python .qoder/scripts/search_index.py $ARGUMENTS
-```
+**QoderWork 环境**（有 `mcp__qoder-knowledge-graph`）：直接调 MCP 工具，更快。
+**其他 Qoder 载体**（IDE/Quest/CLI）：跑 `python "$R/.qoder/scripts/kg.py"`，功能等价。
+
+不确定在哪个环境？先试 MCP；MCP 工具不存在就用 kg.py。
+
+## 13 个能力对照表
+
+| 用户要查什么 | MCP 工具（QoderWork） | kg.py 命令（全系列） |
+|-------------|---------------------|---------------------|
+| 代码在哪 / 搜关键词 | `search_code(keyword='考勤', platform='web')` | `kg.py search 考勤 --platform web` |
+| API 端点 | `search_api(keyword='salary')` | `kg.py api salary` |
+| 已有 PRD（防重复造轮子） | `search_prd(keyword='保险')` | `kg.py prd 保险` |
+| 改某接口影响哪些页面 | `get_impact(endpoint='/asset')` | `kg.py impact /asset` |
+| 某函数/端点的完整关联 | `context_360(symbol='handleExport')` | `kg.py context360 handleExport` |
+| 一次取全(代码+页面+字段+API) | `context_pack(keyword='车辆', role='pm')` | `kg.py context 车辆 --role pm` |
+| 哪些功能有/没测试 | `coverage_matrix()` | `kg.py coverage` |
+| 功能完整画像 | `feature_overview(feature='资产管理')` | `kg.py feature 资产管理` |
+| 业务流程链（几步） | `get_workflow(module='assets')` | `kg.py workflow assets` |
+| 多跳遍历（关联实体） | `multi_hop(symbol='资产管理', max_depth=3)` | `kg.py hop 资产管理 --depth 3` |
+| Repo Wiki 模块文档 | `search_wiki(keyword='考勤')` | `kg.py wiki 考勤` |
+| 原型预填（真实数据） | `fill_prototype(keyword='车辆', platform='web')` | `kg.py fill-prototype 车辆 --platform web` |
+| 设计系统规范 | `get_design_system(platform='web')` | `kg.py design-system --platform web` |
+
+## 快速判断该用哪个
+
+- **"这个功能已经有了吗"** → `prd` 查需求 + `feature` 看画像
+- **"改这个会影响谁"** → `impact`
+- **"哪些功能缺测试"** → `coverage`
+- **"盘点流程有几步"** → `workflow`
+- **"XX 谁调用了/调用链"** → `context360` 或 `hop`
+- **写 PRD 前一次取全** → `context --role pm`
+- **出原型前** → `design-system` + `fill-prototype`
+
+## 字段/页面风格/组件（仍用 search_index.py）
+
+这些 kg.py 未单独封装，直接跑：
 
-If no arguments provided, run:
 ```
-python .qoder/scripts/search_index.py --list
+python "$R/.qoder/scripts/search_index.py" --field <字段名>
+python "$R/.qoder/scripts/search_index.py" --style <table|form|detail|modal|dashboard> [--platform web|app]
+python "$R/.qoder/scripts/search_index.py" --list        # Top50 关键词
+python "$R/.qoder/scripts/search_index.py" --modules     # 项目模块概览
+python "$R/.qoder/scripts/search_index.py" --components  # 组件使用统计
 ```
 
-## How to Use Results
+## 没给参数时
 
-The script returns:
-- Matched files grouped by project
-- Shortened paths (project/module/.../file.java)
-- Max 5 files per keyword
+如果用户没给关键词/子命令，先问意图，或跑 `python "$R/.qoder/scripts/search_index.py" --list` 列出热门关键词让用户选。
+
+## DO NOT grep the entire codebase
+
+## How to Use Results
 
-After getting results:
 1. Pick the most relevant files (2-3 max)
 2. Read ONLY those files directly
-3. Answer the user's question
+3. Answer the user's question — 提炼后回答，别贴原始输出
 
 ## Examples
 
-- `/wl-search 考勤` -> searches attendance related files
-- `/wl-search insurance --platform web` -> insurance files in fywl-ui only
-- `/wl-search --prd 保险` -> searches collected PRDs
-- `/wl-search --style table --platform web` -> table-page examples in fywl-ui
-- `/wl-search --field nickName` -> where a field is used (label + files)
-- `/wl-search --api salary` -> searches salary API endpoints
-- `/wl-search --modules` -> shows project overview
-- `/wl-search --list` -> shows top 50 keywords
+- `/wl-search 考勤` -> `kg.py search 考勤`
+- `/wl-search --api salary` -> `kg.py api salary`
+- `/wl-search 改 /asset 影响谁` -> `kg.py impact /asset`
+- `/wl-search 哪些功能没测试` -> `kg.py coverage`
+- `/wl-search 资产管理功能画像` -> `kg.py feature 资产管理`
+- `/wl-search 资产盘点流程` -> `kg.py workflow assets`
+- `/wl-search --modules` -> `search_index.py --modules`