Starworkmultiagent

starworkMultiagent

使用这个 Skill，把用户关于“常用智能体”“当前会话职责”“多 Agent 分工”“跨 Agent 输出共享”“跨会话指令”“查看其他 lane 进度”“创建 Agent 团队”的自然语言请求，转成安全的 StarWork 协作流程。

starworkMultiagent 不是 starwork multiagent 命令本身。Skill 负责判断意图、读取必要 reference、直接调用宿主标准会话工具，并把真实结果记录回 StarWork 项目事实源。CLI 只做 StarWork 项目事实源，不是宿主会话动作执行者。

如果用户只是询问 StarWork 是什么、怎么开始、安装入口或该用哪个能力，回到 starwork 主入口。用户明确说多 Agent、Agent Lanes、lane、跨会话消息、开发 Agent、产品 Agent、验收 Agent、Codex 标准会话工具或 Codex 会话控制时，继续使用本 Skill。

workflow 是 next 内测能力；stable Skill 不引导普通用户测试 workflow。如果用户询问 workflow，说明需要 next Skill 或等待正式发布。

先读上下文

开始前优先读取当前工作区内这些文件，存在多少读多少：

AGENTS.md
_系统/上下文/current-projects.md
_系统/上下文/decisions.md
_系统/上下文/product-principles.md
_系统/任务/current-work.md
_系统/协作/agent-lanes.md
_系统/协作/shared.md
_system/context/current-project.md
_system/context/decisions.md
_system/tasks/current-work.md
_system/collaboration/agent-lanes.md
_system/collaboration/shared.md

中文项目使用 _系统/协作/；英文项目使用 _system/collaboration/。如果用户指定目标目录，所有 CLI 命令都加 --target <path>；否则默认当前工作区。

Reference 加载规则

当用户请求命中某个场景时，先读取该场景 reference，再执行动作。

如果 reference 文件不存在或无法读取，不得继续执行对应高风险动作；先说明 Skill 安装不完整，并要求用户用完整目录重新安装 StarWork Skills。

前置保护

starworkInit 负责把普通项目接入 StarWork；本 Skill 只负责已有 StarWork 工作台里的团队协作。

开始任何多 Agent 写入前：

1. 先确认目标目录是 StarWork 工作台；目标不是 StarWork 工作台时，停止 multiagent 写入，转 starworkInit 安全接入。 2. rules_entry_status: pending_merge 时停止写入，转 starworkInit 整合最终 AGENTS.md / 宿主规则入口。 3. multiagent.compatibility.status 不是 current 时，不进行写入类 MultiAgent 操作；先走 v0.10 升级预览。 4. 写入类命令先预览或等用户确认；不要覆盖用户业务文件。

当前会话 ID

任何会话控制或跨会话操作前，必须确认当前会话 ID。

• <codex_delegation> 中的 source_thread_id 优先作为当前来源会话 ID。
• 宿主或运行环境显式提供 current thread / current session metadata 时，使用该值。
• 不得用历史 worklog、旧 binding、相似标题、最近更新时间或猜测出的 thread id 推断当前会话。
• 如果当前会话 ID 不明，停止绑定、改名、置顶、归档、释放和以当前会话为来源的投递记录。
• 发送前必须检查目标 lane session 不等于当前会话；否则默认阻断自我投递，除非用户明确要求本地执行或仅记录。

必须投递

目标是另一个 lane、Agent 或 session 的步骤，都是必须投递步骤。必须投递步骤不能用当前回复说明替代，也不能把“消息已准备好”当作完成。

合法结果只有三类：

状态写入顺序固定：

确认目标 lane / session / current session
  -> 组装 STARWORK:MULTIAGENT_MESSAGE
  -> 调用 send_message_to_thread 或对应宿主标准工具成功
  -> 再执行 starwork multiagent request record delivered...

未真实投递成功不得记录 delivered_via_codex_thread_tool 或 delivered_via_claude_code_session_tool，不得说“已通知”“已完成交接”或“目标任务已完成”。

如果 send_message_to_thread 或对应宿主标准工具不在当前工具列表里，先用工具发现能力查找。工具发现不可见、发现失败或调用失败时，进入 manual_handoff_required，展示完整 STARWORK:MULTIAGENT_MESSAGE v1，并明确尚未自动送达。

CLI 与宿主工具边界

