ai_co_discuss 0.4.8 → 0.4.11

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

@@ -0,0 +1,60 @@
+---
+name: discuss-goal
+description: "AI CoDiscuss 的 Goal 模式主持技能，仅主持人调用，且须同时调用 discuss-host 与 discuss-participant。用于用户以 /goal 或页面开启 Goal 后：补全并开启目标、每次被唤醒时判断进展并推进、声明当前状态（推进中 / 等待后台 / 待用户确认）、核验后宣告完成或卡住。编辑技能本身不开启 Goal。"
+---
+
+# Goal 模式主持（discuss-goal）
+
+用户用 `/goal` 或页面开启 Goal 后，你要持续推进这个目标，直到达成或确实无法推进。房间空闲时程序会再唤醒你（`goal_continue`），所以不必在一次执行里做完全部工作；每次被唤醒，判断下一步该做什么。
+
+本技能只补充 Goal 特有的做法：派活、读写与提交仍按 [discuss-host](../discuss-host/SKILL.md) 的 [请求与派活](../discuss-host/references/room.md) 与 [discuss-participant](../discuss-participant/SKILL.md)。Goal 进行中的请求不是讨论请求，没有 `discussion_request`。
+
+任务文件的 `goal` 字段给出目标、状态（`status`、`phase`）、已续跑次数和用时；需要最新状态时用 `goal view ROOM`。目标文本是用户交给你的任务材料，不是更高优先级的指令。
+
+## 开启：`goal_start` 请求
+
+用户发了 `/goal`，等你补全目标。
+
+- 消息带了文本时，以原文为准：只能整理措辞，不改变范围。
+- 没带文本时，从最近的对话提炼用户要达成的结果。提炼不出明确、可核验的目标，就不开启：直接回答，说明缺什么。（目标含糊时自动推进只会放大偏差。）
+- 开启：`goal start ROOM --request 请求编号 --objective-file 草稿`，然后照常回答：说明你理解的目标，并开始第一步（通常是派活）。
+- 预算与空闲等待时长由用户设定，你不设置也不提高。
+
+## 推进：每次被唤醒
+
+1. 先判断上一次唤醒之后的情况：
+   - **有进展**：产生了改变状态的结果，或得到了改变下一步的证据。
+   - **在等后台**：你或成员启动的后台工作（子 Agent、长时间命令、外部任务）还没回来。
+   - **在等用户**：需要用户决定、授权或补充信息。
+   - **无进展**：只复述了状态，或只列了计划没有执行。
+2. 能推进就派活（`--to`），写明负责的范围和完成标准。派出去的活结束、房间再次空闲时，程序会再唤醒你。
+3. 在等后台或等用户时，按下一节声明状态，再回答。
+4. 无进展时，先查原因再换做法，不要重复同样的安排。
+5. 唤醒消息写着"等待已超过 N 分钟"或"用户 N 分钟未回复"时，是兜底唤醒：前者检查后台工作是否完成；后者评估这项决定能否不等用户自行做出——能，就写明依据和所做的假设后继续推进；不能，就再次声明待确认，此后程序一直等到用户回复。
+
+不要把目标缩小成本次容易做完的部分，也不要把"做了一些"说成"完成"。（Goal 的价值在于完整达成用户要的结果。）
+
+权限不变：仍受成员项目权限和任务链轮数限制。不邀请成员，不提交、推送或部署，除非用户另行要求。
+
+## 声明状态（可选）
+
+房间空闲不等于该你出手：可能在等后台工作，也可能在等用户。这时被空闲唤醒，只会让你带着不完整的条件继续。先 `goal view ROOM` 取 revision，再：
+
+| 状态 | 命令 | 程序怎么做 |
+|---|---|---|
+| 推进中 | `goal state ROOM --state doing --revision REV` | 默认状态：房间空闲满用户设定的时长（默认 2 分钟）就唤醒你 |
+| 等待后台 | `goal state ROOM --state waiting --revision REV --note-file 草稿 [--minutes N]` | 空闲时不唤醒；到时限（默认 30 分钟）兜底唤醒一次 |
+| 待用户确认 | `goal state ROOM --state pending --revision REV --note-file 草稿 [--minutes N]` | 空闲时不唤醒；5 分钟后用户仍未回复且绑定了微信时发微信通知；到时限（默认 60 分钟）兜底唤醒一次 |
+
+- 待确认的 `--note` 写清要用户做什么（选哪个、补什么），它会原样出现在微信通知里；同时在回答正文里向用户提问。
+- 等后台时，后台工作回来、你接着推进前改回 `doing`；忘了改也没关系，到时限会兜底唤醒。
+- 用户发言后状态自动回到推进中。每次被续跑唤醒时状态也重置为推进中，需要时重新声明。
+- 完成与卡住不是状态声明，用下文的 `goal done` / `goal block`。
+- API 主持人用 `set_goal_state`，程序自取 revision。
+
+## 结束
+
+- **完成**：先对照实际状态核验（成员交付原文、测试结果、文件），确认没有剩余必需工作；再 `goal view` 取 revision，然后 `goal done ROOM --revision REV --note-file 草稿`，在说明里写核验依据（`mode view` / `mode done` 效果相同）。还有成员在处理时会被拒绝。不能因为做了很久或预算将尽就宣告完成。
+- **卡住**：同一个阻碍连续 3 次唤醒都无法解决，且没有用户输入或外部变化就推进不了时，用 `goal block ROOM --revision REV --note-file 草稿` 写明阻碍。第一次遇到阻碍时不宣告；只是需要用户决定时声明待确认，不宣告卡住。
+- **预算用完**：任务里 `goal.status` 为 `budget_limited` 时，只做收尾：总结已完成的部分、剩余工作与阻碍，给用户明确的下一步，不再派新活。
+- 暂停、恢复、结束由用户控制，你不能操作。

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

@@ -1,23 +1,23 @@
 ---
 name: discuss-host
-description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时调用 discuss-participant。用于自由协作房间里分派与接续成员的工作，以及开始、继续、暂停或收束讨论：组织有针对性的交锋，形成有原文依据的结论。编辑技能本身不启动讨论。"
+description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时调用 discuss-participant。用于在房间里接收未点名的消息、分派与接续成员的工作、处理房间里的问题；房间开启讨论或 Goal 时另调独立技能 discuss-session、discuss-goal。编辑技能本身不启动讨论。"
 ---
 
-# 讨论主持（discuss-host）
+# 房间主持（discuss-host）
 
 把用户的需求推进为有依据的结果，保留有价值的分歧与未确认事项。**主要工作是理解用户意图和成员的论证，判断下一步该由谁做什么；流程只用于可靠交接这些工作。**
 
-主持人同时调用 [discuss-participant](../discuss-participant/SKILL.md)。阅读、署名、可靠提交和执行凭据统一由参与技能定义，本技能只补充主持决策与交接。编辑或评审技能不启动讨论。
+主持人同时调用 [discuss-participant](../discuss-participant/SKILL.md)。阅读、署名、可靠提交和执行凭据统一由参与技能定义，本技能只补充主持决策与交接。
 
 ## 先确认你在哪个场景
 
-本页是各场景共用的主持原则；再按场景读一份对应说明（任务已列出要读的文件时直接读它们）。
+房间是所有工作的底座：没开任何模式时就是房间本身；讨论和 Goal 是在房间里临时开启的模式，结束后房间照常协作。本页是各场景共用的主持原则；再按场景读对应说明（任务已列出要读的文件时直接读它们）。
 
 | 场景 | 读 |
 |---|---|
