@yunkeai/yunke-cli 3.0.0-alpha.0 → 3.0.1

package/dist/skills/yunke-crm-team-analysis/SKILL.md

@@ -1,75 +0,0 @@
----
-name: yunke-crm-team-analysis
-description: "基于销售或服务团队的数据，用 yunke yunke-crm 命令取数，生成中文《团队沟通分析报告》。需处理电话录音转文本、企业微信聊天记录、考勤定位数据等输入，输出包含沟通效率、协作密度、工作量饱和度、内外沟通比例、优秀话术标杆、违规话术识别、风险预警与行动建议的结构化周期报告时使用。默认匿名化员工信息，给出可执行管理建议。前置：需先 yunke crm.auth.login-web 页面登录（宿主无本地回调时用 crm.auth.login-device-code）。"
-metadata:
-  requires:
-    bins: ["yunke"]
----
-
-# 团队沟通分析报告（CLI 数据驱动）
-
-> **版本门槛：** 依赖 yunke-cli **≥ 3.0.0**（`schema.detail` 的参数/返回值来自上游契约）。
-> 检查 `yunke --version`，升级以安装包为准（SaaS 生产包可 `yunke self.update` 检查）。
-
-> **前置依赖**
-> - 命令族基础用法见 `../yunke-crm/SKILL.md`（yunke 的 crm 插件）。
-> - 必须先登录：`yunke crm.auth.status` 显示已登录即可；未登录则执行 `yunke crm.auth.login-web`（浏览器页面登录；宿主无本地回调时用 `crm.auth.login-device-code`，详见 yunke-crm skill）。
-> - **本文只写顺序与判据，不抄参数**：调用前先 `yunke schema.detail --command <命令名>` 拿全参。
-
-## 定位（与 periodic-report 互补）
-
-- `../yunke-crm-periodic-report/SKILL.md` 走**结构化数据**生成日/周/月报（强结构化、产品版式）。
-- 本 skill 走**通话转写 + 沟通明细**生成**长文管理分析报告**（重判断、重话术、重可落地建议）。
-- 若需统一口径可并用：本 skill 出全文分析，periodic-report 出结构化数据，合并时注明数据来源分区。
-
-## 前置：加载参考模板（必须）
-
-先读 `references/report-template.md` —— 固定角色设定（10 年经验销售运营总监）、必须覆盖的 7 个分析维度、固定报告结构骨架、写作风格与缺失数据处理规则。
-
-## 数据采集（用 yunke-crm CLI）
-
-按用户给定范围取数。典型命令：
-
-```bash
-# 通话清单 → 录音转写文本（用通话 ID 串联）
-yunke crm.call.log-list
-yunke crm.call.asr-result
-
-# 考勤定位（围栏 inOrOut / 停留时长 locDuration / 在线状态 activeType）
-yunke crm.location.everyone-last-location
-yunke crm.location.record-list
-```
-
-> **语义坑**
-> - `call.log-list` 的日期过滤键虽然叫 `last_connect_time_*`，**实际按记录创建时间过滤**，没有"通话开始时间"维度。
-> - 考勤语义来自定位记录的围栏字段（`inOrOut` 进出围栏、`locDuration` 停留时长），无独立打卡接口。
-> - 参数名、时间格式以 `yunke schema.detail --command <命令名>` 为准；各命令族写法不统一，不要凭记忆猜。
-
-## 执行流程
-
-1. **确认报告范围**：时间范围、团队规模、业务类型、可用数据源。
-2. **先证据归一，再写结论**：只基于已取到的数据或可直接计算的指标下结论。缺考勤定位/通话质检/沟通对象标签时，在正文或附录说明局限，不要补造细节。
-3. **覆盖核心分析维度**（只要数据支撑）：沟通效率、协作密度、风险预警、工作量饱和度、内外沟通比例、优秀话术标杆、违规/风险话术（私单/飞单/辱骂/过度承诺）。
-4. **按管理视角写**：把数字翻译成管理语言，指出最大风险点和亮点，识别执行断层/渠道失衡/资源集中，区分严重违规与一般风险。
-5. **结论可追溯**：每个关键判断回溯到具体指标、样本数、通话文本片段或渠道统计。出现真实姓名默认匿名化，除非用户明确要求保留。
-
-## 输出规则
-- 中文输出，专业、直接、偏管理汇报风格。
-- 结构与 `references/report-template.md` 一致。
-- 关键指标、风险汇总、饱和度分层优先用表格。
-- 明确标注异常值、离群点、趋势变化。
-- 明确区分事实、判断、建议，避免混写。
-
-## 分析规则
-- 缺失渠道数据写"数据不可得"或"暂未提供"，不要当作 0。
-- 私下返点/线下交易引导/辱骂客户等严重合规问题，归为立即处理事项。
-- 客户-facing 团队企微好友数（qwFriendCount）为 0，判为客户资产沉淀风险（风险信号 ≠ 已违规）。
-- SOP 完成率低/通话极短/工作量过度集中，落培训、质检或资源再分配建议。
-- 只在有可比历史周期时才写环比/同比/趋势。
-
-## 质量门槛
-- [ ] 执行摘要含 3~5 条关键发现
-- [ ] 正文至少 1 个关键指标表格
-- [ ] 同时覆盖正向标杆和负向风险
-- [ ] 行动建议按紧急程度分组且可执行
-- [ ] 附录说明数据来源、指标定义、局限性