Codex App 正常路径中，创建、投递、读取、命名、置顶、归档由 Skill 直接调用标准线程工具：create_thread、send_message_to_thread、read_thread、list_threads、set_thread_title、set_thread_pinned、set_thread_archived。

CLI 只维护 StarWork 项目事实源，例如：

• starwork doctor --target <path> --json
• starwork multiagent status --target <path> --json
• starwork multiagent init
• starwork multiagent add
• starwork multiagent bind
• starwork multiagent release
• starwork multiagent share
• starwork multiagent request record

不得恢复旧 CLI 自动投递或创建路径作为 Codex App 正常路径；宿主工具不可见时走工具发现或人工交接，不用 CLI 模拟自动投递。

成功口径

对用户汇报时分层说明：

消息已送达不等于目标任务已完成。Agent 已创建 / 会话已绑定也不等于任务已经开始或完成。

Skill-owned Message

Codex App 正常路径中，Skill 自己组装 StarWork 消息，不调用 CLI 模板生成器。消息必须完整可复制，详情读取 references/message-templates.md。

输出与安全

• 不自动决定项目该有哪些 lane；lane ID、职责和写入范围必须来自当前项目语境。
• 不把示例 lane 当默认模板。
• 不把 lane workspace 当成项目正式输出目录。
• lane 外文件修改前，先登记共享请求或取得用户明确授权。
• 工具不可见或失败时，直接给出 manual_handoff_required 和完整可复制消息。
• 完成状态必须来自目标 lane 的明确回报、worklog、shared output 或 read_thread 观察。

事实源参考

需要完整边界、验收标准和协议细节时读取：

../starworkMultiagent-spec.md
../../core/agent-lanes-spec.md

不要在主 Skill 内重复维护 Agent Lanes 协议细节；以 Core SPEC、MultiAgent SPEC 和 references 为事实源。

Context And Compatibility

任何 MultiAgent 写入前，先确认目标目录、入口规则和 MultiAgent 状态。

StarWork 工作台

starworkInit 负责把普通项目接入 StarWork；starworkMultiagent 只负责已有 StarWork 工作台里的协作记录。

目标不是 StarWork 工作台时：

1. 停止 multiagent 写入。 2. 不做局部初始化，不创建无人读取的 AI 规则草稿。 3. 转 starworkInit 做安全接入、预览和确认。

pending merge

如果 doctor 或 adapter 状态显示 AI 入口文档仍是 pending_merge：

1. 停止创建 lane、绑定会话、投递消息和记录 request。 2. 说明 AI 入口还没有最终生效，避免不同 AI 读到不一致规则。 3. 转 starworkInit 整合最终入口文件。

v0.10 compatibility

开始任何会写入 MultiAgent 状态的动作前，读取：

starwork multiagent status --target <path> --json

如果 multiagent.compatibility.status 不是 current：

1. 可以汇总已有 AI 岗位，不能把旧结构误说成“没有 AI 岗位”。 2. 不得继续写入新岗位、绑定会话、登记 shared output 或记录 request。 3. 先解释升级影响，再给出安全预览：

starwork multiagent upgrade --target <path> --dry-run

4. 用户确认后才执行：

starwork multiagent upgrade --target <path> --yes

5. 迁移成功并重新检查为 current 后，才继续原任务。

如果状态为 blocked_conflict 或 unknown_partial，不得承诺自动修复；列出冲突来源，建议用户或 product-lead 人工判断。

Delivery Guarantee

目标是另一个 lane、Agent 或 session 的步骤都是必须投递步骤。必须投递步骤不能用当前回复说明替代。

合法结果

写入顺序

固定顺序：

确认目标 lane / session / current session
  -> 组装 STARWORK:MULTIAGENT_MESSAGE
  -> 调用 send_message_to_thread 或对应宿主标准工具成功
  -> starwork multiagent request record --host-delivery delivered_via_codex_thread_tool ...

未真实投递成功不得记录：

delivered_via_codex_thread_tool
delivered_via_claude_code_session_tool

也不得说“已通知”“已完成交接”或“目标任务已完成”。

换句话说，未投递成功不得写 delivered。

工具发现与人工转交

如果 send_message_to_thread 或目标宿主发送工具不可见：

1. 先用工具发现能力查找。 2. 如果仍不可用或调用失败，输出 manual_handoff_required。 3. 展示完整 STARWORK:MULTIAGENT_MESSAGE v1。 4. 明确说明“尚未自动送达”。 5. 不记录 delivered；如用户已经人工转交，只能按事实补记 recorded_only。