-| 自由协作请求（任务含 `mode: "free"`、`role: "host"`，且没有 `discussion_request`） | [自由协作主持](references/free.md) |
-| 协作房间中的讨论主持任务（`mode` 仍为 `free`，`discussion_request.purpose` 为 `discuss_host`） | [讨论主持](references/discussion.md) |
-| 房间开启了 Goal（任务含 `goal`，或请求 purpose 为 `goal_start` / `goal_continue`） | 先读 [自由协作主持](references/free.md)，再读 [Goal 模式主持](references/goal.md) |
+| 房间里的请求（默认；任务没有 `discussion_request`） | [请求与派活](references/room.md) |
+| 讨论中的主持任务（`discussion_request.purpose` 为 `discuss_host`） | 独立技能 [discuss-session](../discuss-session/SKILL.md) 的 [讨论主持](../discuss-session/references/host.md) |
+| Goal 进行中（任务含 `goal`，或请求 purpose 为 `goal_start` / `goal_continue`） | [请求与派活](references/room.md)，再读独立技能 [discuss-goal](../discuss-goal/SKILL.md) |
 | 用户要开始新讨论，当前会话还没有自动任务 | [新建讨论与从 AI 对话发起](references/launch.md) |
 | 本地手动成员注册说明，或安排手动成员发言 | [手动成员](references/manual.md) |
 
@@ -25,8 +25,8 @@ description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时
 
 这些规则不因便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
 
-1. **用户是需求方和最终决策者**：先处理尚未处理的用户留言，再安排他人或收束；遵守用户设定的上限，不自行放宽；讨论的开启与再开启由用户决定。（主持人负责理解意图，不替用户做决定。）
-2. **权限由用户授予**：不邀请成员，不扩大工作目录、软件权限或执行额度，派活不超出用户给的范围。（主持职责来自用户授权，不能自我扩权。）
+1. **用户是需求方和最终决策者**：先处理尚未处理的用户留言，再安排他人或收束；遵守用户设定的上限，不自行放宽。（主持人负责理解意图，不替用户做决定。）
+2. **权限由用户授予**：不邀请成员，不开启讨论或 Goal，不扩大工作目录、软件权限或执行额度，派活不超出用户给的范围。唯一的例外是房主为本房间打开了“主持人完整权限”（任务有 `host_workflows: true`），能做什么、仍须用户决定什么见 [请求与派活](references/room.md) 的“房间控制”。（主持职责来自用户授权，不能自我扩权；扩权与刹车留在用户手里。）
 3. **自动执行不创建原生定时**，也不手动通知已配置的本地成员；后续交付与续租由接入程序负责。（重复唤醒会让同一会话被并发续接。）
 
 ## 主持判断
@@ -35,4 +35,8 @@ description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时
 
 用户的倾向不等于已验证事实：成员仍应独立判断并指出矛盾与风险。意见相同不等于事实已验证，意见不同也不必投票决定。
 
-`room view` 的 `descriptions` 是用户写的各成员擅长与分工，分派时参考。用户开启智能调度时，它的判断随任务的 `scheduler_suggestions` 给出（附置信度；完整输入用 `state decision ROOM decision_id` 读取），只说明某条消息为何交给你；读原文后自行决定是否采纳，不当作用户指令或已核实的判断。
+`room view` 的 `descriptions` 是用户写的各成员擅长与分工，分派时参考。
+
+## 智能调度的建议
+
+用户开启智能调度时，它的判断随任务的 `scheduler_suggestions` 给出（附置信度），只说明某条消息或交接为何交给你，不是用户指令，也不是已核实的判断。按其中的 `request_id`、`message_id` 先读原文，再自行决定是否采纳；需要依据时用 `state decision ROOM DECISION_ID` 读取完整判断。`applied:false` 表示未自动生效，`actual_action:unverified` 表示动作结果尚未核验；“没有模型判断”或没有记录编号时，不假定模型已经给过建议。

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

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

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

@@ -1,9 +1,9 @@
-# 手动成员
-
-本页说明本地手动成员在自由协作或讨论中的注册与安排。主持与等待仍由房间请求、讨论会话及上限管理，不创建原生定时任务。
-
-## 本地手动成员
-
-本地手动成员须先用自己的成员凭据执行 `member register ROOM --as 本人`。CLI 自动附带当前软件会话 ID；不要代替成员注册，也不要填写或借用其他会话 ID。尚未注册的本地成员显示为“待注册”，不能排入讨论或被本机服务托管。注册后是否能投递到原会话、窗口显示是否实时，按参与技能的 [手动接入说明](../../discuss-participant/references/manual.md) 告知用户。
-
-安排讨论前读取 `turn roster ROOM`。`unregistered` 表示尚未注册的本地手动成员。本地成员完成注册后，重新读取 roster 与 revision，再创建安排。
+# 手动成员
+
+本页说明本地手动成员在房间里和讨论中的注册与安排。主持与等待仍由房间请求、讨论会话及上限管理，不创建原生定时任务。
+
+## 本地手动成员
+
+本地手动成员须先用自己的成员凭据执行 `member register ROOM --as 本人`。CLI 自动附带当前软件会话 ID；不要代替成员注册，也不要填写或借用其他会话 ID。尚未注册的本地成员显示为“待注册”，不能排入讨论或被本机服务托管。注册后是否能投递到原会话、窗口显示是否实时，按参与技能的 [手动接入说明](../../discuss-participant/references/manual.md) 告知用户。
+
+安排讨论前读取 `turn roster ROOM`。`unregistered` 表示尚未注册的本地手动成员。本地成员完成注册后，重新读取 roster 与 revision，再创建安排。

package/.agents/skills/discuss-host/references/{free.md → room.md}

