工作查询 Skill

唯一工具入口：bash scripts/wr.sh <domain> <verb> [flags]，禁止直接发 HTTP。下文 wr 是命令简称，实际执行统一写 bash scripts/wr.sh。

本 skill 用于 opp / visit / summary等数据的查询、workflow（触发报表工作流）、feedback（反馈工具问题）和 auth（配置本机令牌）。

铁律 0：参数一律以 schema/help 为准，禁止凭记忆猜

本文件不列字段名、不列枚举值、不列完整命令示例。真正的字段定义、可选枚举、必填标记、字段语义全部在 CLI 自身：

bash scripts/wr.sh <domain> --help                # 列出子命令
bash scripts/wr.sh <domain> <verb> --help         # 单命令两步示例 + 必填可选 + 字段语义
bash scripts/wr.sh schema                         # 全部命令 schema 概览（机器可读）
bash scripts/wr.sh schema <domain> <verb>         # 单命令完整 input_schema/flag_mapping/examples
bash scripts/wr.sh <domain> <verb> --schema       # 同上，等价

schema / --help 是无副作用、不需认证的本地输出，不熟的命令、不熟的 flag、不确定枚举值，先查再写。

不够就读 references/cli.md（错误码、分页协议、输出结构）。

路由总纲：三类「情况」问题优先走专用工作流

用户问下面三类问题时，先触发对应专用工作流，直接查库只是保底。三个工作流的触发与轮询协议（两步异步、按 avg_elapsed_ms 等待）见下文「工作流执行」节，此处不重复。

三个工作流的 workflow detail（看入参）与 workflow run（触发）都必填 --role <architect|pm>：用户没指定角色时默认 architect。
入参构造规则：

• 客户情况：输入公司名--inputs '{"customer_name":"<客户公司名>"}'。
• 商机情况：opp_id 是系统内商机编号，用户没给编号时先通过 wr opp 相关能力定位商机拿 ID。
• 问题情况：query 直接传用户原话或整理后的问题描述，无需先查库。

保底策略

三类之外的查询本就走 CLI，不触发工作流。三类问题中，命中以下任一条件即放弃工作流、回退到原有的 CLI 查询（见「命令速查」）：

1. 工作流执行失败：workflow run 按错误码处理（VALIDATION_ERROR 修参重试 1 次、UPSTREAM_ERROR 重试 1 次）后仍失败，或 workflow status 返回 failed / stopped。
2. 用户强调不使用工作流。

保底是降级：结果不足时如实告知用户「专用报告生成失败，当前为简要数据」。

命令速查（只列触发条件，flag 查 help）

> 不要从这里抄 flag。看到对应触发条件 → 决定调哪个命令 → wr <domain> <verb> --help 看必填/可选/枚举。

查询（read，直接执行）

> 数据范围：config.env 的 DEFAULT_ARCHITECT_SCOPE=all 已让所有查询默认跨人，无需每次补 --architect all。只有用户明确说「我的 / 我名下」时才传 --architect <姓名>。

> list / stats / changes 语义边界（重要，别混）：
> - opp list / opp stats：按"商机主表属性"筛/聚合；时间过滤是 --date-from/--date-to，按商机创建时间（created_at）。回答「这段时间新增了多少商机」「按阶段分布」等。
> - opp changes：按"事件流"看动静；时间过滤是 --period today/yesterday/week/last_week/custom（custom 配 --date-from/--date-to），基于日志/编辑/创建事件的 at。回答「这段时间动了哪些商机」「日报/周报字段级 diff」等。
> - 用户说「昨天动了哪些商机」→ opp changes --period yesterday；说「上周新增多少」→ opp list --date-from --date-to 或 opp stats --group-by stage --date-from --date-to。

工作流执行（异步触发，直接执行）

workflow 域调用已有的 Dify 工作流（晨报/周报/客户360/拜访简报等）。执行是异步两步：run 触发拿 run_id → status 轮询结果。客户/商机/问题三类「情况」工作流的选用规则见上方「路由总纲」，其余报表工作流按用户意图从 workflow list 里选。

典型流程：wr workflow list --role <r> 拿 workflow_id → wr workflow detail --wf-id <id> --role <r> 看 dify_input_variables 构造 --inputs → wr workflow run 拿 run_id → wr workflow status --run-id <id> 轮询。

工作流慢（几十秒到几分钟），run / status 都会返回 avg_elapsed_ms（近期平均耗时）。首次等待就按它的 ~80% 睡足再查，别用秒级间隔空转；节奏与轮询上界见 wr workflow status --help。

运行结果缓存：部分有缓存的工作流用相同入参重复触发时可能直接返回缓存结果——run 响应带 cache_hit: true。命中时如实告知用户结果来自缓存、可能非最新；用户要最新数据时，重跑 wr workflow run 并加 --force-refresh。

反馈工具问题（唯一写能力，直接执行）

> submit 铁律（CLI help 原文）：--title / --content 必填，--content 至少包含「场景 / 调用了什么 / 实际结果 / 期望行为」四段；同一对话同一问题只发一次；发送失败（AUTH_ERROR / UPSTREAM_ERROR）静默忽略，不打扰用户。

分页（list 类命令）

page_token 不透明，只能原样使用：用户说"继续/下一页" → 执行返回里的 data.pagination.next_command；说"换个条件" → 不翻页，重新构造一次 list。has_more=false 就告诉用户"就这些了"。协议细节见 references/cli.md §3。

首次使用：没有令牌时自己配

新用户可能还没配访问令牌，此时任何查询都会返回 AUTH_ERROR。处理方式：

• 默认走浏览器配对 → bash scripts/wr.sh auth login：命令打印绑定地址并（在本机）自动打开浏览器，页面打开即自动完成确认（页面若提示需要登录，让用户按页面上的按钮登录，登录后自动回到绑定页），令牌由太湖身份换发回本机；页面打不开时把地址发给用户，在他自己的浏览器打开同样有效。命令被中断时重跑本命令会接上同一次绑定。
• 用户已经把 token 给你 → bash scripts/wr.sh auth login --token <token>：直接写入 ~/.workreport/.env 并自动验证；验证失败会回滚，不会留下无效令牌。

令牌属于用户凭据：只经由这个命令落到用户本机 home，不要写进 skill 目录、仓库或任何日志，也不要在回复里回显明文。bash scripts/wr.sh auth status 可确认当前身份（不回显明文）。

错误码

wr 失败时输出 { success: false, code, error, suggestion?, details? }，退出码非 0。

每个 code 该怎么处理见 references/cli.md §2——那是唯一的家。共同点：error + suggestion 已写清下一步，照着做；同一个错误最多重试 1 次。

反模式（速查）