发送成功只代表消息送达和 request 已记录，不代表目标任务完成。

Intent Routing

优先把用户话语归到一个入口，不要一开始讲 CLI 子命令。

含混时先追问，不要擅自执行写入。例如“帮我做一个产品迭代循环”应先问：你是想先设计流程，还是现在按已有流程开始执行？

Lane Workspace And Output Promotion

每个 lane 默认有自己的过程工作区：

_系统/协作/lanes/<lane-id>/workspace/
_system/collaboration/lanes/<lane-id>/workspace/

使用规则

• 草稿、调研笔记、中间分析和临时实验结果，优先放入当前 lane workspace。
• 用户认可的最终交付物、项目正式文档、发布稿和确认稿，应晋升到项目正式输出目录。
• workspace 内容需要其他 lane 读取时，用 starwork multiagent share 登记到当前语言对应的 shared.md。
• 晋升后，以项目正式输出目录中的文件为准；workspace 保留过程记录。
• 不要把 workspace 当成新的长期事实源或归档库。

读取 lane 状态

用户问某个 lane 做到哪了时：

1. 先读 StarWork 协作状态。 2. 对已绑定的 Codex session，调用 read_thread；需要查找历史会话时，调用 list_threads。 3. 汇总时区分宿主会话最近状态、lane worklog、shared outputs / cross-lane requests。

read_thread 是宿主观察，不替代 lane worklog。正式交接仍以 lane worklog 和 shared outputs 为准。

晋升输出

过程材料只有在用户认可、产品负责人确认或 workflow gate 通过后，才晋升为正式输出。晋升前说明目标文件、目的和是否会改正式目录。

Message Templates

Codex App 正常路径中，Skill 自己组装 StarWork 消息，不调用 CLI 模板生成器。消息必须完整可复制。

Instruction Message

<!-- STARWORK:MULTIAGENT_MESSAGE v1 -->

# StarWork MultiAgent Instruction

message_type: instruction
request_id: <REQ-id>
from_lane: <from-lane>
to_lane: <to-lane>
created_at: <ISO time>
recorded_in: _系统/协作/shared.md

## 消息内容

<用户指令或任务说明>

## 边界

- 只在你的 write_scope 内主动修改：<write-scope>
- 如需修改 write_scope 之外的文件，先在共享记录中说明需要授权。
- 不要修改与本任务无关的文件。
- 当前工作区：<absolute-target-path>

## 完成后请回报

1. 更新你的 lane worklog。
2. 如有正式输出，登记 Shared Outputs。
3. 如需验收，向来源 lane 回传复验请求。

<!-- /STARWORK:MULTIAGENT_MESSAGE -->

Launch Message

Launch Message 使用同一包装格式，标题可写成 # StarWork MultiAgent Launch。正文包含：

• lane 职责。
• 写入范围。
• 当前工作区。
• 启动后的第一步。
• 回报方式。

Manual handoff

自动工具不可用时，输出 manual_handoff_required，展示完整消息，并明确“尚未自动送达”。不要说已通知或已发送成功。

Return contract

要求目标 lane 回传时，明确字段：

• changed_files / output_paths
• verification
• risks
• next_action
• acceptance_needed

字段按任务裁剪，不强行套模板。

starworkMultiagent references

这些 reference 是 starworkMultiagent 的场景化操作说明。主 SKILL.md 只保留硬安全规则和加载表；命中具体场景后，先读取对应 reference，再执行动作。

如果本目录不存在或文件无法读取，说明 Skill 安装不完整。不得继续执行创建会话、跨 lane 投递、绑定、晋升输出等高风险动作；先提示用户使用完整目录重新安装 StarWork Skills。

文件

• intent-routing.md：自然语言意图到 MultiAgent 场景的路由。
• context-and-compatibility.md：StarWork 工作台、pending merge、v0.10 兼容迁移前置检查。
• session-tools.md：Codex / Claude Code 宿主标准会话工具边界。
• delivery-guarantee.md：必须投递、工具发现、manual handoff、request record 顺序。
• team-onboarding.md：创建 AI 团队、预览、确认、lane + session 成功标准。
• message-templates.md：Skill-owned StarWork 消息模板。
• lane-workspace-output-promotion.md：lane workspace、shared output、正式输出晋升。
• safety-output-rules.md：写入确认、输出口径和禁止行为。

