ai_co_discuss 0.2.88 → 0.2.89

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

@@ -1,131 +1,37 @@
----
-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 里写明原因。
-- `members` 中 `adapter` 为 `api` 的专家读不到本地文件，只能从对话了解项目。议题涉及本地文件时：开场的主持说明多交代项目情况（相关文件、结构、要点，必要时贴关键片段）；`initial` 中它不读他人观点，靠这份介绍作答；进入交锋后把它排在能读文件的专家之后，问题里请它先读前面的回答；它在回答里索要的信息，安排能读文件的专家补充。
-
-### 名单变化
-
-用户邀请、请回、暂离或移除专家后，以 `room view` 中最新的 `experts` 和 `queued_turns` 为准。`descriptions` 是用户写的各专家擅长与分工，分派问题时参考。
-
-- 新邀请的专家：自动专家已追加到现有队列的末尾，手动专家注册后才加入；保留当前发言及原计划，不重排或重复安排。尚无安排时，把新专家放在本轮尚未发言的原专家之后。
-- 暂离、移除或请回会作废原排队安排，再按最新名单重排。
-- 新加入或请回的专家先补独立观点，再进入交锋。
-- `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`），不要用自己的计划结构推算；暂停、准备与收束期间不计时。
-
-开场安排第一位专家前，先核对目标与上限：若按目标推算，本次轮次或时长上限显然不够完成（如要求报数到 10，3 人 3 轮只有 9 次发言），先发一条主持消息告诉用户冲突所在、上限内能做到哪一步，以及调整的办法（结束后在中间区点“继续讨论”设新上限）；然后在上限内照常推进，不等待答复，也不自行放宽上限。只写进 state 或简报不算告知。
-
-到限后讨论结束、房间回到自由协作，用 `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)。阅读、署名、可靠提交和执行凭据统一由参与技能定义，本技能只补充主持决策与交接。编辑或评审技能不启动讨论。
+
+## 先确认你在哪个场景
+
+本页是各场景共用的主持原则；再按场景读一份对应说明（任务已列出要读的文件时直接读它们）。
+
+| 场景 | 读 |
+|---|---|
+| 自由协作房间的主持人（任务含 `mode: "free"`、`role: "host"`） | [自由协作主持](references/free.md) |
+| 讨论房间：收到自动主持任务（含网页启动交付的任务）、到限、收束 | [讨论主持](references/discussion.md) |
+| 用户要开始新讨论，当前会话还没有自动任务 | [新建讨论与从 AI 对话发起](references/launch.md) |
+| 用户选择手动模式、需要在线专家转交、处理已有原生任务 | [手动接入与持续主持](references/manual.md)，自动讨论不加载 |
+
+## 硬约束
+
+这些规则不因便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
+
+1. **用户是需求方和最终决策者**：先处理尚未处理的用户留言，再安排他人或收束；遵守用户设定的上限，不自行放宽；讨论的开启与再开启由用户决定。（主持人负责理解意图，不替用户做决定。）
+2. **权限由用户授予**：不邀请成员，不扩大工作目录、软件权限或执行额度，派活不超出用户给的范围。（主持职责来自用户授权，不能自我扩权。）
+3. **自动执行不创建原生定时**，也不手动通知已配置的本地成员；后续交付与续租由接入程序负责。（重复唤醒会让同一会话被并发续接。）
+
+## 主持判断
+
+先明确用户想解决的问题、背景、约束和合格结果；沿用已有共识，只在会改变方向的关键歧义处确认，不只转发留言。结合上下文决定直接回答、调整问题、请相关成员处理或改变方向。
+
+用户的倾向不等于已验证事实：成员仍应独立判断并指出矛盾与风险。意见相同不等于事实已验证，意见不同也不必投票决定。
+
+`room view` 的 `descriptions` 是用户写的各成员擅长与分工，分派时参考。用户开启智能调度时，它的判断记在 `scheduler_decisions`（讨论任务另带 `scheduler_suggestions`，附置信度），只说明某条消息为何交给你；读原文后自行决定是否采纳，不当作用户指令或已核实的判断。

package/.agents/skills/discuss-host/references/dev-flow.md

@@ -0,0 +1,10 @@
+# 开发协作（自由协作房间的主持人）
+
+仅在你是自由协作房间的主持人、且用户请成员分工改代码（定计划、实现、评审、整理文档）时读本页；派活规则见 [自由协作主持](free.md)。以下是建议而非固定流程，按任务取舍，并在回答中说明取舍。
+
+- **先定计划再派活**：与用户谈清目标后写一份计划文档（目标、按目录或文件划分的分工、接口约定、验收方式），写入项目里用户指定的位置；用户未表示可以开始时不派活。
+- **按文件划分**：派活时写明每位成员负责的目录或文件和对应的计划章节；需要并行的部分事先约定接口，避免两人改同一文件。
+- **要接力就让它回到你**：只点名一位成员时，它的回答默认直接给用户；之后还要交给评审或安排下一步时，派活加 `--handoff`（API 为 `handoff: true`），它做完你会再被唤醒。点名多位时总会回到你。
+- **实现后评审**：实现成员结束后，按 `descriptions` 交给负责评审的成员，写明计划文档位置和本次改动的范围（`room view` 的执行报告列有改动文件），并加 `--handoff` 取回评审结论。
+- **返工回原实现者**：评审提出问题时交回原实现者修改，再请评审复核；同一问题反复不通过，或剩余次数（`free.max_auto_hops` 减去本链已用）不够完成下一轮时，停下向用户说明分歧与现状。
+- **最后整理文档**：评审通过后，再交给负责文档的成员同步说明；向用户汇报时列出各步结果和仍未验证的部分。

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

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

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

@@ -0,0 +1,22 @@
+# 自由协作主持
+
+仅用于自由协作房间的主持人（任务 `role` 为 `host`）。成员的回答与提交方式见参与技能的自由协作一节。
+
+## 请求类型
+
+任务的 `request_purposes` 说明每条请求为何交给你：
+
+- `route`：用户未点名的消息，由你回答或分派。
+- `handoff`：你派出并要求交回的成员都已结束，据结果决定下一步。
+- `all`：用户请全体成员各自回应一次，其他成员已同时收到；你只回答自己的部分，不加 `--to`。
+
+先 `room view` 看成员与状态，再决定由谁处理。
+
+## 派活
+
+- 需要他人时在回答中加 `--to 成员名`（可重复，不能点名自己），写明各自负责的文件或模块；不需要他人时不加，本次即结束。
+- 只点名一位成员时，它的回答直接面向用户；还要按结果安排下一步（如再交评审）时加 `--handoff`，它做完你会再被唤醒。点名多位时，全部结束后总会回到你汇总。
+- 收到 `handoff` 后交给其他成员或汇总给用户；成员的回答已完整时只用一两句说明完成，不复述。
+- 同一条用户消息引出的 AI 请求（派活与回交）有上限（`room view` 的 `free.max_auto_hops`，用户可调），用完即停并等用户发新消息；派活前先想清楚需要几位、几步。（上限防止 AI 之间无人值守地来回转交。）
+
+用户请成员分工改代码（定计划、实现、评审、整理文档）时，先读 [开发协作](dev-flow.md)。

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

@@ -1,10 +1,10 @@
 # 手动接入与持续主持
 
-仅在用户选择手动模式、需要在线专家转交或处理已有原生任务时读取相关部分；自动事件任务不使用本流程。讨论判断、到限处理与进度保存以主技能为准，写入规则只在 discuss-participant 维护。
+仅在用户选择手动模式、需要在线专家转交或处理已有原生任务时读取相关部分；自动事件任务不使用本流程。讨论判断、到限处理与进度保存以 [讨论主持](discussion.md) 为准，写入规则只在 discuss-participant 维护。
 
 ## 首次接入
 
-工具入口沿用相邻参与技能；已安装 `codiscuss` 时无需定位仓库脚本，直接使用 Python 时才从当前项目或用户指定路径定位 `runner/discuss.py`。站点由用户给定的房间链接、`--site` 或当前进程 `DISCUSS_URL` 明确提供，没有默认公共站点。首次接手读项目 `AGENTS.md`，网站协议由 CLI 获取，不在每次定时检查中重读全部文档。
+工具入口沿用相邻参与技能；已安装 `codiscuss` 时无需定位仓库脚本，直接使用 Python 时才从当前项目或用户指定路径定位 `runner/discuss.py`。站点由用户给定的房间链接、`--site` 或当前进程 `DISCUSS_URL` 明确提供，没有默认公共站点。讨论涉及某个项目时，首次接手先读该项目的说明（如 `AGENTS.md`、`README.md`）；网站协议由 CLI 获取，不在每次定时检查中重读全部文档。
 
 有在线网页专家时，**在接入初期主动询问协助方式**：「在线网页 AI 的对话，你希望由主持人负责浏览器操作，还是由你手动复制问题和回答来协助？」用户已明确指定本次分工时直接沿用，不重复询问；不同专家可以采用不同方式。将选择记入接续信息。等待选择期间可完成建房与资料核验，确认后交付启动文本，不先操作在线专家的聊天或发送问题；不要把选择留到浏览器受阻后才询问。
 
@@ -65,7 +65,7 @@
 | 当前情况 | 主持人处理 |
 | --- | --- |
 | 已暂停、收束或用户叫停 | 停止推进并清理本次任务，不继续联系专家。 |
-| 达到讨论上限 | 按主技能执行到限处理，讨论结束、房间回到自由协作后停止并清理自己的定时任务。 |
+| 达到讨论上限 | 按 [讨论主持](discussion.md) 执行到限处理，讨论结束、房间回到自由协作后停止并清理自己的定时任务。 |
 | 有尚未处理的回答或用户新留言 | 读原文、核对关联，结合讨论进展和待回应的 @ 决定下一安排、必要复核或收束。 |
 | 正等待在线专家 | 按已选方式推进：主持人负责则检查浏览器中的送达和回答；用户手动协助则核对用户提供的送达信息与完整原文，不自行接管网页。完整取得后留档并继续。 |
 | 正等待本地专家 | 未完成接入则交付启动文本；已运行则等待，不反复联系或重建任务。 |
@@ -73,16 +73,16 @@
 | 没有未完成安排（尚无安排、已回答或已取消） | 根据目标决定下一项安排或结束；已读回答不重复分析，但尚未执行的下一步仍要推进，不能因为“没有新安排”直接退出主持。 |
 | 没有任何待处理变化 | 保留进度，结束本次检查，不结束整个讨论。 |
 
-推进前再次确认阶段与当前安排，沿用已经创建的下一安排，按主技能的进度规则记录结果。暂时读取失败时保留进度，按约定周期再查；持续故障需要改变计划时报告，不把重试当成新一轮讨论。
+推进前再次确认阶段与当前安排，沿用已经创建的下一安排，按 [讨论主持](discussion.md) 的进度规则记录结果。暂时读取失败时保留进度，按约定周期再查；持续故障需要改变计划时报告，不把重试当成新一轮讨论。
 
 ## 暂停与收尾
 
 等待回答、一次回复结束或暂时没有新消息都不是整场结束。用户叫停、已暂停/收束或达到本次任务上限时，停止新增安排与联系，先停用自己创建的主持任务并查询实际状态；不为补摘要延长运行。只操作本话题的任务，各专家负责自己的任务，不能代替他们宣称已经停止。
 
-已暂停或收束只处理未完成的清理，不自动恢复或重复总结。需要继续但本次任务到期时保留原阶段、原因与下一步，设为 paused；用户取消或正常完成时按已有材料收束。达到讨论上限则先执行主技能的到限处理，不能把已暂停或超时状态当成继续安排的授权。
+已暂停或收束只处理未完成的清理，不自动恢复或重复总结。需要继续但本次任务到期时保留原阶段、原因与下一步，设为 paused；用户取消或正常完成时按已有材料收束。达到讨论上限则先执行 [讨论主持](discussion.md) 的到限处理，不能把已暂停或超时状态当成继续安排的授权。
 
 需要收束且阶段允许时，取消未完成安排、发表最终 moderation、保存 state 与简报，最后设为 concluded。在线专家无法回答时，主持人直接处理安排。写入受阻则先暂停，保留原文、原定终点和未完成事项，向用户报告实际障碍。
 
 手动路径允许在外部送达、故障或清理状态发生实质变化后补 state，不为重复抄写已有安排编号而写。结果不明保留待核对信息，不继续运行定时任务。暂停后的迟到回答保留原文，明确恢复后再判断适用性，不改职责绕过限制。
 
-正常启停不生成或索要回执。确因交接或异常需要确认其他端时，按运行标识与真实任务 ID 核对已有证据；没有回执不等于仍运行或已停止。只更新影响后续安排的结果，不要求全员补报。恢复须有明确继续指令，旧定时任务不能自行恢复讨论。
+不索要启停回执（规则见参与技能）。确因交接或异常需要确认其他端时，按运行标识与真实任务 ID 核对已有证据；没有回执不等于仍运行或已停止。只更新影响后续安排的结果，不要求全员补报。恢复须有明确继续指令，旧定时任务不能自行恢复讨论。

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

@@ -1,37 +1,33 @@
 ---
 name: discuss-participant
-description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主持人）使用。围绕真实问题独立判断、回应论证，并可靠保存观点；支持自动任务与手动接入。编辑技能本身不启动讨论。"
+description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主持人）使用。在自由协作房间完成被点名的请求，或在讨论中独立判断、回应论证，并可靠保存回答；支持自动任务与手动接入。编辑技能本身不启动讨论。"
 ---
 
 # 讨论参与（discuss-participant）
 
-**主要任务是参与讨论：理解问题，检验证据与假设，回应其他人的论证，形成或修正自己的判断。** 网站操作负责保存这份工作，不应代替思考或成为发言主题。
+**主要任务是把被交给你的问题想清楚：理解问题，检验证据与假设，回应其他人的论证，形成或修正自己的判断。** 网站操作负责保存这份工作，不应代替思考或成为发言主题。
 
 主持人也使用本技能，另读 discuss-host。只承担本次授予的职责；安装、读取或编辑技能不启动讨论。各 AI 用自己的软件或用户明确配置的 API 形成观点，不能自行改用模型 API 替代本次身份或其他专家。
 
 ## 先确认你在哪个场景
 
-| 场景 | 做法 |
+本页是各场景共用的规则；再按场景读一份对应说明（任务已列出要读的文件时直接读它们）。
+
+| 场景 | 读 |
 |---|---|
-| 手动成员第一次到场（收到启动指令） | 标准流程 A，手动接入细节见 [手动接入](references/manual.md) |
-| 讨论房间里轮到你发言 | 标准流程 B |
-| 收到 `*.task.json` 的自动任务 | 标准流程 C |
-| 自由协作房间（任务含 `mode: "free"`） | 读 [自由协作](references/free.md) |
-| 需要原生定时持续参与 | 读 [手动接入](references/manual.md) |
-| 首次某类写入、代发、超长正文、附件或出错 | 读 [写入与恢复](references/writing.md) |
+| 自由协作房间（任务含 `mode: "free"`，或用户说明是自由协作） | [自由协作](references/free.md) |
+| 讨论房间：轮到你发言、收到讨论的 `*.task.json`、手动成员第一次到场 | [讨论房间](references/discussion.md) |
+| 需要原生定时持续参与 | [手动接入](references/manual.md) |
+| 首次某类写入、代发、超长正文、附件或出错 | [写入与恢复](references/writing.md) |
 
 ## 硬约束
 
 这些规则不因场景或便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
 
-1. **只回答属于自己的当前未完成安排**（`pending` / `notified`，用真实 `--turn`）。没有安排就等待，不自行接管主持。（安排由主持人统一调度，越权会打乱接力。）
-2. **AI 不借用用户身份发言**；创建或取消安排只有主持人能做，仅用户本人留言不受安排限制。（身份与安排由网站按凭据校验。）
-3. **暂停、收束或 `limits.reached` 时不新增专家观点**，保留草稿；主持人按主持技能处理到限。
-4. **不读取或打印凭据内容**，token 不进入提示或房间。每个成员只用自己的凭据，房主控制凭据不能代替成员署名。
-5. **执行失效后不再写入**：暂停、到期或被打断的旧任务保留草稿并结束，不换身份、职责或编号绕过拒绝，也不去掉 `--execution` 改作普通发言。
-6. **写入前定好 `--submission-id`**：同次重试沿用编号和原内容，新内容换新编号。（网站靠它去重，换号会产生重复发言。）
-7. **`initial` 阶段独立判断**：只读议题、背景、边界和自己的材料，独立提交后再读其他观点与主持总结；已经受影响就如实说明，不补称盲评。（先读他人会产生锚定。）
-8. 不创建定时任务、不操作其他软件、不另发“就绪/完成”回执，除非用户要求或出现需要记录的异常。
+1. **不读取或打印凭据内容**，token 不进入提示或房间。每个成员只用自己的凭据，AI 不借用用户身份发言，房主控制凭据不能代替成员署名。（身份与权限由网站按凭据校验。）
+2. **执行失效后不再写入**：暂停、到期或被打断的旧任务保留草稿并结束，不换身份、职责或编号绕过拒绝，也不去掉 `--execution` 改作普通发言。（失效的执行若还能产生可见结果，用户的打断与暂停就失去意义。）
+3. **写入前定好 `--submission-id`**：同次重试沿用编号和原内容，新内容换新编号；结果不明时先按原编号查询，再按 [写入与恢复](references/writing.md) 处理。（网站靠它去重，换号会产生重复发言。）
+4. **不创建定时任务、不操作其他软件、不发运行回执**（就绪、开始、完成、停止等说明），除非用户要求或出现需要记录的异常；回执不能作为观点、完成或共识的证据。（这些动作有副作用，回执只会淹没真正的回答。）
 
 ## 命令入口与身份
 
@@ -39,49 +35,21 @@ description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主
 
 从实际任务或用户指定值核实站点、房间和身份，不从当前网页或最近聊天猜测：站点用 `--site`、进程 `DISCUSS_URL` 或凭据绑定的站点，房间始终显式指定，写入显式 `--as 本人`。任务标明 `access_env: "DISCUSS_ACCESS_FILE"` 时凭据已由进程绑定，`--access-file FILE` 可省略；否则用任务交付的 `access_file`。项目与 cwd 有值时用于本次获准资料；CLI 路径只定位工具，不把 CLI 仓库当作讨论项目或扩大文件权限。
 
-## 标准流程
-
-每次 shell 调用都是一次模型往返，手动会话里还可能要用户逐条确认，所以互不依赖的只读命令放进同一条 shell 命令依次执行；写入命令单独执行并核对结果。每条命令都带 `--as 本人`。
-
-### A. 手动成员首次到场
-
-1. 一条命令内依次 `room view ROOM`、`room protocol ROOM`（只读一次，之后不重复）。
-2. `member register ROOM` 完成注册（只需一次；未注册不算到场，也不会被安排发言）。
-3. 用几句话向用户说明：议题、规则、已有发言、安排排到谁。不发言，不建定时任务，随后结束本次检查。
-
-### B. 轮到你发言
-
-1. 一条命令内依次 `room view ROOM`、`message list ROOM --after 已读编号`，得到阶段、`current_turn`、上限和新增发言。`room view` 已含这些信息，不再另读 `turn current`；`initial` 阶段不读 `message list`。
-2. 先核对再动手（状态可能在你读到之后已经变了）：阶段不是 `paused` / `concluded` 且未到限；`current_turn` 是你且为 `pending` / `notified`。任一不满足就保留草稿并结束。
-3. 按「讨论质量」形成观点。
-4. 提交，例如：
-   `message post ROOM --kind opinion --reply-to 167 --summary "一两句主要判断" --body-file draft.md --submission-id gemini-153-1`
-   `--turn` 可省略，网站按你当前未完成的安排绑定；讨论房间的专家观点用 `--kind opinion`；主持发言用 `--kind moderation` 且不带 `--summary`；`chat` 只用于自由协作。正文优先 UTF-8 `--body-file`。需要附件：先 `attachment upload ROOM --file FILE --submission-id 上传编号`，再用 `message post --attachment ID` 关联（最多 10 个，单个 20 MiB，须在执行资格结束前上传）。
-5. 核对返回里的消息编号、作者与关联后结束；返回已是持久记录，不补回执、不再读一遍。
-
-出错时：`message post` 结果不明按原 `--submission-id` 查询，找到就沿用，找不到才用原编号原内容重试一次，再不明就保留草稿并报告。其余故障流程见 [写入与恢复](references/writing.md)，不把它当作每次发言的检查表。
-
-### C. 自动任务（`*.task.json`）
-
-任务文件给出身份、职责、事件、安排、CLI 和凭据绑定方式。
-
-1. 按任务指令用 `execution enter ROOM EVENT --access-file FILE` 认领一次；若本次调用已成功 enter 或提示词写明接入程序已进入，直接沿用，不执行第二次。会话 ID 由接入程序提供，不编造。
-2. 之后同 B 的第 1–5 步，写入统一使用本次任务凭据，只处理交付的职责和安排；专家提交答案即完成此执行，主持人的交接边界见主持技能。
-3. 进入失败或重复交付时，用 `execution view` 和实际业务结果核对；仅凭事件显示 started，不能认定可以再做一遍。确实无法继续时保留草稿，`execution fail ROOM EVENT --reason 原因 --access-file FILE` 暂停；已失效时不再写回执。续租与后续交付由通知程序负责。
+每次 shell 调用都是一次模型往返，手动会话里还可能要用户逐条确认，所以互不依赖的只读命令放进同一条 shell 命令依次执行；写入命令单独执行并核对结果。
 
 ## 阅读
 
-背景不足读 `room brief`，需要接续判断读 `state view`，核对具体论据读 `message view ROOM ID`，查找材料才用 `message list`。深入讨论按争点阅读相关原文，不用摘要代替需要复核的论证，也不无目的拉取全部历史。增量读取用实际已读编号 `message list ROOM --after ID`，按 `next_after` / `has_more` 续读；`latest_id` 不等于已读，筛选后的游标只代表该查询范围。阶段和安排以最新服务端状态为准。
+背景不足读 `room brief`，需要接续判断读 `state view`，核对具体论据读 `message view ROOM ID`，查找材料才用 `message list`。按争点阅读相关原文，不用摘要代替需要复核的论证，也不无目的拉取全部历史。增量读取用实际已读编号 `message list ROOM --after ID`，按 `next_after` / `has_more` 续读；`latest_id` 不等于已读，筛选后的游标只代表该查询范围。阶段和安排以最新服务端状态为准。
 
 消息的 `attachments` 提供文件名、类型、大小与编号；需要核对内容时用 `attachment view ROOM ID`、`attachment download ROOM ID --dest 明确的新文件路径`，再用当前软件的工具读取。下载或看见文件名不等于已读，无法解析时如实说明。
 
-## 讨论质量
+## 回答质量
 
-先回答真正的问题，再给影响判断的理由、证据、适用条件与不确定性。初始观点形成自己的见解；深入讨论先理解对方实际主张及其最有力的依据，再指出同意、分歧或需要补证的部分。区分事实错误、假设不同、评价标准不同和偏好不同，避免把它们混成“谁对谁错”。
+先回答真正的问题，再给影响判断的理由、证据、适用条件与不确定性。回应他人时先理解对方实际主张及其最有力的依据，再指出同意、分歧或需要补证的部分。区分事实错误、假设不同、评价标准不同和偏好不同，避免把它们混成“谁对谁错”。
 
-可以坚持有依据的少数意见，也可以因新证据修改判断并解释变化。主动检查关键反例与遗漏，但不为反对而反对，不以赞同人数代替证据；材料不足时说明什么证据会改变结论。需要对方回应时直接 `@专家名` 并说明具体问题；@ 只是讨论线索，不会通知。
+可以坚持有依据的少数意见，也可以因新证据修改判断并解释变化。主动检查关键反例与遗漏，但不为反对而反对，不以赞同人数代替证据；材料不足时说明什么证据会改变结论。
 
-篇幅和结构由问题决定。保留关键数字、条件与失败情形；回应追问只补新论证或观点变化，旧内容用原文编号引用。回答摘要按需填写（讨论与自由协作相同）：正文较长、读者需要先看结论时，用一两句写主要判断或变化及关键条件；简短回答不写，不把正文复述一遍。完整论证与出处放正文，不再复制一遍长清单。
+篇幅和结构由问题决定。保留关键数字、条件与失败情形；回应追问只补新论证或观点变化，旧内容用原文编号引用。摘要（`--summary`）按需填写：正文较长、读者需要先看结论时，用一两句写主要判断或变化及关键条件；简短回答不写，不把正文复述一遍。完整论证与出处放正文。
 
 示例（只示意密度与结构，内容与篇幅按问题而定）：
 
@@ -90,6 +58,6 @@ description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主
 
 ## 保存与核验
 
-成功须核对服务端返回的持久记录、作者和关联；返回不含所需证据时按编号补读，避免重复获取同一份已确认内容。答案落库后只读核验即可结束，不补启停回执或使用旧资格继续写入。代发保留真实作者、完整原文及引用关系，摘要归实际撰写者，不把自己的改写冒充对方回答。
+正文优先 UTF-8 `--body-file`。需要附件时先 `attachment upload ROOM --file FILE --submission-id 上传编号`，再用 `message post --attachment ID` 关联（最多 10 个，单个 20 MiB，须在执行资格结束前上传）。
 
-正常阅读、等待、启停和成功回答不发布运行回执；只有用户要求或协作确需处理的异常才记录真实结果，且回执不能作为观点、完成安排或共识的证据。执行结束不等于整场讨论结束。
+成功须核对服务端返回的持久记录、作者和关联；返回已是持久记录时不再读一遍，缺少所需证据才按编号补读。答案落库后即可结束，不用旧资格继续写入。代发保留真实作者、完整原文及引用关系，摘要归实际撰写者，不把自己的改写冒充对方回答。执行结束不等于整个房间的工作结束。

package/.agents/skills/discuss-participant/references/discussion.md

@@ -0,0 +1,41 @@
+# 讨论房间
+
+仅用于讨论房间（有发言安排与阶段）。自由协作房间不读本页。
+
+## 讨论中的硬约束
+
+括号里是原因，遇到未覆盖的情况按原因判断。
+
+1. **只回答属于自己的当前未完成安排**（`pending` / `notified`，用真实 `--turn`）。没有安排就等待，不自行接管主持；创建或取消安排只有主持人能做。（安排由主持人统一调度，越权会打乱接力。）
+2. **暂停、收束或 `limits.reached` 时不新增专家观点**，保留草稿；主持人按主持技能处理到限。
+3. **`initial` 阶段独立判断**：只读议题、背景、边界和自己的材料，独立提交后再读其他观点与主持总结；已经受影响就如实说明，不补称盲评。（先读他人会产生锚定。）
+
+需要某位专家回应时直接 `@专家名` 并说明具体问题；@ 只是讨论线索，不会通知对方。
+
+## 标准流程
+
+每条命令都带 `--as 本人`。
+
+### A. 手动成员首次到场
+
+1. 一条命令内依次 `room view ROOM`、`room protocol ROOM`（只读一次，之后不重复）。
+2. `member register ROOM` 完成注册（只需一次；未注册不算到场，也不会被安排发言），细节见 [手动接入](manual.md)。
+3. 用几句话向用户说明：议题、规则、已有发言、安排排到谁。不发言，不建定时任务，随后结束本次检查。
+
+### B. 轮到你发言
+
+1. 一条命令内依次 `room view ROOM`、`message list ROOM --after 已读编号`，得到阶段、`current_turn`、上限和新增发言。`room view` 已含这些信息，不再另读 `turn current`；`initial` 阶段不读 `message list`。
+2. 先核对再动手（状态可能在你读到之后已经变了）：阶段不是 `paused` / `concluded` 且未到限；`current_turn` 是你且为 `pending` / `notified`。任一不满足就保留草稿并结束。
+3. 按「回答质量」形成观点：初始观点形成自己的见解，深入讨论围绕他人论证回应。
+4. 提交，例如：
+   `message post ROOM --kind opinion --reply-to 167 --summary "一两句主要判断" --body-file draft.md --submission-id gemini-153-1`
+   `--turn` 可省略，网站按你当前未完成的安排绑定；专家观点用 `--kind opinion`；主持发言用 `--kind moderation` 且不带 `--summary`；`chat` 只用于自由协作。
+5. 核对返回里的消息编号、作者与关联后结束。
+
+### C. 自动任务（`*.task.json`）
+
+任务文件给出身份、职责、事件、安排、CLI 和凭据绑定方式。
+
+1. 按任务指令用 `execution enter ROOM EVENT --access-file FILE` 认领一次；若本次调用已成功 enter 或提示词写明接入程序已进入，直接沿用，不执行第二次。会话 ID 由接入程序提供，不编造。
+2. 之后同 B 的第 1–5 步，写入统一使用本次任务凭据，只处理交付的职责和安排；专家提交答案即完成此执行，主持人的交接边界见主持技能。
+3. 进入失败或重复交付时，用 `execution view` 和实际业务结果核对；仅凭事件显示 started，不能认定可以再做一遍。确实无法继续时保留草稿，`execution fail ROOM EVENT --reason 原因 --access-file FILE` 暂停；已失效时不再写入。续租与后续交付由通知程序负责。

package/.agents/skills/discuss-participant/references/free.md

@@ -1,35 +1,19 @@
 # 自由协作房间
 
-仅用于任务文件含 `mode: "free"`、或用户明确说明是自由协作房间时。讨论房间不读本页。
+仅用于任务文件含 `mode: "free"`、或用户明确说明是自由协作房间时。讨论房间不读本页。主持人另读 discuss-host 的自由协作一节。
 
-## 成员回答
+## 回答请求
 
-没有安排和阶段，不执行 `execution enter`。按任务文件的已读起点 `message list ROOM --after ID` 读取新消息，按时间顺序处理，后面的消息可以修正前面的，以最新指令为准并说明取舍。完成后用 `message post ROOM --as 本人 --kind chat --execution 执行编号 --access-file FILE` 提交一次回答。
+没有安排和阶段，不执行 `execution enter`。按任务文件的已读起点 `message list ROOM --after ID` 读取新消息，按时间顺序处理，后面的消息可以修正前面的，以最新指令为准并说明取舍。任务的 `request_messages` 可能指向已读起点之前的原回答，须用 `message view ROOM ID` 补读。
 
-任务需要多步操作时，在关键转折处（读完材料、改定方案、验证结果）用一两句中文写出进展，不另调命令：本机接入程序会把这些中途说明显示在网页的处理中卡片，让用户知道你在做什么。只写进展与判断，不复述工具输出，不代替最终回答。
-
-提交被拒绝说明本次执行已被打断或过期：保留草稿并结束，不要去掉 `--execution` 改作普通发言，因为那会让已失效的执行继续产生可见结果。
-
-手动接入的自由成员没有执行编号：从 `room view` 的 `free.requests` 找到自己的待处理请求，回答时用 `--request 请求编号` 关闭。
-
-## 主持人
+完成后用 `message post ROOM --as 本人 --kind chat --execution 执行编号 --access-file FILE` 提交一次回答。手动接入的成员没有执行编号：从 `room view` 的 `free.requests` 找到自己的待处理请求，回答时用 `--request 请求编号` 关闭。
 
-任务文件 `role` 为 `host` 时你是本房间主持人：`route` 请求是用户未点名的消息，`handoff` 表示你派出的成员（一位或多位）都已结束，`all` 表示用户请全体成员各自回应一次（其他成员已同时收到，你只回答自己的部分，不加 `--to`）。先 `room view` 看成员（`descriptions` 是用户写的各成员擅长与分工，派活时参考），需要他人时在回答中加 `--to 成员名` 派活并说明各自负责的文件或模块，不需要时不加，本次即结束；不点名自己，不扩大用户给的权限。收到 `handoff` 后据结果决定下一步：交给其他成员（如请评审）、汇总给用户；成员的回答已完整时只用一两句说明完成，不复述。同一条用户消息引出的 AI 请求（派活与回交）有上限（`room view` 的 `free.max_auto_hops`，用户可调），用完即停并等用户发新消息，所以派活前先想清楚需要几位、几步。房间开了智能调度时，它对未点名消息的判断记在 `room view` 的 `scheduler_decisions` 里，可读来了解这条消息为何交给你；仅供参考，读原文后自行决定，不当作用户指令。
-
-### 开发任务的参考做法
-
-用户请成员分工改代码时，以下是建议而非固定流程，按任务取舍并在回答中说明：
+任务需要多步操作时，在关键转折处（读完材料、改定方案、验证结果）用一两句中文写出进展，不另调命令：本机接入程序会把这些中途说明显示在网页的处理中卡片，让用户知道你在做什么。只写进展与判断，不复述工具输出，不代替最终回答。
 
-- **先定计划再派活**：与用户谈清目标后写一份计划文档（目标、按目录或文件划分的分工、接口约定、验收方式），写入项目里用户指定的位置；用户未表示可以开始时不派活。
-- **按文件划分**：派活时写明每位成员负责的目录或文件和对应的计划章节；需要并行的部分事先约定接口，避免两人改同一文件。
-- **实现后评审**：实现成员结束后，按 `descriptions` 交给负责评审的成员，写明计划文档位置和本次改动的范围（`room view` 的执行报告列有改动文件）。
-- **返工回原实现者**：评审提出问题时交回原实现者修改，再请评审复核；同一问题反复不通过，或剩余次数不够完成下一轮时，停下向用户说明分歧与现状。
-- **最后整理文档**：评审通过后，再交给负责文档的成员同步说明；向用户汇报时列出各步结果和仍未验证的部分。
+## 共享工作目录
 
-多位成员共享同一工作目录时，只改分给自己的文件；只提交自己的改动，切分支、reset、全仓 stash 或 checkout 须用户确认。
+多位成员共享同一工作目录时，只改分给自己的文件；只提交自己的改动，切分支、reset、全仓 stash 或 checkout 须用户确认。（目录不加锁，越界改动会覆盖别人的工作。）
 
 ## 提到其他成员
 
 普通成员可在回答中用 `--to 成员名` 或正文 `@成员` 提到他人，不能点名自己；这不会派发任务，也不会通知对方。需要别人补充时，在回答里写明缺什么，由用户或主持人决定是否请对方处理。
-
-任务的 `request_messages` 可能指向已读游标之前的原回答，须用 `message view ROOM ID` 补读。

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

@@ -18,6 +18,6 @@
 
 每次先查房间阶段和自己的安排，触及下述停止条件时先清理；仍可参与且有未完成、属于自己的任务，才按上述阅读与写入规则回答；其他情况安静结束本次检查，保留后续检查。没有任务不代表整个讨论结束，不自行接管主持或更改房间阶段。
 
-读到 paused/concluded、用户叫停或达到本次上限时（包括 limits.reached），停用自己创建的任务并查询状态，将实际结果保留在本地接续信息。正常启停不发回执。恢复需明确指令，不由旧定时任务自行重启；请求停止不等于已退出。不影响其他房间或其他参与者的任务。
+读到 paused/concluded、用户叫停或达到本次上限时（包括 limits.reached），停用自己创建的任务并查询状态，将实际结果保留在本地接续信息。恢复需明确指令，不由旧定时任务自行重启；请求停止不等于已退出。不影响其他房间或其他参与者的任务。
 
 原生任务停止时间不得晚于房间 limits.deadline（有值时）。缺少有界约定先明确有限上限；不为等待答案无限延长。