feat: 寰汐插件随 v1.0.0 生产切换升级到 v2 技能组，新增独立管理端插件
huanxi 插件的技能内容从 v1 全面替换为 v2（huanxi-org/huanxi-weekly 等 v1 专属技能下线，新增 huanxi-issue/huanxi-lookup/huanxi-meeting），MCP 连接与 Token 获取方式同步更新为个人中心自助生成。 新增独立的 huanxi-admin 插件（管理端 4 个技能，hxa_ Token，普通员工无需 安装），此前一直卡在"v2 未部署到生产域名前不推送"这条约束，今晚寰汐 v1.0.0 生产切换完成后条件满足。 产物由 huanxi-menagement 仓库 skills/sync_marketplace.py 生成，技能源码 单一真相在该仓库的 skills/，本仓库只接收产物、不手工编辑。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018xxRKMuiGR4wYT3QbwCpDc
This commit is contained in:
SkyJourney
co-authored by
Claude Sonnet 5
Claude Sonnet 5
parent
d7aaaf8224
commit
600c0dd323
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: huanxi-admin-module
|
||||
description: "寰汐管理端模块与任务：全量查模块任务、建模块、改模块状态、整组配置成员、跨模块任务管理。当用户说「建个模块」「把某人加进模块」「全公司任务情况」「关掉这个模块」时使用。"
|
||||
---
|
||||
|
||||
# 寰汐管理端 · 模块与任务
|
||||
|
||||
**前置：先读 `huanxi-admin-shared`。**
|
||||
|
||||
全量视角，不受「我参不参与」过滤。
|
||||
|
||||
---
|
||||
|
||||
## 查
|
||||
|
||||
```
|
||||
module_query(status_category?, q?) 全量模块，带负责人与成员数
|
||||
module_get(module_ids=[...]) 详情含成员名单与各自角色
|
||||
task_query(module_ids?, assignee_ids?, status_category?, priority?, q?)
|
||||
task_get(task_ids=[...])
|
||||
```
|
||||
|
||||
过滤维度都收列表，一次查多个比循环调用好。
|
||||
|
||||
---
|
||||
|
||||
## 建模块
|
||||
|
||||
```
|
||||
module_create(name, type_id, leader_user_id, description?)
|
||||
```
|
||||
|
||||
`type_id` 先 `dict_get(kinds=["module_types"])` 取，`leader_user_id` 用 `user_query` 取。
|
||||
创建后会自动生成该模块的「杂记」任务，承载不值得单独建任务的零散工作。
|
||||
|
||||
---
|
||||
|
||||
## 改模块
|
||||
|
||||
```
|
||||
module_update(module_id, name?, description?, status_option_id?)
|
||||
```
|
||||
|
||||
⏸ **切到「已取消」有副作用**：级联取消该模块下全部未完成任务，并给成员发飞书通知。
|
||||
这不是可撤销的操作，确认清楚再调。
|
||||
|
||||
模块**删除**不在本端点——那是纠错场景（建错了），需要在后台确认。
|
||||
|
||||
---
|
||||
|
||||
## 成员整组配置
|
||||
|
||||
```
|
||||
module_set_members(module_id, members=[{user_id, role}, ...])
|
||||
```
|
||||
|
||||
⏸ **替换语义**：不在名单里的现有成员**会被移除**。正确做法：
|
||||
|
||||
```
|
||||
1. module_get 拿现有名单
|
||||
2. 在现有名单基础上做改动（加人/改角色/去人）
|
||||
3. 把完整的最终名单整组传回
|
||||
4. 先把「改完会变成谁、谁会被移除」说给用户听，确认后再调
|
||||
```
|
||||
|
||||
返回的 `added` / `role_changed` / `removed` 三组是本次实际发生的变更，
|
||||
用它向用户复述结果。
|
||||
|
||||
一人一模块只能有一个角色（`leader` / `reviewer` / `member`）。新加入的成员会收到飞书通知。
|
||||
|
||||
---
|
||||
|
||||
## 任务
|
||||
|
||||
```
|
||||
task_create(module_id, tasks=[{title, ...}])
|
||||
task_update(updates=[{id, status_option_id?, progress?, priority?, ...}])
|
||||
task_set_assignees(task_id, user_ids=[...])
|
||||
```
|
||||
|
||||
- 改状态先 `dict_get` 取 task 类型的 `status_option_id`
|
||||
- 状态与进度**有联动，只传一个就够**（进度 100 自动完成；已完成的调低进度自动回落）
|
||||
- 非叶子任务（`progress_readonly` 为 true）不能直接设进度，要改它的子任务
|
||||
- `task_set_assignees` 是**替换**不是追加，同 `module_set_members` 的注意事项
|
||||
|
||||
任务删除与跨模块转移不在本端点。
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
name: huanxi-admin-ops
|
||||
description: "寰汐管理端运维与内容：提交运维简报、查公告与自动报告、全量查会议与议题。当用户说「提交运维简报」「本周系统周报」「看看有哪些议题」时使用。"
|
||||
---
|
||||
|
||||
# 寰汐管理端 · 运维与内容
|
||||
|
||||
**前置：先读 `huanxi-admin-shared`。**
|
||||
|
||||
---
|
||||
|
||||
## 运维简报
|
||||
|
||||
```
|
||||
ops_briefing_submit(content, iso_week?)
|
||||
```
|
||||
|
||||
Markdown **原文存档，不经 AI 加工**——这是设计决策，简报的价值在于运维侧的原始记录，
|
||||
加工会丢失细节。你可以帮用户组织语言，但要让他确认最终文本，不要自作主张改写后直接提交。
|
||||
|
||||
**同一 ISO 周重复提交是版本覆盖**：旧版本保留但不再是当前版本，公告表里那条发布记录
|
||||
原地更新指向最新版。不传 `iso_week` 则用今天所在周。
|
||||
|
||||
⏸ 提交前把最终 Markdown 展示给用户确认。
|
||||
|
||||
---
|
||||
|
||||
## 公告与自动报告
|
||||
|
||||
```
|
||||
announcement_query(ids?, kind?, series_slug?, period_key?)
|
||||
```
|
||||
|
||||
统一入口，覆盖系统周报、周度复盘、版本发布、运维简报、人工公告。
|
||||
|
||||
- 按生命周期分类查 → `kind`
|
||||
- 某条内置报告的历次期次 → `series_slug`
|
||||
- 具体某一期 → 加 `period_key`
|
||||
|
||||
报告按受众分档（全员/管理层/老板/本人），过滤在服务端完成——查不到某条不代表它不存在。
|
||||
|
||||
---
|
||||
|
||||
## 会议与议题（只读）
|
||||
|
||||
```
|
||||
meeting_query(scope="all", status_category?, series_ids?, module_ids?, tag_ids?)
|
||||
issue_query(scope?, level?, status_category?, module_ids?, tag_ids?, q?)
|
||||
```
|
||||
|
||||
管理身份可见全部议题，含标记为「仅管理层可见」的那些。
|
||||
|
||||
议题的写操作（建、记进展、关闭）**不在管理端**——那些应当由议题的当事人在个人端做，
|
||||
管理端替他记进展会让决策链的「谁说的」失真。会议的写操作同理。
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
name: huanxi-admin-report
|
||||
description: "寰汐管理端汇报盘点：谁没交日报、跨用户查汇报内容、团队负载看板。当用户说「全公司谁没交」「盘点汇报」「谁比较闲」「看看某人这周报了什么」时使用。"
|
||||
---
|
||||
|
||||
# 寰汐管理端 · 汇报盘点
|
||||
|
||||
**前置：先读 `huanxi-admin-shared`。**
|
||||
|
||||
管理端最高频的场景。个人端只能看自己和自己负责的模块，这里是全量视角。
|
||||
|
||||
---
|
||||
|
||||
## 谁还没交（最常被问）
|
||||
|
||||
```
|
||||
report_pending(module_ids?, date?)
|
||||
```
|
||||
|
||||
只返回**存在未提交人员**的模块——交齐的模块不占篇幅。不传 `module_ids` 则盘点全部。
|
||||
|
||||
**统计口径含两条容易忽略的规则，不要自己重算**：
|
||||
|
||||
- 模块杂记不计入分母（那是零散工作的承载容器，不代表当天有汇报义务）
|
||||
- 当日免报的人**整体排除**——既不算未提交也不算已提交，不是「视为已提交」。
|
||||
这个区别很重要：算成已提交会污染「已交人数」，算成未提交会一直催不该催的人
|
||||
|
||||
回答用户时直接给名单和模块，不要把原始结构丢回去让他自己数。
|
||||
|
||||
---
|
||||
|
||||
## 查汇报内容
|
||||
|
||||
```
|
||||
report_query(user_id?, module_id?, date_from?, date_to?) 员工日报条目
|
||||
leader_report_query(user_id?, module_id?, date_from?, date_to?) 负责人日报
|
||||
```
|
||||
|
||||
三个维度可任意组合，都不传即查今天全部。典型用法：
|
||||
|
||||
- 「张三这周报了什么」→ `report_query(user_id=..., date_from=周一, date_to=今天)`
|
||||
- 「智能诊断模块上周的汇报」→ `report_query(module_id=..., date_from=..., date_to=...)`
|
||||
|
||||
**只读**。管理端不能替别人写或提交日报——那会让汇报失去「本人确认」的意义。
|
||||
|
||||
---
|
||||
|
||||
## 负载看板
|
||||
|
||||
```
|
||||
people_board()
|
||||
```
|
||||
|
||||
按人聚合的跨模块任务负载，**含 0 任务的人**。回答「谁比较闲」「谁扛得太多」时用它，
|
||||
比逐个 `task_query` 快得多。含 0 任务的人是有意的——那正是「谁完全没有负载」的答案。
|
||||
|
||||
---
|
||||
|
||||
## 组合用法
|
||||
|
||||
「这周谁又没交日报、手上还压着多少活」这类问题，是 `report_pending` + `people_board`
|
||||
两个结果的交叉，不需要额外工具：先拿未提交名单，再从看板里查这些人的任务数。
|
||||
|
||||
⏸ 涉及要不要点名、要不要发提醒时，先把名单给用户确认再说下一步——
|
||||
盘点的产出是信息，催办是另一个决定。
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: huanxi-admin-shared
|
||||
description: "寰汐管理端 MCP 共享基础：管理身份语义、高危操作边界、缓存策略、状态两层模型、人员查询。所有 huanxi-admin-* 技能必须先读本文件。"
|
||||
---
|
||||
|
||||
# 寰汐管理端 · 共享规则
|
||||
|
||||
所有 `huanxi-admin-*` 技能的**必读前置**。本技能族用的是管理端 Token（`hxa_`），
|
||||
与个人端（`hxp_`）是两条独立通道，**工具集不同、视角不同**。
|
||||
|
||||
---
|
||||
|
||||
## 你是以谁的身份在操作
|
||||
|
||||
管理端 Token 不绑定业务用户，执行时以 **Token 创建人的管理员身份**进行，
|
||||
所有写操作按该身份记入审计。`whoami` 回答「我现在代表谁」。
|
||||
|
||||
创建人若已停用或被撤销后台权限，Token 会一并失效——这不是 bug，是随人事变动收回权限。
|
||||
|
||||
视角是**全量**的：模块、任务、汇报都不受「我参不参与」过滤。这是与个人端最大的差别，
|
||||
也意味着你看到的东西大多不是你自己的，措辞上要注意（说「张三的日报」而不是「你的日报」）。
|
||||
|
||||
---
|
||||
|
||||
## 高危操作不在本端点
|
||||
|
||||
**账号启停、授予/撤销管理员与老板身份、通讯录全量同步、各类删除、状态选项与标签等
|
||||
字典的写操作——全部走网页后台。**
|
||||
|
||||
理由不是「危险所以不给」，而是网页后台有确认弹窗与完整的操作上下文，MCP 通道没有
|
||||
等价的「让人看清楚再点」环节。用户提这类需求时，直接告诉他去后台哪个页面，
|
||||
**不要试图用别的工具绕过去**。
|
||||
|
||||
---
|
||||
|
||||
## 参数以工具自身的说明为准
|
||||
|
||||
本文档与各技能都不重画参数表。参数名、必填项、取值范围以工具在 MCP 里注册的
|
||||
docstring 为唯一真相；技能只描述调用顺序、ID 如何传递、哪里必须停下来等用户确认。
|
||||
|
||||
工具名在 Claude 客户端里带前缀 `mcp__huanxi-admin__`，其他平台按各自约定；
|
||||
本文档统一写裸名。
|
||||
|
||||
---
|
||||
|
||||
## 状态是可配置的两层模型
|
||||
|
||||
**不要硬编码状态字面量。** 分两层：
|
||||
|
||||
- `category`：四类固定语义 `not_started` / `in_progress` / `completed` / `cancelled`，用于**判断**
|
||||
- `status_option_id`：具体状态项的 UUID，用于**写入**
|
||||
|
||||
改状态前先 `dict_get` 取对应 `entity_type`（module/task/issue/meeting，必须选对）
|
||||
下的选项。字典本身的增删改不在本端点。
|
||||
|
||||
---
|
||||
|
||||
## 人员查询
|
||||
|
||||
```
|
||||
user_query(q?, ids?, status?, has_backend_permission?)
|
||||
```
|
||||
|
||||
> 组织架构树（`org_tree`）已随 M16 身份体系替换下线——公司改用蚁熊通行证，
|
||||
> 它不提供部门信息。
|
||||
|
||||
`user_query` 比个人端多两个维度：`status`（active 在职 / observation 交接观察期 /
|
||||
inactive 已停用）与 `has_backend_permission`。用于盘点「谁在观察期」「谁有后台权限」。
|
||||
**只读**——账号启停与权限授予见上文。
|
||||
|
||||
---
|
||||
|
||||
## 缓存
|
||||
|
||||
缓存根 `~/.claude/huanxi-cache/`，管理端用 `admin/` 子目录，与个人端隔离——
|
||||
两边看到的模块范围不同，混用会把不该展示的内容展示出去。
|
||||
|
||||
| 类别 | 策略 |
|
||||
|---|---|
|
||||
| 身份 `admin/me.json` | 永久 |
|
||||
| 配置字典 `dict/*.json` | **`dict_version` 比对** + 24h 兜底 |
|
||||
| 人员与模块 `admin/all-modules.json` | 24h |
|
||||
| 工作日 `dict/workdays.json` | 按日期 key 永久 |
|
||||
| **业务数据**（汇报/任务/会议/议题） | **一律不缓存** |
|
||||
|
||||
字典为什么不能只靠 TTL：状态选项可能被停用，拿过期 ID 去写会**直接报错**——
|
||||
失败方向是「操作失败」而非「看到旧数据」，值得比对一次。`dict_get` 的返回自带
|
||||
`versions` 字段，连内容一起存即可，不要分两次调。
|
||||
|
||||
---
|
||||
|
||||
## 全局约定
|
||||
|
||||
1. **有副作用的写操作先确认**：`module_set_members`（替换语义，会移除名单外的人）、
|
||||
`module_update` 切「已取消」（级联取消该模块全部未完成任务并通知成员）。
|
||||
2. **盘点类查询直接给结论**：用户问「谁没交」，答案是名单，不是让他自己看原始数据。
|
||||
3. **先解析 ID 再操作**，不要凭名字猜。
|
||||
Reference in New Issue
Block a user