package/dist/skills/yunke-crm-team-analysis/references/report-template.md

@@ -1,293 +0,0 @@
----
-name: report-template
-skill: yunke-crm-team-analysis
----
-
-# 团队沟通分析报告模板
-
-## 适用范围
-
-用于销售、客服、交付、技术支持等团队的周期性沟通分析报告。典型输入包括：
-
-- 电话录音转文本分析
-- 微信企业版聊天记录
-- 员工考勤定位数据
-
-如果只有部分数据源，照常输出报告，但必须在正文或附录中说明缺失项及影响。
-
-## 固定角色设定
-
-默认采用以下角色口径：
-
-- 你是一位拥有 10 年经验的资深销售运营总监和数据分析专家
-- 输出要专业、犀利、可落地
-- 不只罗列数字，要解释数字背后的管理问题与执行机会
-
-## 必须覆盖的分析维度
-
-1. 沟通效率指标
-2. 协作密度分析
-3. 风险识别预警
-4. 工作量饱和度
-5. 内外沟通比例
-6. 沟通优秀话术标杆
-7. 违规或风险话术识别
-
-## 固定报告结构
-
-按以下顺序输出：
-
-1. 标题区
-2. 执行摘要
-3. 详细数据分析
-4. 可视化建议
-5. 行动建议
-6. 附录：方法论说明
-
-## 标题区写法
-
-标题区至少包含：
-
-- 报告名称，例如：`销售二部团队沟通效率周报`
-- 时间范围，例如：`2026-03-09 至 2026-03-15`
-- 团队规模，例如：`85 人`
-- 业务类型，例如：`销售`
-
-## 执行摘要要求
-
-执行摘要写 3 到 5 条关键发现，每条都要同时包含：
-
-- 结论
-- 证据或指标
-- 管理含义
-
-优先挑选以下类型的发现：
-
-- 最严重的违规或合规风险
-- 最亮眼的优秀员工或优秀行为模式
-- 最明显的效率分化
-- 标准化执行缺口
-- 多渠道协同问题
-
-## 详细数据分析写法
-
-### 1. 沟通效率指标
-
-必须优先使用表格。推荐字段：
-
-
-| 员工姓名 | 有效通话数 | 新增客户数 | 跟进客户数 |
-| ---- | ----- | ----- | ----- |
-
-
-写完表格后补充：
-
-- 异常值标注
-- 关键亮点
-- 趋势变化
-
-### 2. 协作密度分析
-
-至少给出分层统计，例如：
-
-- 高协作
-- 中等协作
-- 低协作
-- 零协作
-
-如果可以，附上人数和占比，并解释这说明团队的协同水平如何。
-
-### 3. 风险识别预警
-
-至少拆成两个层级：
-
-- 高风险事件
-- 中风险事件
-
-高风险优先覆盖：
-
-- 私单、飞单、私下返点
-- 侮辱客户
-- 严重过度承诺
-- 客户资产完全未沉淀
-
-中风险优先覆盖：
-
-- SOP 执行率低
-- 无效沟通过高
-- 渠道单一
-- 工作量过度集中
-
-### 4. 工作量饱和度
-
-建议使用分层表格，例如：
-
-
-| 饱和度等级 | 员工数量 | 占比  | 平均有效通话数 |
-| ----- | ---- | --- | ------- |
-
-
-常见分层：
-
-- 超高饱和
-- 高饱和
-- 中等饱和
-- 低饱和
-- 零饱和
-
-必须补一句管理判断，说明当前资源分配是否失衡。
-
-### 5. 内外沟通比例
-
-优先按以下口径表达：
-
-- 对外客户沟通占比
-- 对内团队协作占比
-
-如果考勤定位或会话标签不足以精确判断，就写"基于现有数据推算"，不要伪装成精准统计。
-
-### 6. 沟通优秀话术标杆
-
-提供 3 到 5 个标杆案例，优先选：
-
-- 陌拜客户
-- 催单推进
-- 合同跟进
-- 客户异议处理
-- 客诉安抚
-
-每个案例尽量包含：
-
-- 场景
-- 亮点话术
-- 效果
-- 可复制点
-
-### 7. 违规话术识别
-
-将严重违规与其他风险行为分开写。
-
-严重违规案例至少包含：
-
-- 员工编号
-- 违规类型
-- 具体行为
-- 风险等级
-- 处理建议
-
-其他风险行为可以按类型汇总，例如：
-
-- 过度承诺
-- 情绪失控
-- 引导线下交易
-- 客户辱骂
-
-## 可视化建议要求
-
-给出 4 到 5 项适合 BI 或周报展示的图表建议，优先包括：
-
-- 热力图
-- 雷达图
-- 趋势线图
-- 散点图
-- 风险矩阵
-
-每项建议都要说明图表用途，不要只报图表名称。
-
-## 行动建议要求
-
-按时间优先级给出建议：
-
-- 立即行动
-- 短期改进
-- 长期优化
-
-建议必须具备执行属性，避免空泛表述。优先给出：
-
-- 合规处置
-- 话术培训
-- 客户资产沉淀要求
-- 工作量再分配
-- 激励和考核机制
-- 系统能力建设
-
-## 附录要求
-
-附录至少包含：
-
-- 数据来源
-- 指标定义
-- 局限性说明
-
-如果某个关键数据源缺失，例如考勤定位数据，必须在局限性说明中点明影响。
-
-## 写作风格要求
-
-- 明确奖罚分明
-- 优秀案例要提炼可复制经验
-- 风险问题要指出根因，不要停留在表面
-- 负面问题允许直接，但不要情绪化
-- 结论必须服务于管理动作
-
-## 缺失数据处理
-
-遵守以下规则：
-
-- 没有趋势数据，就不要写环比或同比
-- 没有通话文本，就不要虚构优秀话术原文
-- 没有明确违规证据，就写"风险信号"而不是"已违规"
-- 没有考勤定位数据，就不要做时空协同结论
-
-## 建议输出骨架
-
-```markdown
-# 销售二部团队沟通效率周报
-
-时间范围：2026-03-09 至 2026-03-15
-团队规模：85 人
-业务类型：销售
-
-## 执行摘要
-1. ...
-2. ...
-3. ...
-
-## 详细数据分析
-### 1. 沟通效率指标
-| ... |
-
-### 2. 协作密度分析
-...
-
-### 3. 风险识别预警
-...
-
-### 4. 工作量饱和度
-| ... |
-
-### 5. 内外沟通比例
-...
-
-### 6. 沟通优秀话术标杆
-...
-
-### 7. 违规话术识别
-...
-
-## 可视化建议
-1. ...
-2. ...
-
-## 行动建议
-### 立即行动
-1. ...
-
-### 短期改进
-1. ...
-
-### 长期优化
-1. ...
-
-## 附录：方法论说明
-...
-```

