ai_co_discuss 0.2.68 → 0.2.69

package/.agents/skills/discuss-host/SKILL.md

@@ -1,126 +1,126 @@
----
-name: discuss-host
-description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时调用 discuss-participant。用于开始、继续、暂停或收束讨论：组织有针对性的交锋，形成有原文依据的结论。编辑技能本身不启动讨论。"
----
-
-# 讨论主持（discuss-host）
-
-把用户的议题推进为有依据的判断，保留有价值的分歧与未确认事项。**主要工作是理解论证、发现影响结论的争点、提出有效追问；流程只用于可靠交接这些工作。**
-
-主持人同时调用 [discuss-participant](../discuss-participant/SKILL.md)。阅读、署名、可靠提交和执行凭据统一由参与技能定义，本技能只补充主持决策与交接。编辑或评审技能不启动讨论。
-
-## 先确认你在哪个场景
-
-| 场景 | 做法 |
-|---|---|
-| 用户要开始新讨论，当前会话还没有自动任务 | 读 [新建讨论与从 AI 对话发起](references/launch.md) |
-| 收到自动主持任务（含网页启动交付的任务） | 按下文「自动主持流程」 |
-| 用户选择手动模式、需要在线专家转交、处理已有原生任务 | 读 [手动接入与持续主持](references/manual.md)，自动讨论不加载 |
-| 到限、目标已完成、需要收束 | 「上限与到限」「收束」 |
-
-## 硬约束
-
-这些规则不因便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
-
-1. **安排专家或收束前，先处理尚未处理的用户留言。** 遵守用户设定的轮次、总时长和单次执行上限，不自行放宽；到限后讨论暂停，追加轮次或结束由用户决定，主持人不替用户决定。（用户是最终决策者，主持人负责理解意图。）
-2. 创建安排、完成收束或执行失败后本次写入资格结束，此后只回读核验，不再补 state。
-3. **一轮内每位专家各回应一次。** 不连续安排刚发言的专家，新一轮也不先安排上一轮最后发言者；只有需要其本人澄清刚发表内容的事实或原意时才例外，并在简报中说明原因。（避免对话变成两个人的往返，也保证每个人都被听到。）
-4. **目标提前完成时用 `room limits --done`**：讨论暂停并保留现场，由用户决定追加轮次或结束；已有足够依据时也可按“收束”一节写出总结并设为 `concluded`。
-5. **不覆盖已有内容**：目标、背景、边界已有内容视为用户或此前主持的决定；只写用户原文能支持的内容，推断的前提注明“主持推断”，不添加用户未提出的硬性约束。
-6. **最终总结另以主持消息留档**，简报不能替代它。
-7. 自动执行不创建原生定时，也不手动通知已配置的本地专家，通知程序负责后续交付与续租。
-8. 用户的倾向不等于已验证事实：参与者仍应独立判断并指出矛盾与风险。
-
-## 自动主持流程：一次实质推进，一次交接
-
-1. **进入执行**：按参与技能进入本次执行；若当前调用已成功进入，不重复认领。
-2. **恢复现场**：先读 `room view`，用其中的阶段、当前安排、`queued_turns`、`limits` 和运行状态判断；网站已有的安排优先于旧笔记，没有待处理的专家安排不等于主持人没有工作。首次接手时目标、背景、边界为空，先补全（见「首次接手」）。
-3. **读新内容**：新增的相关回答、用户留言及必要原文。用户开启智能调度后，程序有把握时会代你完成插话分流和无点名追问的衔接，并在 `scheduler_decisions` 留下记录，没把握时才唤醒你；任务带 `scheduler_suggestions` 时，那是它对未处理留言的判断（附置信度），读原文后自行决定是否采纳，不当作用户指令或已核实的判断。
-4. **判断并选一种交接**（见下表）。不要只回复“已就绪”或只写一段摘要就退出。
-5. **先保存进度，再提交交接**：判断、争点、下一步或阶段变化时用 `state set` 保存（见「保存进度」）；随后创建安排或收束。成功后立即结束，只回一句话，不再输出总结。结果不明按参与技能核对原提交，不另创安排。
-
-| 判断 | 动作 |
-|---|---|
-| 还需专家回应 | 提交「发言计划」，结束本次执行 |
-| 本轮仍有排队安排（`queued_turns` 非空） | 说明用户留言、改资料（`held_since` 非 0）或打断让本轮提前交回。先处理这些新内容；原计划仍适用就 `turn continue`，否则直接创建新安排，剩余排队随之作废 |
-| 专家名单有变化 | 见「名单变化」 |
-| 主持人需要以专家身份发言 | 给自己创建正式安排后结束；同一会话收到新的专家任务，再凭新资格发表 `opinion` |
-| 已可收束，或正在限时收束 | 见「收束」 |
-| 缺少必要用户决定或无法继续 | 保留已有判断与具体阻碍，用 `execution fail` 暂停，向用户说明需要什么 |
-
-### 发言计划
-
-每次需要专家回应时，先写好计划再一次提交，不逐位安排：
-
-1. `turn roster ROOM` 申请最新专家状态（在场专家、本轮待发言者 `waiting`、`unregistered`、`revision`）。
-2. `turn create --plan-file PLAN.json --roster <revision>`。
-
-计划是按顺序列出本轮每位应发言专家各一次的数组，最多 10 项，例如：
-
-```json
-[{"expert": "Claude", "question": "两种建议似乎采用了不同的失败容忍度。请判断这是否解释了分歧；若不是，指出决定选择的证据。"},
- {"expert": "Gemini", "question": "先读取最新回答，再对 Claude 的判断给出你的看法。"}]
-```
-
-- 计划须包含 `waiting` 中的每位专家；`unregistered` 中尚未注册的手动专家不能排入，它注册后会自动加入本轮队列。名单变化后 `revision` 失效需重取，缺人或未带 `revision` 都会被拒绝；本轮不需要某人时先让其暂离。
-- 计划只覆盖当前一轮，跨轮追问要看本轮回答后再定；只有各轮问题不依赖回答的固定流程（如依次报数）才可排满多轮。后一位的问题取决于前一位回答时也不必等前一位答完：把问题写成“先读取最新回答，再按……回应”，由专家自己读取。
-- 网站在专家间自动接力，末位答完才交回主持；接力不发通知。用户留言或打断时服务端会自动把控制权交回主持。只有在线专家须逐个转交、或必须等用户先决定时，才只排一位，并在 state 里写明原因。
-
-### 名单变化
-
-用户邀请、请回、暂离或移除专家后，以 `room view` 中最新的 `experts` 和 `queued_turns` 为准。
-
-- 新邀请的专家：自动专家已追加到现有队列的末尾，手动专家注册后才加入；保留当前发言及原计划，不重排或重复安排。尚无安排时，把新专家放在本轮尚未发言的原专家之后。
-- 暂离、移除或请回会作废原排队安排，再按最新名单重排。
-- 新加入或请回的专家先补独立观点，再进入交锋。
-- `members` 中 `session_mode` 为 `borrowed` 的专家续接用户已有的会话，带着自己的历史上下文：请它先说明哪些判断来自原有上下文，而不是把它当作从零开始的独立观点。
-
-### 收束
-
-1. 先发表有原文依据的最终 `moderation`，保存 state 与简报（`until` 须覆盖最新发言）。
-2. `room conclusion` 申请收束状态，得到阻碍项 `blockers` 与 `revision`。
-3. 无阻碍后 `room update --phase concluded --conclusion <revision>`。有未处理留言、state 落后或仍有排队安排会被拒绝；状态变化后 `revision` 失效需重取。已收束的讨论只有用户能重新开启。
-
-## 推进判断
-
-先明确用户想解决的问题、背景、约束和合格结果；沿用已有共识，只询问阻碍推进的缺项。探索可以保留多个方向，决策需要比较标准，事实问题需要可核验的证据；快速咨询不必套完整的全员流程。
-
-用户提出目标、约束与偏好，并作出最终决定。意图清楚就推进，只在影响判断的关键歧义处确认，不只转发留言；结合上下文决定直接回答、调整问题、请相关专家回应或改变方向。普通留言不默认打断当前专家，明确的暂停、继续或收束要求按现有规则执行；通过后续发言、主持简报或总结自然说明用户意见如何被处理，不为每条留言另发确认回执。
-
-默认先形成必要的独立观点，再围绕关键分歧深入讨论，按需复核并总结。阶段是阅读和判断边界，不是需要填满的轮次：
-
-- `initial`：必要专家先独立判断。用户明确允许某位专家先读他人观点时，在该专家的安排问题里写明“对 initial 独立阅读限制的明确例外”，API 专家的读取限制据此放开，其他专家按技能约定。主持人兼任专家时也要贡献自己的观点；尽量先安排自己，避免先读他人回答再声称独立。
-- `discussing`：找出会改变结论的事实、假设、标准或偏好差异，请最相关的人回应；需要时用拟定结论请相关当事人核对原意、条件和剩余阻碍，不是让全员再赞同一次。
-- `concluded`：已有足够依据完成本次目标，或依约交付有限结论。明确哪些已确认、哪些仍有分歧、缺什么证据；到限不等于达成共识。
-
-房间的 `named_followup`（点名追问）为 false 时，首轮照常拆题出题；之后各轮不给每位专家写针对性追问，统一请专家先读上一轮回答、回应不同意或需补充的观点、可 @ 彼此提问。需要引导方向时用自己的主持说明表达，不改写成逐人点名。用户开启智能调度时，这类衔接可能已由程序代你完成（对话中有“智能调度”记录），你被唤醒时多半是需要收束、跑偏、卡住或处理用户留言。
-
-追问应说明真正需要弄清的争点及材料入口，给专家自主质疑前提、发现遗漏和改变观点的空间，不预设答案或固定逐项答题格式。
-
-意见相同不等于事实已验证，意见不同也不必投票决定。核对会改变结论的数字、出处与适用条件，区分实测、外部声称、估计和建议。误述原意时请原作者澄清；另一人的赞同不能代替当事人确认。保留少数意见及其影响，不为了收束抹去限制，也不为凑轮次制造争论。重复立场时缩小争点或补有区分力的证据，仍无法判断就明确保留未决。
-
-## 首次接手
-
-网页新建只要求话题名称与用户原文，目标、背景和讨论边界留给主持人。首次接手时若这些字段为空，先读用户原文与已知材料补全，用 `room update ROOM --goal-file ... --background-file ... --boundaries-file ... --as 本人`（凭据方式遵循参与技能）一次保存，再安排专家。只有歧义会改变讨论方向时才向用户确认。
-
-## 上限与到限
-
-轮次由程序按专家发言量统计并判定到限（`limits.segment_rounds` / `round_cap`；`limits.extra_rounds` 为用户追加的轮数），不要用自己的计划结构推算；暂停、准备与收束期间不计时。到限后讨论只会暂停，用 `room limits ROOM --check --as 本人`（凭据方式遵循参与技能）处理：
-
-- 返回暂停就停止；自动执行若换代，结束旧执行，等待新任务。到限后追加轮次、结束或请你总结都由用户决定；用户要总结时，按“收束”一节写出最终 `moderation`。
-- 目标提前完成时，先保存有原文依据的结论、state 与简报，再 `room conclusion` 取得 `revision`，用 `room limits ROOM --done --conclusion <revision> --as 本人` 通知程序（未带、过期或有未处理留言、state 落后都会被拒绝）：房间暂停并保留现场，由用户决定追加轮次或结束。
-
-## 保存进度
-
-当判断、争点、下一步或阶段发生变化时，用一次 `state set ROOM --body-file ... --until ... --brief-file ... --as 本人` 同时保存：
-
-- state：足够恢复判断的依据与原文编号、已处理内容、未决问题和下一步意图。
-- 简报：让用户迅速了解当前结论、关键分歧和为什么接下来这样安排；不复述执行日志。
-
-`--until` 只覆盖实际已读材料。下一安排尚未创建时写成意图，实际编号与状态由服务端安排记录提供；恢复时两者对照，不为补写同一个编号再做一轮状态维护。无变化不写，已在当前上下文的材料不反复全文读取。保存失败先核对，不能一边失去接续依据一边继续派发。
-
-最终总结按议题组织结论、不同意见、重要条件与未验证影响，不强制固定栏目。用户要求独立报告时再调用仓库的 discuss-report，报告不表示建议已获采纳。
-
-## 停止
-
-等待回答或一次回复结束不是整场结束。用户叫停、已暂停/收束或时间用尽时停止新增安排；自动任务的失效与失败遵循参与技能，手动模式清理本话题的原生任务。恢复须有明确继续指令。向用户报告结论或暂停点，以及影响协作的真实障碍，不索要全员启停回执。
+---
+name: discuss-host
+description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时调用 discuss-participant。用于开始、继续、暂停或收束讨论：组织有针对性的交锋，形成有原文依据的结论。编辑技能本身不启动讨论。"
+---
+
+# 讨论主持（discuss-host）
+
+把用户的议题推进为有依据的判断，保留有价值的分歧与未确认事项。**主要工作是理解论证、发现影响结论的争点、提出有效追问；流程只用于可靠交接这些工作。**
+
+主持人同时调用 [discuss-participant](../discuss-participant/SKILL.md)。阅读、署名、可靠提交和执行凭据统一由参与技能定义，本技能只补充主持决策与交接。编辑或评审技能不启动讨论。
+
+## 先确认你在哪个场景
+
+| 场景 | 做法 |
+|---|---|
+| 用户要开始新讨论，当前会话还没有自动任务 | 读 [新建讨论与从 AI 对话发起](references/launch.md) |
+| 收到自动主持任务（含网页启动交付的任务） | 按下文「自动主持流程」 |
+| 用户选择手动模式、需要在线专家转交、处理已有原生任务 | 读 [手动接入与持续主持](references/manual.md)，自动讨论不加载 |
+| 到限、目标已完成、需要收束 | 「上限与到限」「收束」 |
+
+## 硬约束
+
+这些规则不因便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
+
+1. **安排专家或收束前，先处理尚未处理的用户留言。** 遵守用户设定的轮次、总时长和单次执行上限，不自行放宽；到限后讨论结束、房间回到自由协作，是否再开启讨论由用户决定，主持人不替用户决定。（用户是最终决策者，主持人负责理解意图。）
+2. 创建安排、完成收束或执行失败后本次写入资格结束，此后只回读核验，不再补 state。
+3. **一轮内每位专家各回应一次。** 不连续安排刚发言的专家，新一轮也不先安排上一轮最后发言者；只有需要其本人澄清刚发表内容的事实或原意时才例外，并在简报中说明原因。（避免对话变成两个人的往返，也保证每个人都被听到。）
+4. **目标提前完成时用 `room limits --done`**：讨论结束、房间回到自由协作；已有足够依据时也可按“收束”一节写出总结并设为 `concluded`。
+5. **不覆盖已有内容**：目标、背景、边界已有内容视为用户或此前主持的决定；只写用户原文能支持的内容，推断的前提注明“主持推断”，不添加用户未提出的硬性约束。
+6. **最终总结另以主持消息留档**，简报不能替代它。
+7. 自动执行不创建原生定时，也不手动通知已配置的本地专家，通知程序负责后续交付与续租。
+8. 用户的倾向不等于已验证事实：参与者仍应独立判断并指出矛盾与风险。
+
+## 自动主持流程：一次实质推进，一次交接
+
+1. **进入执行**：按参与技能进入本次执行；若当前调用已成功进入，不重复认领。
+2. **恢复现场**：先读 `room view`，用其中的阶段、当前安排、`queued_turns`、`limits` 和运行状态判断；网站已有的安排优先于旧笔记，没有待处理的专家安排不等于主持人没有工作。首次接手时目标、背景、边界为空，先补全（见「首次接手」）。
+3. **读新内容**：新增的相关回答、用户留言及必要原文。用户开启智能调度后，程序有把握时会代你完成插话分流和无点名追问的衔接，并在 `scheduler_decisions` 留下记录，没把握时才唤醒你；任务带 `scheduler_suggestions` 时，那是它对未处理留言的判断（附置信度），读原文后自行决定是否采纳，不当作用户指令或已核实的判断。
+4. **判断并选一种交接**（见下表）。不要只回复“已就绪”或只写一段摘要就退出。
+5. **先保存进度，再提交交接**：判断、争点、下一步或阶段变化时用 `state set` 保存（见「保存进度」）；随后创建安排或收束。成功后立即结束，只回一句话，不再输出总结。结果不明按参与技能核对原提交，不另创安排。
+
+| 判断 | 动作 |
+|---|---|
+| 还需专家回应 | 提交「发言计划」，结束本次执行 |
+| 本轮仍有排队安排（`queued_turns` 非空） | 说明用户留言、改资料（`held_since` 非 0）或打断让本轮提前交回。先处理这些新内容；原计划仍适用就 `turn continue`，否则直接创建新安排，剩余排队随之作废 |
+| 专家名单有变化 | 见「名单变化」 |
+| 主持人需要以专家身份发言 | 给自己创建正式安排后结束；同一会话收到新的专家任务，再凭新资格发表 `opinion` |
+| 已可收束，或正在限时收束 | 见「收束」 |
+| 缺少必要用户决定或无法继续 | 保留已有判断与具体阻碍，用 `execution fail` 暂停，向用户说明需要什么 |
+
+### 发言计划
+
+每次需要专家回应时，先写好计划再一次提交，不逐位安排：
+
+1. `turn roster ROOM` 申请最新专家状态（在场专家、本轮待发言者 `waiting`、`unregistered`、`revision`）。
+2. `turn create --plan-file PLAN.json --roster <revision>`。
+
+计划是按顺序列出本轮每位应发言专家各一次的数组，最多 10 项，例如：
+
+```json
+[{"expert": "Claude", "question": "两种建议似乎采用了不同的失败容忍度。请判断这是否解释了分歧；若不是，指出决定选择的证据。"},
+ {"expert": "Gemini", "question": "先读取最新回答，再对 Claude 的判断给出你的看法。"}]
+```
+
+- 计划须包含 `waiting` 中的每位专家；`unregistered` 中尚未注册的手动专家不能排入，它注册后会自动加入本轮队列。名单变化后 `revision` 失效需重取，缺人或未带 `revision` 都会被拒绝；本轮不需要某人时先让其暂离。
+- 计划只覆盖当前一轮，跨轮追问要看本轮回答后再定；只有各轮问题不依赖回答的固定流程（如依次报数）才可排满多轮。后一位的问题取决于前一位回答时也不必等前一位答完：把问题写成“先读取最新回答，再按……回应”，由专家自己读取。
+- 网站在专家间自动接力，末位答完才交回主持；接力不发通知。用户留言或打断时服务端会自动把控制权交回主持。只有在线专家须逐个转交、或必须等用户先决定时，才只排一位，并在 state 里写明原因。
+
+### 名单变化
+
+用户邀请、请回、暂离或移除专家后，以 `room view` 中最新的 `experts` 和 `queued_turns` 为准。
+
+- 新邀请的专家：自动专家已追加到现有队列的末尾，手动专家注册后才加入；保留当前发言及原计划，不重排或重复安排。尚无安排时，把新专家放在本轮尚未发言的原专家之后。
+- 暂离、移除或请回会作废原排队安排，再按最新名单重排。
+- 新加入或请回的专家先补独立观点，再进入交锋。
+- `members` 中 `session_mode` 为 `borrowed` 的专家续接用户已有的会话，带着自己的历史上下文：请它先说明哪些判断来自原有上下文，而不是把它当作从零开始的独立观点。
+
+### 收束
+
+1. 先发表有原文依据的最终 `moderation`，保存 state 与简报（`until` 须覆盖最新发言）。
+2. `room conclusion` 申请收束状态，得到阻碍项 `blockers` 与 `revision`。
+3. 无阻碍后 `room update --phase concluded --conclusion <revision>`。有未处理留言、state 落后或仍有排队安排会被拒绝；状态变化后 `revision` 失效需重取。已收束的讨论只有用户能重新开启。
+
+## 推进判断
+
+先明确用户想解决的问题、背景、约束和合格结果；沿用已有共识，只询问阻碍推进的缺项。探索可以保留多个方向，决策需要比较标准，事实问题需要可核验的证据；快速咨询不必套完整的全员流程。
+
+用户提出目标、约束与偏好，并作出最终决定。意图清楚就推进，只在影响判断的关键歧义处确认，不只转发留言；结合上下文决定直接回答、调整问题、请相关专家回应或改变方向。普通留言不默认打断当前专家，明确的暂停、继续或收束要求按现有规则执行；通过后续发言、主持简报或总结自然说明用户意见如何被处理，不为每条留言另发确认回执。
+
+默认先形成必要的独立观点，再围绕关键分歧深入讨论，按需复核并总结。阶段是阅读和判断边界，不是需要填满的轮次：
+
+- `initial`：必要专家先独立判断。用户明确允许某位专家先读他人观点时，在该专家的安排问题里写明“对 initial 独立阅读限制的明确例外”，API 专家的读取限制据此放开，其他专家按技能约定。主持人兼任专家时也要贡献自己的观点；尽量先安排自己，避免先读他人回答再声称独立。
+- `discussing`：找出会改变结论的事实、假设、标准或偏好差异，请最相关的人回应；需要时用拟定结论请相关当事人核对原意、条件和剩余阻碍，不是让全员再赞同一次。
+- `concluded`：已有足够依据完成本次目标，或依约交付有限结论。明确哪些已确认、哪些仍有分歧、缺什么证据；到限不等于达成共识。
+
+房间的 `named_followup`（点名追问）为 false 时，首轮照常拆题出题；之后各轮不给每位专家写针对性追问，统一请专家先读上一轮回答、回应不同意或需补充的观点、可 @ 彼此提问。需要引导方向时用自己的主持说明表达，不改写成逐人点名。用户开启智能调度时，这类衔接可能已由程序代你完成（对话中有“智能调度”记录），你被唤醒时多半是需要收束、跑偏、卡住或处理用户留言。
+
+追问应说明真正需要弄清的争点及材料入口，给专家自主质疑前提、发现遗漏和改变观点的空间，不预设答案或固定逐项答题格式。
+
+意见相同不等于事实已验证，意见不同也不必投票决定。核对会改变结论的数字、出处与适用条件，区分实测、外部声称、估计和建议。误述原意时请原作者澄清；另一人的赞同不能代替当事人确认。保留少数意见及其影响，不为了收束抹去限制，也不为凑轮次制造争论。重复立场时缩小争点或补有区分力的证据，仍无法判断就明确保留未决。
+
+## 首次接手
+
+网页新建只要求话题名称与用户原文，目标、背景和讨论边界留给主持人。首次接手时若这些字段为空，先读用户原文与已知材料补全，用 `room update ROOM --goal-file ... --background-file ... --boundaries-file ... --as 本人`（凭据方式遵循参与技能）一次保存，再安排专家。只有歧义会改变讨论方向时才向用户确认。
+
+## 上限与到限
+
+轮次由程序按专家发言量统计并判定到限（`limits.segment_rounds` / `round_cap`），不要用自己的计划结构推算；暂停、准备与收束期间不计时。到限后讨论结束、房间回到自由协作，用 `room limits ROOM --check --as 本人`（凭据方式遵循参与技能）处理：
+
+- 返回后房间已回到自由协作，本次执行随之换代，停止即可；之后用户的未点名留言照常交给你处理。用户要总结时，按“收束”一节写出最终 `moderation`。
+- 目标提前完成时，先保存有原文依据的结论、state 与简报，再 `room conclusion` 取得 `revision`，用 `room limits ROOM --done --conclusion <revision> --as 本人` 通知程序（未带、过期或有未处理留言、state 落后都会被拒绝）：讨论结束，房间回到自由协作。
+
+## 保存进度
+
+当判断、争点、下一步或阶段发生变化时，用一次 `state set ROOM --body-file ... --until ... --brief-file ... --as 本人` 同时保存：
+
+- state：足够恢复判断的依据与原文编号、已处理内容、未决问题和下一步意图。
+- 简报：让用户迅速了解当前结论、关键分歧和为什么接下来这样安排；不复述执行日志。
+
+`--until` 只覆盖实际已读材料。下一安排尚未创建时写成意图，实际编号与状态由服务端安排记录提供；恢复时两者对照，不为补写同一个编号再做一轮状态维护。无变化不写，已在当前上下文的材料不反复全文读取。保存失败先核对，不能一边失去接续依据一边继续派发。
+
+最终总结按议题组织结论、不同意见、重要条件与未验证影响，不强制固定栏目。用户要求独立报告时再调用仓库的 discuss-report，报告不表示建议已获采纳。
+
+## 停止
+
+等待回答或一次回复结束不是整场结束。用户叫停、已暂停/收束或时间用尽时停止新增安排；自动任务的失效与失败遵循参与技能，手动模式清理本话题的原生任务。恢复须有明确继续指令。向用户报告结论或暂停点，以及影响协作的真实障碍，不索要全员启停回执。

package/.agents/skills/discuss-host/references/manual.md

@@ -65,7 +65,7 @@
 | 当前情况 | 主持人处理 |
 | --- | --- |
 | 已暂停、收束或用户叫停 | 停止推进并清理本次任务，不继续联系专家。 |
-| 达到讨论上限 | 按主技能执行到限处理，返回暂停就停止并清理，等待用户决定追加轮次或结束。 |
+| 达到讨论上限 | 按主技能执行到限处理，讨论结束、房间回到自由协作后停止并清理自己的定时任务。 |
 | 有尚未处理的回答或用户新留言 | 读原文、核对关联，结合讨论进展和待回应的 @ 决定下一安排、必要复核或收束。 |
 | 正等待在线专家 | 按已选方式推进：主持人负责则检查浏览器中的送达和回答；用户手动协助则核对用户提供的送达信息与完整原文，不自行接管网页。完整取得后留档并继续。 |
 | 正等待本地专家 | 未完成接入则交付启动文本；已运行则等待，不反复联系或重建任务。 |