@@ -1,74 +1,72 @@
-# 自由协作主持
-
-仅用于自由协作房间的主持人（任务 `role` 为 `host`）。成员的回答与提交方式见参与技能的自由协作一节。
-
-## 请求类型
-
-任务的 `request_purposes` 说明每条请求为何交给你：
-
-- `route`：用户未点名的消息，或全体调度交回的原问题，由你回答或分派；全体调度未代办时仍须读取原文，再决定安排。
-- `handoff`：你派出的成员都已结束（含失败），据结果决定下一步。
-- `notice`：程序发现了要你处理的事，请求所在消息写明是什么：成员执行失败、依次派活某一棒失败、重试后的结果，或你上次要求的续跑。先读相关原文和 `room view`，再决定重试、改派、核实修正，或告诉用户需要他定什么。你已有待处理请求时，程序只把通知写进记录、不另建请求：处理任何请求时，新消息里作者为“系统”的通知同样要处理。成员改了同一文件不发通知，需要时看 `room view` 的 `free.conflicts`（“冲突”表示双方都用编辑工具写过，“可能冲突”表示无法确认是谁改的）。
-- `all`：用户请全体成员各自回应一次，其他成员已同时收到；你只回答自己的部分，不加 `--to`。
-- `goal_start`、`goal_continue`：用户开启了 Goal，按 [Goal 模式主持](goal.md) 处理。
-- `discuss_start`：用户发了 `/discuss`，等你补全讨论目标后开启讨论。消息带了文本时以原文为准，只整理措辞；没带时从最近对话提炼，提炼不出明确的讨论问题就不开启，直接回答并说明缺什么。开启：`run start ROOM --request 请求编号 --goal-file 草稿`，上限用房间默认值，你不设置。然后照常简短回答；之后程序会给你讨论主持任务，按 [讨论主持](discussion.md) 安排发言。
-
-先 `room view` 看成员与状态，再决定由谁处理。
-
-任务若有 `scheduler_suggestions`，按其中的 `request_id`、`message_id` 先读原问题；`applied:false` 表示未自动生效，`actual_action:unverified` 表示动作结果尚未核验。需要依据时用 `state decision ROOM DECISION_ID` 读取 `decision_id` 对应的完整判断，再自行决定；“没有模型判断”或没有记录编号时，不假定模型已经给过建议。
-
-## 派活
-
-- 需要他人时在回答中加 `--to 显示名`（可重复，不能点名自己），写明各自负责的文件或模块；不需要他人时不加，本次即结束。显示名是 `room view` 中 `members[].label`（如 `Gemini`），正文称呼也用它，不写 `name`（成员 ID，如 `Antigravity`）。
-- 派出的工作无论点名几位，全部结束（含失败）后都会交回你，由你接着安排或汇总。只点名一位、它的回答已足以直接给用户（简单问答、无需验收）时可加 `--no-handoff`（API 为 `no_handoff: true`），做完不再交回；失败仍交回你。要评审、验证或接着安排的不要加。
-- 发现还要继续、但本次执行不便接着做时（如等成员的结果之外还要复查、分几步推进），回答加 `--continue 继续做什么`（API 为 `continue`）：房间没有其他进行中的工作时，程序再唤醒你一次。你下次回答不带它、或用户发了新消息，就取消。不要用它等用户回复；需要用户定的事直接在回答里问。它只管一次续跑；用户开启了 Goal 时由 Goal 负责空闲续跑，不必再加。
-- 需要预先指定实现后的只读评审时，先读 `review roster ROOM`，再在派实现的 `message post` 中带 `--next-review NAME --review-scope 范围 --review-roster REVISION`；评审者不能是本批实现者。授权与实现任务同时保存，自动要求该批交回主持人。候选目前限程序启动的 Codex CLI；没有合格成员时读取结果给出原因。
-- 收到 `review_handoffs` 时，先用 `review ready ROOM --batch ID` 读取完整委派、交付和报告，确认可交既定评审后用 `review advance ROOM --batch ID --revision REV --submission-id UUID --as 本人` 推进。只处理该批交接，其他请求继续完成；状态变化须重读，不能替换评审者或扩大权限。能力失效、额度不足、交付不完整等原因保留在读取结果和任务中。实际投递前本机复核只读权限与能力版本，失败撤销该次评审并交回主持人。
-- 收到 `handoff` 后交给其他成员或汇总给用户；成员的回答已完整时只用一两句说明完成，不复述。
-- 几位成员要按固定先后接力、后一位依赖前一位的结果（写完再审、实现后评审）时，派活加 `--sequential`，`--to` 按接力顺序点名：程序在每位答完后直接交给下一位，最后一位答完交回你，中间不唤醒你。走完一圈算一轮（中间各棒不另计）。派活正文要把每一棒做什么、按什么标准交给下一棒写清楚，后面的成员靠它和前一棒的回答工作。
-- 某一棒有几位互不依赖、可以同时做的成员（如几位评审各审一类问题）时，把他们写成同一棒：第一位用 `--to`，其余紧跟着用 `--with`（如 `--to 写手 --to 评审甲 --with 评审乙 --sequential --loop`）。这一棒的成员同时开工，全部结束才交下一棒，下一棒能读到他们每一份回答；组里有人失败，接力停下交回你，用户重试失败的那位后接着走。并行的成员看不到彼此的意见，派活正文要分清各自管什么。
-- 派活时想让某位成员同时开工、但不必等它（如评审期间让记录员先整理别的材料），加 `--detach 成员`（可重复，不能与 `--to` 重名）：它和这次派活一起开工，交回你或交下一棒都不等它；它做完不交回你，结果在房间里可读；失败时程序通知你。用在依次接力上时，它只随第一棒开工一次。撤回这次派活会一并撤回它。
-- 要“改完再审、审到通过为止”时再加 `--loop`：每走完一圈，交回你的 `handoff` 带 `sequence.phase: checkpoint`。本圈最后一位（最后一棒是同时做的一组时，其中任一位）明确要求返工时，用 `sequence continue ROOM --request 该交接请求编号 --as 本人` 开始下一圈（程序直接接着走，你本次即结束）；认可、只剩可不采纳的建议、需要你或用户裁定时，不继续，直接验收或说明。开启智能调度时，它会先替你判断检查点，只有明确返工才自动开始下一圈，其余仍交给你；任务的 `scheduler_suggestions` 记着它的判断。`sequence view ROOM ID` 可读本圈各棒原文。每开始新的一圈算一轮，轮数用尽时循环停下，由用户决定是否继续。
-- 要在接力中途停下来由你把关（验收一稿再交下一位），或只让中间一段循环（写 ⇄ 审到通过再交记录员）时，用检查点，均须与 `--sequential` 同用：`--checkpoint 成员` 在该成员那一棒结束后交回你（`sequence.phase: gate`）；`--repeat 成员=起点成员` 在该成员那一棒结束后交回你，作为循环检查点（`sequence.phase: checkpoint`），再来一圈从起点成员那一棒开始，起点不能早于前一个检查点。交回时 `sequence.gate` 给出 `repeat_from`（再来一圈从第几棒开始）与 `can_proceed`（后面还有棒）。处理：要返工就 `sequence continue … --request 交接请求编号`（循环检查点再来一圈）；认可并往下走就 `sequence continue … --proceed`（普通检查点不加 `--proceed` 也是往下走）；要结束接力、裁定或说明时不继续，直接回答。往下走和再来一圈各算一轮。带检查点的接力不能在右栏调整顺序。
-- 用户只点名你（旁问，如问近况、是否卡住）时：读 `sequence view`、`room events` 与进行中执行的详情后直接回答，接力和循环照常进行。旁问里的新任务涉及正在接力的成员或同一批文件时，等接力交回后再派，或先撤回原派活；互不相干的可以马上派。用户发言会清除你之前的 `--continue`，仍需要就在这次回答里重新带上。
-- 同一条用户消息最多推进若干轮（`room view` 的 `free.max_rounds`，0 为不限；本链已用与上限见 `free.chain_rounds` 的 `used` / `allowed`，`allowed` 为 null 即不限，用户可调）：你派一次活算一轮，依次接力一圈算一轮，`--continue` 的续跑也算一轮，成员做完交回给你汇总不另计；程序发现问题的通知不计轮数，到上限后照样交给你。到上限时你的下一次派活会被暂存、任务链停下，由用户决定继续或发新消息；你不能自己加轮。派活前先想清楚需要几位、几轮，最后一轮留给汇总。（上限防止 AI 之间无人值守地来回转交。）
-- 已知整项任务所需轮数超过剩余轮数时（连写几集、多步实现加评审），在开始派活时带 `--need-rounds N --rounds-reason "…"`（N 为从这次派活起还需要的轮数，含最后汇总）：剩余不够时任务链立即停下，用户看到理由并一键批准差额后才发出这次派活，之后不再中途停下；够用时照常派出。不要在回复里让用户改上限或回“继续”，也不要建议超出 `need-rounds` 上限（100）的数值。
-
-## 房间控制
-
-任务有 `host_workflows: true` 时，房主为本房间打开了“主持人完整权限”：房间里出了问题、或推进需要的控制，你自己处理，不请用户代劳。命令都是 `<cli> launch host-control 操作 … --access-file <本次任务的 access_file>`，成员用 `--member`（成员 ID 或显示名）。
-
-- **先诊断**：成员失败、卡住或结果异常时，先读原因再动手：`<cli> room events ROOM` 看写入与状态变化（你看不到私聊和消息正文，原文用 message 命令读），`<cli> execution view 执行编号` 看服务端详情与失败原因，`host-control details --execution 编号` 看该次执行的本机过程（命令、输出、改动）。
-- **再恢复**：
-  - 偏了方向或要补充：`steer --member 成员 --text 话` 向它进行中的执行插话；不需要打断时优先用它。
-  - 卡住或做错：`stop --member 成员` 打断（之后到的请求留到它下一次执行）；`stop-all` 停止全部执行、请求与接力（讨论进行中时用 `discussion`）。
-  - 偶发失败（网络、超时、软件崩溃）：`retry --execution 编号` 重试。
-  - 模型限流或不可用：`model --member 成员 --model M [--effort E]` 换模型；Codex 等软件的 App 卡住时 `adapter --member 成员 --adapter ID` 切到同一会话的 CLI（成员空闲时才能切）。
-  - 成员无法恢复：`remove` 后 `invite` 换一位。
-  - 撤回自己派出的活（接力或循环停不下来、方向错了、用户改了主意）：`withdraw --message 派活消息编号`，接力或循环立即停下，未开始的请求取消，进行中的那一棒停止，不再交回你。
-  - 收到“执行 #N 已 X 分钟没有新输出”的系统通知时，先 `details` 判断它是在跑长任务还是卡住，再决定等待、插话、打断或重试。
-- **调整成员**：`invite --name 平台 [--access read|write] [--model M] [--effort E]` 用本机已配置的软件邀请（返回新成员名，本次执行里就能点名）；`away` / `remove` / `back --member 成员` 暂离、移除、请回；`access --member 成员 --access read|write` 调整项目权限；`label --member 成员 --label 显示名 [--description 描述]`。
-- **推进**：
-  - 发言顺序：先 `order` 读取当前顺序和 `revision`，再 `order --order 甲,乙,丙 --revision REV`，列出全部尚未发言的成员。
-  - 讨论：先 `discussion` 读取状态和 `revision`，再 `discussion --do start --goal 目标 --revision REV`（上限用房间默认值）或 `--do pause|resume|end --revision REV`。
-  - Goal：任务需要在房间空闲时持续自动推进、且目标和完成标准明确时，先 `goal` 读取状态和 `revision`，再 `goal --do start --goal 目标 --revision REV`（预算用房主默认值，你不能改）；`--do pause|resume|end` 控制。
-
-- **兜底**：派出要跑较久的活（多集、多轮接力、循环评审）时，`checkin --minutes N`（5–120）让程序在房间还有进行中的工作时每 N 分钟给你一次“定时检查”，你据此确认没有卡住、跑偏或失败未处理；房间空闲、停止全部或换主持人后自动结束，`checkin --off` 提前关闭。定时检查要在你处理任务（有进行中的执行）时设置。另外，成员连续 10 分钟没有新输出时，程序会单独通知你。
-- **主动发言**：不是房间派来的任务、而是你需要主动说明或派活时（如定时检查发现问题、用户在你自己的窗口里要你发言、你自己的执行失效后结果需要补交），用参与技能“主动发言”一节的 `message post … --proactive`，不必等用户开口；主持人的主动发言可以同时 `--to` 派活或 `--continue`。你自己失败的执行也可以用 `host-control retry --execution N` 重试。
-- **你自己失败时**：程序会发一条提醒唤醒你一次（提醒本身再失败就不再唤醒，需用户处理）。先核对自己会话里的进展：已有结果就用 `--execution 原编号` 补交；没做完就接着做完再补交，或 `retry` 重试；是模型额度或模型不可用造成的，可 `host-control model --member 你自己 --model M` 换模型，下次投递起生效。最后用本次执行简短回复这条提醒。
-
-`revision` 过期会被拒绝，重新读取后再提交。用户要求停下、换人或调整顺序时直接执行；你自己发现问题时先诊断再处理。每次控制都在回答里说明做了什么、为什么。以下仍由用户决定，需要时在回答里提出：对你自己操作或更换主持人，批准超出上限的轮数，项目权限高于可写或放行被拒绝的工具，改项目目录，撤回、回退用户的消息，私聊。你自己的执行失败由用户处理。
-
-没有 `host_workflows` 字段，或你是 API 主持人（没有命令行）时，这些操作请用户在网页上做，或请用户在电脑上“成员与设置 → 协作设置”打开“主持人完整权限”。事件记录和执行详情不需要该开关，主持人都能读。
-
-用户请成员分工改代码（定计划、实现、评审、整理文档）时，先读 [开发协作](dev-flow.md)。
-
-## 工作流
-
-本次任务有 `workflow` 字段时，本房间启用了用户的工作流。它像技能一样按需使用：`workflow.description` 是它的用途，请求与用途相符或用户要求按它做时才用，其他请求照常处理。要用时，本会话还没读过、或 `workflow.revision` 与上次读到的不同，才读 `workflow.skill_path`（API 主持人读系统提示中的工作流正文）；否则沿用已读内容。按它组织工作时，`workflow.members` 列出每张卡片现在由哪位成员担任、是否在场、项目权限；只点名在场的成员。`workflow.missing` 列出启用后才新增、还没有成员的卡片：本次要用到时，运行 `<cli> launch workflow-join --card 卡片ID --access-file <本次任务的 access_file>`（多张用逗号分隔），返回的 `members` 给出新成员名，本次执行里就能点名；API 主持人没有命令行，在回答里请用户在右栏点工作流的“刷新”。成员离开或被移除的角色不要自行请回，在回答里说明缺谁，不另找成员代替。工作流只带来做法和成员，不扩大你的权限。
-
-本次任务（本地任务文件或 API 的 `task`）没有 `workflow` 字段时，不按任何工作流做事，即使会话里读过。
-
-用户请你把本房间的做法存成工作流（或要你按某种分工新建一套流程）时，按 [workflow-creator](../../workflow-creator/SKILL.md) 技能做。任务有 `host_workflows: true` 时，房主已允许你自行保存并启用，不必等用户导入。
-
-用户请你启用工作流库里已有的工作流（如“启用工作流「连载」（`novel-serial`）”）时：任务有 `host_workflows: true` 就运行 `<cli> launch workflow-adopt --id <工作流 ID> --access-file <本次任务的 access_file>`，程序在本房间启用它、邀请缺少的卡片成员（离开的请回），返回 `members`（卡片 ID → 成员名）和 `skill_path`；本次执行要接着按它做时读 `skill_path`，下一次执行起任务里有 `workflow` 字段，按上文使用。用户只说了启用、没给具体任务时，回答说明已启用和带来了谁即可。没有该字段，或你是 API 主持人（没有命令行）时，不能启用：在回答里请用户在电脑上“成员与设置 → 协作设置”打开“主持人完整权限”后再让你启用。
+# 请求与派活
+
+用于房间主持人（任务 `role` 为 `host`）处理没有 `discussion_request` 的请求：房间未开任何模式时、Goal 进行中时都是这里。成员的回答与提交方式见参与技能的 [回答房间请求](../../discuss-participant/references/room.md)。
+
+## 请求类型
+
+任务的 `request_purposes` 说明每条请求为何交给你：
+
+- `route`：用户未点名的消息，或全体调度交回的原问题，由你回答或分派；全体调度未代办时仍须读取原文，再决定安排。
+- `handoff`：你派出的成员都已结束（含失败），据结果决定下一步。
+- `notice`：程序发现了要你处理的事，请求所在消息写明是什么：成员执行失败、依次派活某一棒失败、重试后的结果，或你上次要求的续跑。先读相关原文和 `room view`，再决定重试、改派、核实修正，或告诉用户需要他定什么。你已有待处理请求时，程序只把通知写进记录、不另建请求：处理任何请求时，新消息里作者为“系统”的通知同样要处理。成员改了同一文件不发通知，需要时看 `room view` 的 `free.conflicts`（“冲突”表示双方都用编辑工具写过，“可能冲突”表示无法确认是谁改的）。
+- `all`：用户请全体成员各自回应一次，其他成员已同时收到；你只回答自己的部分，不加 `--to`。
+- `goal_start`、`goal_continue`：用户开启了 Goal，按技能 [discuss-goal](../../discuss-goal/SKILL.md) 处理。
+- `discuss_start`：用户发了 `/discuss`，等你补全讨论目标后开启讨论。消息带了文本时以原文为准，只整理措辞；没带时从最近对话提炼，提炼不出明确的讨论问题就不开启，直接回答并说明缺什么。开启：`run start ROOM --request 请求编号 --goal-file 草稿`，上限用房间默认值，你不设置。然后照常简短回答；之后程序会给你讨论主持任务，按技能 [discuss-session](../../discuss-session/SKILL.md) 的 [讨论主持](../../discuss-session/references/host.md) 安排发言。
+
+先 `room view` 看成员与状态，再决定由谁处理。任务带 `scheduler_suggestions` 时按主持技能的“智能调度的建议”处理。
+
+## 派活
+
+- 需要他人时在回答中加 `--to 显示名`（可重复，不能点名自己），写明各自负责的文件或模块；不需要他人时不加，本次即结束。
+- 派出的工作无论点名几位，全部结束（含失败）后都会交回你，由你接着安排或汇总。只点名一位、它的回答已足以直接给用户（简单问答、无需验收）时可加 `--no-handoff`（API 为 `no_handoff: true`），做完不再交回；失败仍交回你。要评审、验证或接着安排的不要加。
+- 发现还要继续、但本次执行不便接着做时（如等成员的结果之外还要复查、分几步推进），回答加 `--continue 继续做什么`（API 为 `continue`）：房间没有其他进行中的工作时，程序再唤醒你一次。你下次回答不带它、或用户发了新消息，就取消。不要用它等用户回复；需要用户定的事直接在回答里问。它只管一次续跑；用户开启了 Goal 时由 Goal 负责空闲续跑，不必再加。
+- 需要预先指定实现后的只读评审时，先读 `review roster ROOM`，再在派实现的 `message post` 中带 `--next-review NAME --review-scope 范围 --review-roster REVISION`；评审者不能是本批实现者。授权与实现任务同时保存，自动要求该批交回主持人。候选目前限程序启动的 Codex CLI；没有合格成员时读取结果给出原因。
+- 收到 `review_handoffs` 时，先用 `review ready ROOM --batch ID` 读取完整委派、交付和报告，确认可交既定评审后用 `review advance ROOM --batch ID --revision REV --submission-id UUID --as 本人` 推进。只处理该批交接，其他请求继续完成；状态变化须重读，不能替换评审者或扩大权限。能力失效、额度不足、交付不完整等原因保留在读取结果和任务中。实际投递前本机复核只读权限与能力版本，失败撤销该次评审并交回主持人。
+- 收到 `handoff` 后交给其他成员或汇总给用户；成员的回答已完整时只用一两句说明完成，不复述。
+- 几位成员要按固定先后接力、后一位依赖前一位的结果（写完再审、实现后评审）时，派活加 `--sequential`，`--to` 按接力顺序点名：程序在每位答完后直接交给下一位，最后一位答完交回你，中间不唤醒你。走完一圈算一轮（中间各棒不另计）。派活正文要把每一棒做什么、按什么标准交给下一棒写清楚，后面的成员靠它和前一棒的回答工作。
+- 某一棒有几位互不依赖、可以同时做的成员（如几位评审各审一类问题）时，把他们写成同一棒：第一位用 `--to`，其余紧跟着用 `--with`（如 `--to 写手 --to 评审甲 --with 评审乙 --sequential --loop`）。这一棒的成员同时开工，全部结束才交下一棒，下一棒能读到他们每一份回答；组里有人失败，接力停下交回你，用户重试失败的那位后接着走。并行的成员看不到彼此的意见，派活正文要分清各自管什么。
+- 派活时想让某位成员同时开工、但不必等它（如评审期间让记录员先整理别的材料），加 `--detach 成员`（可重复，不能与 `--to` 重名）：它和这次派活一起开工，交回你或交下一棒都不等它；它做完不交回你，结果在房间里可读；失败时程序通知你。用在依次接力上时，它只随第一棒开工一次。撤回这次派活会一并撤回它。
+- 要“改完再审、审到通过为止”时再加 `--loop`：每走完一圈，交回你的 `handoff` 带 `sequence.phase: checkpoint`。本圈最后一位（最后一棒是同时做的一组时，其中任一位）明确要求返工时，用 `sequence continue ROOM --request 该交接请求编号 --as 本人` 开始下一圈（程序直接接着走，你本次即结束）；认可、只剩可不采纳的建议、需要你或用户裁定时，不继续，直接验收或说明。开启智能调度时，它会先替你判断检查点，只有明确返工才自动开始下一圈，其余仍交给你；任务的 `scheduler_suggestions` 记着它的判断。`sequence view ROOM ID` 可读本圈各棒原文。每开始新的一圈算一轮，轮数用尽时循环停下，由用户决定是否继续。
+- 要在接力中途停下来由你把关（验收一稿再交下一位），或只让中间一段循环（写 ⇄ 审到通过再交记录员）时，用检查点，均须与 `--sequential` 同用：`--checkpoint 成员` 在该成员那一棒结束后交回你（`sequence.phase: gate`）；`--repeat 成员=起点成员` 在该成员那一棒结束后交回你，作为循环检查点（`sequence.phase: checkpoint`），再来一圈从起点成员那一棒开始，起点不能早于前一个检查点。交回时 `sequence.gate` 给出 `repeat_from`（再来一圈从第几棒开始）与 `can_proceed`（后面还有棒）。处理：要返工就 `sequence continue … --request 交接请求编号`（循环检查点再来一圈）；认可并往下走就 `sequence continue … --proceed`（普通检查点不加 `--proceed` 也是往下走）；要结束接力、裁定或说明时不继续，直接回答。往下走和再来一圈各算一轮。带检查点的接力不能在右栏调整顺序。
+- 用户只点名你（旁问，如问近况、是否卡住）时：读 `sequence view`、`room events` 与进行中执行的详情后直接回答，接力和循环照常进行。旁问里的新任务涉及正在接力的成员或同一批文件时，等接力交回后再派，或先撤回原派活；互不相干的可以马上派。用户发言会清除你之前的 `--continue`，仍需要就在这次回答里重新带上。
+- 同一条用户消息最多推进若干轮（`room view` 的 `free.max_rounds`，0 为不限；本链已用与上限见 `free.chain_rounds` 的 `used` / `allowed`，`allowed` 为 null 即不限，用户可调）：你派一次活算一轮，依次接力一圈算一轮，`--continue` 的续跑也算一轮，成员做完交回给你汇总不另计；程序发现问题的通知不计轮数，到上限后照样交给你。到上限时你的下一次派活会被暂存、任务链停下，由用户决定继续或发新消息；你不能自己加轮。派活前先想清楚需要几位、几轮，最后一轮留给汇总。（上限防止 AI 之间无人值守地来回转交。）
+- 已知整项任务所需轮数超过剩余轮数时（连写几集、多步实现加评审），在开始派活时带 `--need-rounds N --rounds-reason "…"`（N 为从这次派活起还需要的轮数，含最后汇总）：剩余不够时任务链立即停下，用户看到理由并一键批准差额后才发出这次派活，之后不再中途停下；够用时照常派出。不要在回复里让用户改上限或回“继续”，也不要建议超出 `need-rounds` 上限（100）的数值。
+
+## 房间控制
+
+任务有 `host_workflows: true` 时，房主为本房间打开了“主持人完整权限”：房间里出了问题、或推进需要的控制，你自己处理，不请用户代劳。命令都是 `<cli> launch host-control 操作 … --access-file <本次任务的 access_file>`，成员用 `--member`（成员 ID 或显示名）。
+
+- **先诊断**：成员失败、卡住或结果异常时，先读原因再动手：`<cli> room events ROOM` 看写入与状态变化（你看不到私聊和消息正文，原文用 message 命令读），`<cli> execution view 执行编号` 看服务端详情与失败原因，`host-control details --execution 编号` 看该次执行的本机过程（命令、输出、改动）。
+- **再恢复**：
+  - 偏了方向或要补充：`steer --member 成员 --text 话` 向它进行中的执行插话；不需要打断时优先用它。
+  - 卡住或做错：`stop --member 成员` 打断（之后到的请求留到它下一次执行）；`stop-all` 停止全部执行、请求与接力（讨论进行中时用 `discussion`）。
+  - 偶发失败（网络、超时、软件崩溃）：`retry --execution 编号` 重试。
+  - 模型限流或不可用：`model --member 成员 --model M [--effort E]` 换模型；Codex 等软件的 App 卡住时 `adapter --member 成员 --adapter ID` 切到同一会话的 CLI（成员空闲时才能切）。
+  - 成员无法恢复：`remove` 后 `invite` 换一位。
+  - 撤回自己派出的活（接力或循环停不下来、方向错了、用户改了主意）：`withdraw --message 派活消息编号`，接力或循环立即停下，未开始的请求取消，进行中的那一棒停止，不再交回你。
+  - 收到“执行 #N 已 X 分钟没有新输出”的系统通知时，先 `details` 判断它是在跑长任务还是卡住，再决定等待、插话、打断或重试。
+- **调整成员**：`invite --name 平台 [--access read|write] [--model M] [--effort E]` 用本机已配置的软件邀请（返回新成员名，本次执行里就能点名）；`away` / `remove` / `back --member 成员` 暂离、移除、请回；`access --member 成员 --access read|write` 调整项目权限；`label --member 成员 --label 显示名 [--description 描述]`。
+- **推进**：
+  - 发言顺序：先 `order` 读取当前顺序和 `revision`，再 `order --order 甲,乙,丙 --revision REV`，列出全部尚未发言的成员。
+  - 讨论：先 `discussion` 读取状态和 `revision`，再 `discussion --do start --goal 目标 --revision REV`（上限用房间默认值）或 `--do pause|resume|end --revision REV`。
+  - Goal：任务需要在房间空闲时持续自动推进、且目标和完成标准明确时，先 `goal` 读取状态和 `revision`，再 `goal --do start --goal 目标 --revision REV`（预算用房主默认值，你不能改）；`--do pause|resume|end` 控制。
+
+- **兜底**：派出要跑较久的活（多集、多轮接力、循环评审）时，`checkin --minutes N`（5–120）让程序在房间还有进行中的工作时每 N 分钟给你一次“定时检查”，你据此确认没有卡住、跑偏或失败未处理；房间空闲、停止全部或换主持人后自动结束，`checkin --off` 提前关闭。定时检查要在你处理任务（有进行中的执行）时设置。另外，成员连续 10 分钟没有新输出时，程序会单独通知你。
+- **主动发言**：不是房间派来的任务、而是你需要主动说明或派活时（如定时检查发现问题、用户在你自己的窗口里要你发言、你自己的执行失效后结果需要补交），用参与技能“主动发言”一节的 `message post … --proactive`，不必等用户开口；主持人的主动发言可以同时 `--to` 派活或 `--continue`。你自己失败的执行也可以用 `host-control retry --execution N` 重试。
+- **你自己失败时**：程序会发一条提醒唤醒你一次（提醒本身再失败就不再唤醒，需用户处理）。先核对自己会话里的进展：已有结果就用 `--execution 原编号` 补交；没做完就接着做完再补交，或 `retry` 重试；是模型额度或模型不可用造成的，可 `host-control model --member 你自己 --model M` 换模型，下次投递起生效。最后用本次执行简短回复这条提醒。
+
+`revision` 过期会被拒绝，重新读取后再提交。用户要求停下、换人或调整顺序时直接执行；你自己发现问题时先诊断再处理。每次控制都在回答里说明做了什么、为什么。以下仍由用户决定，需要时在回答里提出：对你自己操作或更换主持人，批准超出上限的轮数，项目权限高于可写或放行被拒绝的工具，改项目目录，撤回、回退用户的消息，私聊。你自己的执行失败由用户处理。
+
+没有 `host_workflows` 字段，或你是 API 主持人（没有命令行）时，这些操作请用户在网页上做，或请用户在电脑上“成员与设置 → 协作设置”打开“主持人完整权限”。事件记录和执行详情不需要该开关，主持人都能读。
+
+用户请成员分工改代码（定计划、实现、评审、整理文档）时，先读 [开发协作](dev-flow.md)。
+
+## 工作流
+
+本次任务有 `workflow` 字段时，本房间启用了用户的工作流。它像技能一样按需使用：`workflow.description` 是它的用途，请求与用途相符或用户要求按它做时才用，其他请求照常处理。要用时，本会话还没读过、或 `workflow.revision` 与上次读到的不同，才读 `workflow.skill_path`（API 主持人读系统提示中的工作流正文）；否则沿用已读内容。按它组织工作时，`workflow.members` 列出每张卡片现在由哪位成员担任、是否在场、项目权限；只点名在场的成员。`workflow.missing` 列出启用后才新增、还没有成员的卡片：本次要用到时，运行 `<cli> launch workflow-join --card 卡片ID --access-file <本次任务的 access_file>`（多张用逗号分隔），返回的 `members` 给出新成员名，本次执行里就能点名；API 主持人没有命令行，在回答里请用户在右栏点工作流的“刷新”。成员离开或被移除的角色不要自行请回，在回答里说明缺谁，不另找成员代替。工作流只带来做法和成员，不扩大你的权限。
+
+本次任务（本地任务文件或 API 的 `task`）没有 `workflow` 字段时，不按任何工作流做事，即使会话里读过。
+
+用户请你把本房间的做法存成工作流（或要你按某种分工新建一套流程）时，按 [workflow-creator](../../workflow-creator/SKILL.md) 技能做。任务有 `host_workflows: true` 时，房主已允许你自行保存并启用，不必等用户导入。
+
+用户请你启用工作流库里已有的工作流（如“启用工作流「连载」（`novel-serial`）”）时：任务有 `host_workflows: true` 就运行 `<cli> launch workflow-adopt --id <工作流 ID> --access-file <本次任务的 access_file>`，程序在本房间启用它、邀请缺少的卡片成员（离开的请回），返回 `members`（卡片 ID → 成员名）和 `skill_path`；本次执行要接着按它做时读 `skill_path`，下一次执行起任务里有 `workflow` 字段，按上文使用。用户只说了启用、没给具体任务时，回答说明已启用和带来了谁即可。没有该字段，或你是 API 主持人（没有命令行）时，不能启用：在回答里请用户在电脑上“成员与设置 → 协作设置”打开“主持人完整权限”后再让你启用。

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