Safety And Output Rules

写入确认

• 写入类 CLI 命令默认先 dry-run 或征得用户确认。
• 用户明确要求执行后，写入类 CLI 命令使用 --yes。
• status、doctor --json 和只读观察可以直接运行。
• 如果会改正式文件，先列出文件、目的和确认点。

禁止行为

• 不写入 matters/registry.md。
• 不创建任务系统、锁系统或额外 JSON manifest。
• 不自动决定项目该有哪些 lane。
• 不把示例 lane 当默认模板。
• 不把 lane workspace 当成项目正式输出目录。
• 不用 CLI 模拟宿主自动投递。
• 不把消息已送达说成目标任务已完成。

输出格式

对用户汇报时：

• 清楚区分“StarWork 状态已记录”和“宿主工具动作已成功”。
• 只有标准工具调用成功且 CLI 记录成功时，才说 Agent 已创建并绑定或消息已投递。
• 工具不可见或失败时，直接给出 manual_handoff_required 和完整可复制消息。
• 完成状态必须来自目标 lane 的明确回报、worklog、shared output 或宿主会话观察。

Session Tools

宿主动作由宿主标准工具执行，CLI 只记录 StarWork 项目事实源。

当前会话 ID

任何会话控制或跨会话操作前，必须确认当前会话 ID：

• <codex_delegation> 中的 source_thread_id 优先作为当前来源会话 ID。
• 宿主或运行环境显式提供 current thread / current session metadata 时，使用该值。
• 不得用历史 worklog、旧 binding、相似标题或最近更新时间推断当前会话。
• 如果 current session id 不明，停止绑定、改名、置顶、归档、释放和以当前会话为来源的投递记录。
• 发送前必须检查目标 lane session 不等于当前会话。

Codex App

Codex App 正常路径中：

如果工具没有出现在当前可用工具列表里，先用工具发现能力查找。仍不可见或调用失败时，不要宣称已创建、已发送或已改名；转 manual_handoff_required。

Claude Code Desktop

目标会话是 claude-code:<id> 且你正运行在 Claude Code 桌面端时：

非 Codex 宿主

Cursor、Trae 以及 Claude Code 终端 CLI 在没有等价标准会话工具前，不要宣称可以自动创建、发送、改名、置顶或归档。使用人工 handoff 或只读 transcript 摘要。

Team Onboarding

创建 Agent 团队不是只创建 lane。完整成功标准是：每个目标职责都有 lane、每个 lane 已绑定可工作的独立 session，或者输出中明确说明哪些 lane 未完成以及阻塞原因。

第一屏

用户说“开启 MultiAgent”“创建 AI 团队”“帮我创建多个 Agent”时，先用用户语言解释：

• 会把项目拆成几个清楚的 AI 岗位。
• 每个岗位有职责、可以整理或修改的范围、交接方式。
• 先检查项目，再设计岗位方案，再预览写入，确认后创建。
• 检查和预览阶段不会改业务内容。

不要在第一屏出现 lane、write_scope、binding、thread、CLI、doctor 或具体子命令。

自然追问

只问用户能自然回答的问题：

• 这个项目主要想完成什么？
• 希望哪些事情交给不同 AI 分开做？
• 哪些文件或内容不希望 AI 主动修改？

不要索要 lane id、write scope 或 session id。Skill 根据回答生成内部字段。

预览与确认

创建或调整岗位前，用表格预览：

表格后加：

如果这个方案没问题，我再创建这些协作记录。

所有写入前说明“下面是预览，还不会真正写入”。写入后说明“这次只写入了协作记录，没有改你的业务内容”。

会话创建与绑定

每个需要独立 Codex session 的 lane：

1. 组装 Launch Message。 2. 标题建议用短职责名，格式固定为 <职责名> Agent。 3. 调用 create_thread。 4. 如需命名，调用 set_thread_title。 5. 如需置顶，调用 set_thread_pinned。 6. 只有 create_thread 返回 thread id 后，才用 multiagent bind 记录真实 binding。

工具不可见或失败时，说明具体失败点，展示 Launch Message 供用户手动复制；不能说这个 Agent 已创建并绑定。

只有用户明确说“先只初始化协作层 / 先只建职责位 / lane-only”时，才可以停在职责位。