package/dist/skills/yunke-wecom/SKILL.md

@@ -1,162 +0,0 @@
----
-name: yunke-wecom
-description: "用 yunke 按业务场景查企业微信（企微）数据：企微客户资产盘点、会话与沟通质量、客户群运营、敏感词质检、朋友圈运营、员工回复超时、企微通话与整体看板。用户提到企业微信、企微、企微客户、企微好友、客户群、企微群、聊天记录、会话、敏感词、企微朋友圈、超时回复、企微通话、员工企微号、企微数据盘点时使用。前置：需先完成 CRM 登录（浏览器页面登录）。"
-metadata:
-  requires:
-    bins: ["yunke"]
----
-
-# 企业微信（yunke-wecom）
-
-按**业务问题**组织企微取数，不按接口组织。参数名、类型、枚举和返回结构一律运行时查，本文只写
-「回答什么问题 → 按什么顺序调 → 按什么口径汇总」。
-
-> **版本门槛：** 依赖 yunke-cli **≥ 3.0.0**（`schema.detail` 的参数/返回值直接来自上游契约）。
-
-> **前置依赖**
-> - 登录、JSON 信封、命令发现规则见 `../yunke-cli-skills/SKILL.md` 与 `../yunke-crm/SKILL.md`。
->   未登录先 `yunke crm.auth.status`，需要时再 `yunke crm.auth.login-web`（浏览器页面登录；宿主无本地回调时用 `crm.auth.login-device-code`）。
-> - 首次调用某命令前先跑 `yunke schema.detail --command <命令名>`，一次拿全参数。
-> - 本文只覆盖**企业微信**（`crm.wecom.*`）。个人微信是另一套数据（`crm.wechat.*`），不要混用。
-
-## 先认 ID：企微最容易错的一层
-
-同一个概念在不同命令里叫不同名字；喂错不会报错，只会返回空。
-
-| 实体 | 唯一标识 | 从哪拿 | 在别的命令里叫什么 |
-|---|---|---|---|
-| 员工企微账号 | `wechatId` | `wecom_list_contacts` 的 `wechatId` | 会话类命令的 `user_id`、时间轴的 `wechat_id` |
-| 云客员工 | `userId` | `wecom_list_contacts` 的 `userId`、`crm.org.*` | 大多数命令的 `user_id` |
-| 企微主体 | `corpId` | `wecom_list_contacts.corpId`、`wecom_list_chatrooms.corpId`、`wecom_search_messages` 的 `corpNum` | `corp_id`（拉会话消息时必填） |
-| 客户 | `customerId` | `wecom_search_customers.customerId` | `to_id`（type=1）、`customer_ids`、`qw_customer_id` |
-| 群 | `roomId` | `wecom_list_chatrooms.roomId` | `to_id`（type=2） |
-| 会话 | `sessionId` | `wecom_timeline.sessionId` | — |
-
-**最容易踩的：`user_id` 在会话类命令里是员工企微号，在客户/统计类命令里是云客员工 ID。**
-拿不准时先 `wecom_list_contacts`，它同时返回 `userId` 和 `wechatId`，按字段名取。
-
-## 场景配方
-
-### 1. 客户资产盘点
-
-回答：公司企微沉淀了多少客户、谁加的、有没有重复跟进、有没有解绑流失。
-
-```bash
-yunke crm.wecom.wecom_list_contacts
-yunke crm.wecom.wecom_search_customers
-yunke crm.wecom.wecom_get_customer
-yunke crm.wecom.wecom_repeat_friends
-yunke crm.wecom.wecom_new_friend_stats
-yunke crm.wecom.wecom_customer_relations
-```
-
-- 先分页取全客户列表；**行数不是客户数**——一行 = 一个「员工-客户」关系，同一客户被多人添加会出现多行，
-  按 `customerId` 去重后再统计。
-- 重点客户查详情和被哪些员工添加，用 `wecom_get_customer`；关注员工离职对客户的影响时看它的 `followers`。
-- 重复跟进看 `wecom_repeat_friends`；新增趋势看 `wecom_new_friend_stats`；解绑/关联状态看 `wecom_customer_relations`。
-- 口径：客户数按 `customerId` 去重；新增按添加时间；解绑数按关联状态过滤。
-
-### 2. 会话与沟通质量
-
-回答：某员工最近和谁聊过、聊了什么、沟通量多少、有没有长语音和通话。
-
-```bash
-yunke crm.wecom.wecom_timeline
-yunke crm.wecom.wecom_get_chat_records
-yunke crm.wecom.wecom_search_messages
-yunke crm.wecom.wecom_msg_stats
-yunke crm.wecom.wecom_get_calls
-```
-
-- 先用时间轴定位会话（按员工或按客户），再用消息明细还原上下文。
-- 只知道关键词、不知道跟谁聊时，用全文检索；已知会话就直接拉明细，别绕检索。
-- 沟通量、长语音做汇总用 `wecom_msg_stats`，不要拿消息明细自己数。
-- 通话量、接通情况用 `wecom_get_calls`，先分页取全；录音文件与转写不在这个命令里。
-- 口径：会话数按 `sessionId` 去重；消息数用时间轴的收发计数；长语音看统计里的时长与次数。
-- **时间轴没有分页**，必须指定员工或客户，否则会一次拉全企业；时间按小时截断。
-- 消息明细单页固定 20 条，靠首末游标翻页；自动插入的时间分隔行不是真实消息。
-
-### 3. 客户群运营
-
-回答：有多少客户群、哪些群在响应、哪些群快死了、群成员是谁。
-
-```bash
-yunke crm.wecom.wecom_list_chatrooms
-yunke crm.wecom.wecom_chatroom_stats
-yunke crm.wecom.wecom_group_anomalies
-yunke crm.wecom.wecom_get_chatroom_members
-```
-
-- 群档案分页取全 → 响应率/沉默群看统计 → 异动看异动统计 → 指定群拉成员。
-- 口径：群数按 `roomId` 去重；沉默群阈值（例如 7 天无消息）先跟用户确认，并在结论里写明用的阈值。
-- **统计命令不传统计粒度会返回全 0**，这不是没数据，重试无用；只有明细视图才需要起止时间。
-- 群档案默认不排序，翻页顺序不保证稳定；成员是一次全量返回，不分页。
-
-### 4. 敏感词质检
-
-回答：哪些员工/客户触发了敏感词、原文是什么、规则怎么配的。
-
-```bash
-yunke crm.wecom.wecom_get_sensitive_rules
-yunke crm.wecom.wecom_sensitive_stats
-yunke crm.wecom.wecom_get_chat_records
-```
-
-- 先看规则与词库，再取命中记录，最后按需还原会话上下文。
-- 口径：命中数按记录条数；按员工/部门/群分组时先分页取全。
-- 时间窗最长 90 天，且必须给开始时间；不传会走全历史索引并报错。
-- 首次查询某节点会自动补建一条缺省规则记录，是幂等初始化，不是写入了业务数据。
-
-### 5. 朋友圈运营
-
-回答：谁在发圈、发得多不多、内容是什么、互动如何。
-
-```bash
-yunke crm.wecom.wecom_get_moments
-```
-
-- 先出员工汇总定位异常，再用该员工的企微账号查内容明细。
-- 口径：发圈数、点赞数、评论数按员工汇总；明细按发布时间。
-- 统计与明细的时间跨度都不能超过 3 个自然月，超出直接报错、不会自动截断。
-- 明细只查一个账号，需要该账号的 `wechat_id` 与 `corp_id`。
-
-### 6. 员工回复超时
-
-回答：谁没在时限内回客户、超时多久、管理员提醒了没有。
-
-```bash
-yunke crm.wecom.wecom_timeout_records
-```
-
-- 先看今日指标与昨日对比，再下钻超时明细，需要上下文再接会话消息。
-- 口径：超时率的分母（按员工还是按客户）要先跟用户确认；排行前分页取全。
-- 返回里出现翻页提示就说明还没取完，不要按一页数据下结论。
-
-### 7. 整体怎么样 → 看板
-
-回答：某部门/某段时间的企微整体情况。
-
-```bash
-yunke crm.wecom.wecom_dashboard
-```
-
-- 看板只回答「整体怎么样」；一旦知道具体员工、客户或群，直接走上面的明细配方，不要绕看板。
-- 趋势类视图会把缺失日期补零后返回完整序列，空值不是缺数据。
-- 群聊趋势的响应率、免打扰类指标当前不产数（恒为 null），不要当成 0 或异常。
-- 只有登录日志视图分页，其余一次返回完整结果；做统计前把分页取全。
-
-## 通用护栏
-
-- **先取全再汇总**：分页接口出现翻页提示就继续翻，严禁只看第一页下结论。
-- **深度翻页有上限**：客户、消息、群列表都是 ES 查询，页深超过约 30 万条会被后端直接拒绝，
-  改用更窄的时间、部门或员工条件。
-- **空结果不是失败**：`totalCount=0`、空数组、空对象通常是查询成功但无匹配；
-  先检查 ID 语义和时间窗，再决定是否换参数。
-- **汇总与明细分工**：统计/看板只出数字，下钻必须换明细命令，不要拿汇总结果编明细。
-- **参数不猜**：未知参数会被直接拒绝，`details.available` 就是可用参数清单；一次查全比逐个试错快。
-
-## 边界
-
-- 没有数据支撑的结论不写，标注「数据未返回」；不要把缺失当 0。
-- 业务口径（沉默群阈值、超时率分母、活跃定义）由用户确认后在结论里写明，不替业务方默认。
-- 客户手机号、姓名可能带 `*`，是公司脱敏配置，不是数据错误。