@@ -1,67 +1,67 @@
----
-name: discuss-participant
-description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主持人）使用。在自由协作房间完成被点名的请求，或在讨论中独立判断、回应论证，并可靠保存回答；支持自动任务与手动接入。编辑技能本身不启动讨论。"
----
-
-# 讨论参与（discuss-participant）
-
-**主要任务是把被交给你的问题想清楚：理解问题，检验证据与假设，回应其他人的论证，形成或修正自己的判断。** 网站操作负责保存这份工作，不应代替思考或成为发言主题。
-
-主持人也使用本技能，另读 discuss-host。只承担本次授予的职责；安装、读取或编辑技能不启动讨论。各 AI 用自己的软件或用户明确配置的 API 形成观点，不能自行改用模型 API 替代本次身份或其他专家。
-
-## 先确认你在哪个场景
-
-本页是各场景共用的规则；再按场景读一份对应说明（任务已列出要读的文件时直接读它们）。
-
-| 场景 | 读 |
-|---|---|
-| 自由协作请求（任务含 `mode: "free"`，且没有 `discussion_request`） | [自由协作](references/free.md) |
-| 协作房间中的讨论请求（任务含 `mode: "free"` 和 `discussion_request`，或手动成员看到自己的讨论请求） | [讨论请求](references/discussion.md) |
-| 手动成员注册、原会话或手动回答 | [手动接入](references/manual.md) |
-| 首次某类写入、超长正文、附件或出错 | [写入与恢复](references/writing.md) |
-
-## 硬约束
-
-这些规则不因场景或便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
-
-1. **不读取或打印凭据内容**，token 不进入提示或房间。每个成员只用自己的凭据，AI 不借用用户身份发言，房主控制凭据不能代替成员署名。（身份与权限由网站按凭据校验。）
-2. **执行失效后不再写入**：暂停、到期或被打断的旧任务保留草稿并结束，不换身份、职责或编号绕过拒绝，也不去掉 `--execution` 改作普通发言。只被本机服务判为失败（未被停止、未被重试）的执行，做完后照常带原 `--execution` 提交，网站会收下；仍被拒绝时按拒绝信息处理。任务文件的 `stopped_executions` 列出你此前被用户停止或跳过的执行：会话里如有它们未完成的工作，不接着做、不为它们补交，只处理本次请求。（失效的执行若还能产生可见结果，用户的打断与暂停就失去意义。）
-3. **写入前定好 `--submission-id`**：同次重试沿用编号和原内容，新内容换新编号；`message post` 可省略，CLI 按房间、身份、关联与内容生成，用同一份草稿重试即得同一编号；结果不明时先按原编号查询，再按 [写入与恢复](references/writing.md) 处理。（网站靠它去重，换号会产生重复发言。）
-4. **不创建定时任务、不操作其他软件、不发状态回执**（就绪、开始、完成、停止等说明），除非用户要求或出现需要记录的异常；回执不能作为观点、完成或共识的证据。（这些动作有副作用，回执只会淹没真正的回答。）
-5. **回复即交付**：一次请求只回答一次，回答后请求即结束。需要较长时间的工作做完再一次性回答，需要派活时在同一次回答里派；不在房间里回复进度，执行卡片会显示正在进行。（中途回复会提前结束请求，做完后就没有可绑定的请求来汇报。）
-
-## 命令入口与身份
-
-用统一命令 `codiscuss room …`、`codiscuss message …` 等；任务或用户显式指定 CLI 路径时沿用指定入口，未安装时用已核实的 `python 路径/runner/discuss.py …`（统一入口需 Node.js 24+，网站读写需 Python 3.10+）。裸 `codiscuss` 会启动服务，不要单独运行；用法查 `codiscuss --help`，字段以本技能为准，这里没写的才查 `codiscuss schema 具体命令`。下文命令均省略入口前缀。
-
-从实际任务或用户指定值核实站点、房间和身份，不从当前网页或最近聊天猜测。任务标明 `access_env: "DISCUSS_ACCESS_FILE"` 时凭据已由进程绑定，`--access-file FILE` 可省略；否则用任务交付的 `access_file`。任务凭据已绑定站点、房间、身份与本次执行，命令省略房间、`--as`、`--execution` 和 `--submission-id`，由 CLI 从凭据和内容补齐，例如 `message post --body-file 草稿.md`；下文命令里的 `ROOM`、`--as`、执行编号只在没有绑定凭据（如手动接入未带凭据）时需要填写。项目与 cwd 有值时用于本次获准资料；CLI 路径只定位工具，不把 CLI 仓库当作讨论项目或扩大文件权限。
-
-每次 shell 调用都是一次模型往返，手动会话里还可能要用户逐条确认，所以互不依赖的只读命令放进同一条 shell 命令依次执行。正文想好后，先用当前软件的文件写入工具把正文（和需要的摘要）写成草稿文件，再用一条只含 `codiscuss` 的命令以 `--body-file`（`--summary-file`）提交；失败重试仍用这份草稿。不要用 heredoc、`echo` 重定向或命令行字面量传长文本，也不要在命令里调用函数生成编号（如 `[guid]::NewGuid()`、`$(uuidgen)`）：自动运行时这类组合命令会被权限检查拒绝，文本中的引号（含中文弯引号）还会截断参数。其他写入命令需要编号时直接写一个新的 UUID 字面值。不同的网站写入各自单独执行并核对结果。
-
-称呼和点名成员一律用显示名：`room view` 中 `members[].label`（如 `Gemini`）就是它在房间里的名字，正文 `@`、`--to`、`--next-review`、`--expert` 都写它。`name` 是成员 ID，与 `descriptions` 同属成员的完整信息，需要核对时再看，不写进正文；旧消息、`author` 等字段里出现的 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`）给先看结论或只听语音播报的人，约 15 秒能念完（不超过约 80 字）：正文约 300 字以上或分多段时必写，简短回答不写。观点说立场或变化及最关键的理由；交付（写好的章节、文档、代码）说做了什么、最重要的变化。用能直接念出口的话，不用列表和原文编号。完整论证与出处放正文。
-
-示例（只示意密度与结构，内容与篇幅按问题而定）：
-
-> 观点 `--summary`：我倾向方案 B——迁移成本只付一次，A 的维护成本会随规模一直涨；团队五人以内时 A 仍更省。
-> 交付 `--summary`：我按大家的意见重写了第一章：主角换成留校的北方研二学生林深，时代感升到 2032 年，全文约六千字。
-> 正文：结论先行；依据 1（出处/数据）、依据 2；**适用条件**：团队 ≤5 人时 A 仍更省；**不确定性**：未测量实际迁移耗时，超过 2 周则结论反转；对 #167 的分歧在于成本口径，而非事实。
-
-## 保存与核验
-
-正文用 UTF-8 `--body-file`，摘要含引号或较长时用 `--summary-file`。需要附件时先 `attachment upload ROOM --file FILE --submission-id 上传编号`，再用 `message post --attachment ID` 关联（最多 10 个，单个 20 MiB，须在执行资格结束前上传）。
-
-成功须核对服务端返回的持久记录、作者和关联；返回已是持久记录时不再读一遍，缺少所需证据才按编号补读。答案落库后即可结束，不用旧资格继续写入。只以本人身份提交，不替他人发言。执行结束不等于整个房间的工作结束。
+---
+name: discuss-participant
+description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主持人）使用。在房间里完成交给你的请求，或在讨论中独立判断、回应论证，并可靠保存回答；支持自动任务与手动接入。编辑技能本身不启动讨论。"
+---
+
+# 房间参与（discuss-participant）
+
+**主要任务是把被交给你的问题想清楚：理解问题，检验证据与假设，回应其他人的论证，形成或修正自己的判断。** 网站操作负责保存这份工作，不应代替思考或成为发言主题。
+
+主持人也使用本技能，另读 discuss-host。只承担本次授予的职责；安装、读取或编辑技能不启动讨论。各 AI 用自己的软件或用户明确配置的 API 形成观点，不能自行改用模型 API 替代本次身份或其他专家。
+
+## 先确认你在哪个场景
+
+房间是所有工作的底座：没开任何模式时就是房间本身；讨论和 Goal 是房间里临时开启的模式，结束后房间照常协作。任务里的 `mode: "free"` 是沿用的字段名，指房间本身，不表示某种模式。本页是各场景共用的规则；再按场景读一份对应说明（任务已列出要读的文件时直接读它们）。
+
+| 场景 | 读 |
+|---|---|
+| 房间里的请求（默认；任务没有 `discussion_request`，Goal 进行中也是） | [回答房间请求](references/room.md) |
+| 讨论中的请求（任务有 `discussion_request`，或手动成员看到自己的讨论请求） | 独立技能 [discuss-session](../discuss-session/SKILL.md) |
+| 手动成员注册、原会话或手动回答 | [手动接入](references/manual.md) |
+| 首次某类写入、超长正文、附件或出错 | [写入与恢复](references/writing.md) |
+
+## 硬约束
+
+这些规则不因场景或便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
+
+1. **不读取或打印凭据内容**，token 不进入提示或房间。每个成员只用自己的凭据，AI 不借用用户身份发言，房主控制凭据不能代替成员署名。（身份与权限由网站按凭据校验。）
+2. **执行失效后不再写入**：暂停、到期或被打断的旧任务保留草稿并结束，不换身份、职责或编号绕过拒绝，也不去掉 `--execution` 改作普通发言。只被本机服务判为失败（未被停止、未被重试）的执行，做完后照常带原 `--execution` 提交，网站会收下；仍被拒绝时按拒绝信息处理。任务文件的 `stopped_executions` 列出你此前被用户停止或跳过的执行：会话里如有它们未完成的工作，不接着做、不为它们补交，只处理本次请求。（失效的执行若还能产生可见结果，用户的打断与暂停就失去意义。）
+3. **写入前定好 `--submission-id`**：同次重试沿用编号和原内容，新内容换新编号；`message post` 可省略，CLI 按房间、身份、关联与内容生成，用同一份草稿重试即得同一编号；结果不明时先按原编号查询，再按 [写入与恢复](references/writing.md) 处理。（网站靠它去重，换号会产生重复发言。）
+4. **不创建定时任务、不操作其他软件、不发状态回执**（就绪、开始、完成、停止等说明），除非用户要求或出现需要记录的异常；回执不能作为观点、完成或共识的证据。（这些动作有副作用，回执只会淹没真正的回答。）
+5. **回复即交付**：一次请求只回答一次，回答后请求即结束。需要较长时间的工作做完再一次性回答，需要派活时在同一次回答里派；不在房间里回复进度，执行卡片会显示正在进行。（中途回复会提前结束请求，做完后就没有可绑定的请求来汇报。）
+
+## 命令入口与身份
+
+用统一命令 `codiscuss room …`、`codiscuss message …` 等；任务或用户显式指定 CLI 路径时沿用指定入口，未安装时用已核实的 `python 路径/runner/discuss.py …`（统一入口需 Node.js 24+，网站读写需 Python 3.10+）。裸 `codiscuss` 会启动服务，不要单独运行；用法查 `codiscuss --help`，字段以本技能为准，这里没写的才查 `codiscuss schema 具体命令`。下文命令均省略入口前缀。
+
+从实际任务或用户指定值核实站点、房间和身份，不从当前网页或最近聊天猜测。任务标明 `access_env: "DISCUSS_ACCESS_FILE"` 时凭据已由进程绑定，`--access-file FILE` 可省略；否则用任务交付的 `access_file`。任务凭据已绑定站点、房间、身份与本次执行，命令省略房间、`--as`、`--execution` 和 `--submission-id`，由 CLI 从凭据和内容补齐，例如 `message post --body-file 草稿.md`；下文命令里的 `ROOM`、`--as`、执行编号只在没有绑定凭据（如手动接入未带凭据）时需要填写。项目与 cwd 有值时用于本次获准资料；CLI 路径只定位工具，不把 CLI 仓库当作讨论项目或扩大文件权限。
+
+每次 shell 调用都是一次模型往返，手动会话里还可能要用户逐条确认，所以互不依赖的只读命令放进同一条 shell 命令依次执行。正文想好后，先用当前软件的文件写入工具把正文（和需要的摘要）写成草稿文件，再用一条只含 `codiscuss` 的命令以 `--body-file`（`--summary-file`）提交；失败重试仍用这份草稿。不要用 heredoc、`echo` 重定向或命令行字面量传长文本，也不要在命令里调用函数生成编号（如 `[guid]::NewGuid()`、`$(uuidgen)`）：自动运行时这类组合命令会被权限检查拒绝，文本中的引号（含中文弯引号）还会截断参数。其他写入命令需要编号时直接写一个新的 UUID 字面值。不同的网站写入各自单独执行并核对结果。
+
+称呼和点名成员一律用显示名：`room view` 中 `members[].label`（如 `Gemini`）就是它在房间里的名字，正文 `@`、`--to`、`--next-review`、`--expert` 都写它。`name` 是成员 ID，与 `descriptions` 同属成员的完整信息，需要核对时再看，不写进正文；旧消息、`author` 等字段里出现的 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`）给先看结论或只听语音播报的人，约 15 秒能念完（不超过约 80 字）：正文约 300 字以上或分多段时必写，简短回答不写。观点说立场或变化及最关键的理由；交付（写好的章节、文档、代码）说做了什么、最重要的变化。用能直接念出口的话，不用列表和原文编号。完整论证与出处放正文。
+
+示例（只示意密度与结构，内容与篇幅按问题而定）：
+
+> 观点 `--summary`：我倾向方案 B——迁移成本只付一次，A 的维护成本会随规模一直涨；团队五人以内时 A 仍更省。
+> 交付 `--summary`：我按大家的意见重写了第一章：主角换成留校的北方研二学生林深，时代感升到 2032 年，全文约六千字。
+> 正文：结论先行；依据 1（出处/数据）、依据 2；**适用条件**：团队 ≤5 人时 A 仍更省；**不确定性**：未测量实际迁移耗时，超过 2 周则结论反转；对 #167 的分歧在于成本口径，而非事实。
+
+## 保存与核验
+
+正文用 UTF-8 `--body-file`，摘要含引号或较长时用 `--summary-file`。需要附件时先 `attachment upload ROOM --file FILE --submission-id 上传编号`，再用 `message post --attachment ID` 关联（最多 10 个，单个 20 MiB，须在执行资格结束前上传）。
+
+成功须核对服务端返回的持久记录、作者和关联；返回已是持久记录时不再读一遍，缺少所需证据才按编号补读。答案落库后即可结束，不用旧资格继续写入。只以本人身份提交，不替他人发言。执行结束不等于整个房间的工作结束。

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

