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
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
---
|
|
name: huanxi-issue
|
|
description: "寰汐议题:提出议题、记录进展与决策链、调整分级、关闭。当用户说「提个议题」「这事记一下」「议题进展」「关掉这个议题」时使用。"
|
|
---
|
|
|
|
# 寰汐议题
|
|
|
|
**前置:先读 `huanxi-shared`。**
|
|
|
|
议题是「需要被讨论和跟进的事」,与任务的区别:任务有明确执行人和完成标准,
|
|
议题是待决策或待澄清的问题。**议题不需要审批**,任何非观察期用户直接建。
|
|
|
|
---
|
|
|
|
## 决策链是核心
|
|
|
|
议题的价值不在「现在什么状态」,而在 `progress_logs` 记录的**怎么走到这一步的**。
|
|
`issue_get` 会带出完整决策链——起草结论、回顾判断时都应基于它,而不是只看当前状态。
|
|
|
|
---
|
|
|
|
## 常用流程
|
|
|
|
```
|
|
提出 issue_create(issues=[{title, description?, level?, is_management_only?,
|
|
participant_ids?, module_ids?, tag_ids?}])
|
|
|
|
查 issue_query(scope="library"|"created"|"participating", level?, q?, ...)
|
|
issue_get(issue_ids=[...]) ← 含决策链
|
|
|
|
记进展 issue_record_progress(issue_id, content, meeting_id?)
|
|
↓ meeting_id 填了 = 这条结论是某次会上定的,会议与议题因此建立关联
|
|
↓ 不填 = 独立记录的一条进展
|
|
|
|
调分级 issue_update(updates=[{id, level}]) ← 变更会记入决策链
|
|
|
|
关闭 ⏸ 先与用户确认结论文字
|
|
issue_close(issue_id, conclusion) ← 结论必填
|
|
```
|
|
|
|
---
|
|
|
|
## 分级
|
|
|
|
`critical`(必须讨论)/ `watch`(需关注)/ `info`(信息同步)。这是**议题**的分级,
|
|
与任务的 `priority` 是两套取值,别混。
|
|
|
|
---
|
|
|
|
## 几条容易踩的
|
|
|
|
- **关闭必须带结论,且要走 `issue_close`**。用 `issue_update` 改状态到「已完成」是另一条
|
|
路径,服务端会拒——「关了但没说为什么」不允许存在。
|
|
- **`is_management_only` 的议题只对管理层/创建人/参与人可见**,其余人在列表和详情里
|
|
都看不到(不是置灰,是不存在)。你查不到某条议题时,可能就是这个原因,不要断言它不存在。
|
|
- 编辑/关闭/重开/删除需要是**创建人或后台管理员**;记进展的范围更宽(创建人、参与人、
|
|
或该条挂在某会议下时该会议的主持人)。
|
|
- 默认隐藏已完成/已取消,要看全部传 `include_closed=true`。
|