SkyJourneyandClaude Opus 5
4ce9a92013
寰汐 v2 上线双 MCP（个人端 /mcp/ 与管理端 /admin-mcp/），两条端点是**两条独立的 信任边界**——Token 前缀不同、工具集不同、视角不同（管理端看全量、个人端只看我参与的）。 一个插件塞两套会让普通员工的客户端里出现他根本调不动的管理工具，因此拆成两个插件， 按角色各装各的。 ## huanxi（个人端，全体员工） 7 个技能：shared / report / leader / task / issue / meeting / org - 新增 `issue` `meeting`——v2 的议题域与会议域（M6v2 会议×议题解耦后的产物） - **删除 `weekly`**——v2 没有 weekly_report 表，周报已并入报告体系 - 各技能重写为**流水线定义**而非使用说明：写明工具调用顺序、ID 在步骤间怎么传、 人工确认节点落在哪。「禁止自动提交」这条 v1 已验证的硬约束保留 - 删掉 `references/` 拆分文件——v2 技能自包含 ## huanxi-admin（管理端，仅后台管理员） 4 个技能：admin-shared / admin-report / admin-module / admin-ops MCP server key 取 `huanxi-admin`（与个人端的 `huanxi` 不同名），否则两插件并存时 会键冲突。 ## 缓存目录按信任边界隔离 `~/.claude/huanxi-cache/` 下分 `personal/` `admin/` `dict/`：前两者视角不同， 混用会越权展示或数据错乱；`dict/` 与身份无关可共享。业务数据（任务/日报/会议/议题） **显式声明不缓存**——v1 没写这条，Agent 会自行决定缓存然后拿到陈旧数据。 ## 源码单一真相不在本仓库 技能源码在寰汐仓库 `skills/`，与 MCP docstring 同仓库同 commit——签名一改， 技能与工具在同一次改动里更新，从结构上消除跨仓库漂移（本仓库记忆 `feedback_plugin_dev.md` 记录的 4 类漂移覆盖全部 6 个 v1 技能，正是这个病）。 本仓库退化为**分发壳**，只接收 `python skills/sync_marketplace.py` 的产物，不手工编辑。 寰汐侧有 CI 守卫：技能里出现的每个工具名必须存在于实际注册表、个人端技能不得 指导调用管理端独有工具、不得硬编码状态字面量。 ## 本分支不合 main 插件配置的域名此刻跑的还是 v1，合进 main 会通过自动更新推给已安装用户， 他们的技能会去调 v1 上不存在的工具。合并前置条件写在 CLAUDE.md「已发布插件」节。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019Vyeia9k43dVaUFNLo8Lny
55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
---
|
|
name: huanxi-meeting
|
|
description: "寰汐会议：查会议与议程、发起临时会议、维护议程条目、写会议纪要。当用户说「今天有什么会」「加个议程」「记会议纪要」「开个会」时使用。"
|
|
---
|
|
|
|
# 寰汐会议
|
|
|
|
**前置：先读 `huanxi-shared`。**
|
|
|
|
系统里「会议」是通用概念，晨会只是一条周期会议系列。周期会议的每一期由系统自动生成，
|
|
**不要用 `meeting_create` 去建周期会议的某一期**——那个工具只发起临时会议。
|
|
|
|
---
|
|
|
|
## 常用流程
|
|
|
|
```
|
|
查 meeting_query(scope="participating"|"created"|"hosting"|"all")
|
|
↓ 与任务相反，**不隐藏已结束的会议**——翻历史记录是常见需求
|
|
meeting_get(meeting_ids=[...]) ← 含参会人、纪要、完整议程
|
|
|
|
发起临时会 meeting_create(title, scheduled_at?, attendee_ids?, room_id?)
|
|
↓ 发起人自动成为主持人与参会人
|
|
↓ room_id 先 dict_get 取 meeting_rooms
|
|
|
|
维护议程 agenda_write(meeting_id, create?, update?, delete_ids?, reorder_ids?)
|
|
↓ 一次调用可同时增、改、删、重排，返回操作后的完整议程
|
|
|
|
写纪要 meeting_minutes_save(meeting_id, content)
|
|
```
|
|
|
|
---
|
|
|
|
## 权限看下发的布尔，不要自己推算
|
|
|
|
`meeting_query` / `meeting_get` 返回里带 `can_edit`、`can_claim`。**直接用它们**——
|
|
主持人、创建人、后台管理员的组合规则比看上去复杂（比如当前主持人不能自行改派给别人），
|
|
自己按规则推算必然与服务端不一致，表现为「按钮该显示却没显示」或「显示了点了报错」。
|
|
|
|
---
|
|
|
|
## 会议结束后是只读的
|
|
|
|
`ended` 为 true 的会议，议程与纪要都不能再改，任何写入都会被拒。这是归档语义，
|
|
不是 bug——需要补记请让管理员在网页端「重新打开」该会议（有显式操作留痕）。
|
|
|
|
---
|
|
|
|
## 不在工具里的操作
|
|
|
|
认领/撤回/指定主持人、结束/重新打开会议**不在 MCP**。这些是一次点击的 UI 动作，
|
|
AI 代劳收益低而误操作代价高，请引导用户去网页端。
|
|
|
|
`agenda_write` 的 `reorder_ids` 要传**完整**的条目顺序列表，不是只传要移动的那几个。
|