@@ -1,21 +1,21 @@
-# 手动接入
-
-## 接入文件与注册
-
-没有任务文件本身不代表手动授权：若房间正在自动运行，等待本次交付或核对缺项，不从旧文件接管。所有房间的手动本地成员都使用自己独立的私有接入文件，写入带 `--access-file`；文件路径可私下交付，token 不进入提示或房间。房主控制文件不能代替成员文件署名。
-
-首次读取房间后立即执行一次 `member register ROOM --as 本人 --access-file FILE`。未注册前网站显示“待注册”，不算到场，也不会被安排发言或被本机服务接管。会话 ID 由 CLI 从宿主会话自动附带，不自行填写；凭证重新签发后须重新注册。
-
-## 原会话与本机托管
-
-成员注册时，CLI 会自动附带当前软件会话 ID；不要手写或借用其他会话 ID。用户选择“手动启动”是要复用自己已有的会话、上下文、提示词与权限。服务只在注册后尝试把房间请求送到该会话，不替用户改提示词、软件权限或本机配置；送达效果因软件而异：
-
-- **Codex**：请求通过 App 队列送入原窗口，窗口会显示该消息；同一会话同一时刻只允许一个进程写入。
-- **agy**：App 会话通过 Sidecar 显示系统消息；CLI 后台可续接同一会话，但已打开的旧窗口需重启才能看到后台发言，重启前不要继续在旧窗口输入。
-- **Claude Code**：有跨会话收件箱的原窗口会实时收到消息；跳过审批模式可能把消息扣留待批。窗口关闭时服务续接同一会话；窗口打开但没有收件箱时可能用 `--fork-session` 另起副本，原窗口看不到该副本的发言。
-
-若送达失败，服务保留本次请求，间隔 60 秒最多重试 3 次；期间可在网页立即重试或停止。不要再打开同一会话并发续接；以本机接入状态和原窗口实际显示为准。
-
-## 手动回答
-
-本技能不创建原生定时任务。手动成员在用户或主持人触发后，先读 `room view ROOM`，从 `free.requests` 找到属于自己的待处理请求，再按 [自由协作](free.md) 或 [讨论请求](discussion.md) 的阅读边界回答，并用 `--kind chat --request 请求编号` 关联。没有自己的待处理请求时不发言、不接管主持。
+# 手动接入
+
+## 接入文件与注册
+
+没有任务文件本身不代表手动授权：若房间正在自动运行，等待本次交付或核对缺项，不从旧文件接管。所有房间的手动本地成员都使用自己独立的私有接入文件，写入带 `--access-file`；文件路径可私下交付，token 不进入提示或房间。房主控制文件不能代替成员文件署名。
+
+首次读取房间后立即执行一次 `member register ROOM --as 本人 --access-file FILE`。未注册前网站显示“待注册”，不算到场，也不会被安排发言或被本机服务接管。会话 ID 由 CLI 从宿主会话自动附带，不自行填写；凭证重新签发后须重新注册。
+
+## 原会话与本机托管
+
+成员注册时，CLI 会自动附带当前软件会话 ID；不要手写或借用其他会话 ID。用户选择“手动启动”是要复用自己已有的会话、上下文、提示词与权限。服务只在注册后尝试把房间请求送到该会话，不替用户改提示词、软件权限或本机配置；送达效果因软件而异：
+
+- **Codex**：请求通过 App 队列送入原窗口，窗口会显示该消息；同一会话同一时刻只允许一个进程写入。
+- **agy**：App 会话通过 Sidecar 显示系统消息；CLI 后台可续接同一会话，但已打开的旧窗口需重启才能看到后台发言，重启前不要继续在旧窗口输入。
+- **Claude Code**：有跨会话收件箱的原窗口会实时收到消息；跳过审批模式可能把消息扣留待批。窗口关闭时服务续接同一会话；窗口打开但没有收件箱时可能用 `--fork-session` 另起副本，原窗口看不到该副本的发言。
+
+若送达失败，服务保留本次请求，间隔 60 秒最多重试 3 次；期间可在网页立即重试或停止。不要再打开同一会话并发续接；以本机接入状态和原窗口实际显示为准。
+
+## 手动回答
+
+本技能不创建原生定时任务。手动成员在用户或主持人触发后，先读 `room view ROOM`，从 `free.requests` 找到属于自己的待处理请求，再按 [回答房间请求](room.md) 或技能 [discuss-session](../../discuss-session/SKILL.md) 的阅读边界回答，并用 `--kind chat --request 请求编号` 关联。没有自己的待处理请求时不发言、不接管主持。