ccdawn-multi-agent-orchestration

name	ccdawn-multi-agent-orchestration
description	Use when two or more existing, independent Codex App threads in the same project can help each other finish their own tasks through peer negotiation, shared-contract alignment, dependency exchange, conflict reduction, or coordinated local integration; do not use to create or command subagents, transfer ownership, or add ceremony to unrelated work.
license	MIT

CCDawn Peer-Agent Collaboration

目标

让同项目的平级会话 Agent 各自完成原任务，同时通过最少必要协商减少重复劳动、修改冲突、过期结论和集成返工。编排对象是协作过程，不是其他 Agent。

BRT interface

• Context Boundary: 已对齐意图、现有独立 thread、各自任务/scope/branch、共享契约、依赖、冲突和集成目标。
• Output Contract: peer agreement、责任边界、共享决定、依赖交付、集成证据和各自任务状态。
• Allowed Action: 读取/发送 thread 消息、使用现有 registry、协商和执行已授权的本地集成；不得替对方改任务状态，新建会话、远程 Git、发布和破坏性动作需授权。
• Success Evidence: 每个 Agent 的原任务保持 owner、共享边界无矛盾、重复工作被消除、目标分支验证通过且恢复债务清零。
• Stop Condition: 意图未对齐、不是同项目、缺少有效 thread、协作成本不低于收益、责任争议、高风险取舍或权限不足。
• Route Out: 各 Agent 原 owner、ccdawn-autonomous-collaboration-loop、ccdawn-thread-coordination、ccdawn-pr-review、ccdawn-development-cleanup、ccdawn-brt 或 BLOCKED。

统一调用契约

• 所有 Agent 平级且保留原任务、写入许可、branch 和完成责任；没有主从、派发或隐式任务转移。
• 用户可见内容默认中文，只报改变行动的共同决定、依赖、风险和集成证据。Route Out 仅以 BRT interface 为准；末行写 下一步建议: <一个具体动作>。
• 协作必须改善至少一个本地任务且不损害其他任务，或降低共享项目的冲突/回归；否则静默返回各自工作。

进入闸门

BRT 已完成意图对齐和有界发现，以 PEER_COLLABORATION_READY 交接；本轮具有原生 thread read/send 能力，并且至少两个现有独立会话存在真实互补、依赖、重叠或共同集成面。

简单任务、仅目录相似、无共享决定、同一小文件无法并行，或消息/合并成本高于预期收益时不进入。一次建议、状态交换或单一冲突只用 ccdawn-thread-coordination。

本 skill 维护平级协作协议，不负责持续驱动。用户已确认自动推进所有 peer、恢复冲突并合入本地 main 时，以 ccdawn-autonomous-collaboration-loop 为 primary，本 skill 只提供 agreement 支持。

平级协作循环

1. 建立各自与共同事实

读取每个候选的 Task / Desired Outcome / Scope / Branch or Worktree / Checkpoint / Blocker / Success Evidence。区分：各自独占面、共享契约、依赖交付和集成面。代码、Git 和运行证据优先于消息或 registry。

2. 提出协作而非派发

任何 Agent 都可提出 COLLABORATION_PROPOSAL，但不能改变对方任务。对方以 PEER_ACCEPT / PEER_ADAPT / PEER_DECLINE 自主决定。只有接受后才形成 agreement；需要消息结构时读取 references/team-protocol.md。

agreement 只记录 Peer Tasks / Shared Surface / Each Scope / Dependency / Integration Owner / Evidence / Exit Condition。Coordination Owner 仅维护共同决定，Integration Owner 仅负责合入验证，均不拥有其他 Agent。

使用一次 registry claim 原子占用 lane=collaboration/<topic-key>，并加入相关 thread/<agent-id> 与共享 surface，防止重复提议；拒绝、过期或结束后释放。每个 Agent 继续自己的非冲突工作，不等待可选协作。

3. 用信息价值降低熵

只在共享契约变化、依赖就绪、可行动新证据、结论纠正、真实 blocker 或 MERGE_READY 时通信。消息必须说明发送者、原任务、证据、对双方行动的影响和期望回复。

不发送无变化进度、逐步思考、重复边界、可自行读取的信息或非阻塞催促。相同事实只保留最新结论；矛盾结论用 CORRECTION 明确替代关系。没有新增决策价值时继续各自任务。

4. 协商冲突与依赖

共享接口或实现顺序有分歧时，由 ccdawn-thread-coordination 维护 discussion，各方提交立场与证据后形成共同决定。先调整 scope、顺序或接口；只有继续写会立即覆盖/回归且无法拆分时才暂停。暂停方让出 claim，解决后必须恢复，不能因另一方结束而遗留。

5. 协同集成而非收编结果

每个 Agent 独立报告 Base / Head or Artifact / Changed Scope / Tests / Assumptions / Risks。约定的 Integration Owner 用 Git 与测试重验，不把消息当事实源。

• 同一 checkout 的不重叠修改无需制造 merge；独立 branch/worktree 才进入 integration queue。
• 有依赖或共享契约时串行集成；冲突由相关 Agent 共同决定，机械冲突才由 Integration Owner 处理。
• 每项运行窄验证，全部合入后运行一次集成 gate；失败只通知责任 Agent 和受影响依赖方。
• 不得在未授权时 push、创建/合并远程 PR、发布或直接改受保护 main。

完成与降熵门

协作完成不等于替任何 Agent 完成任务。只有各自交付达到原验收、共享决定一致、必要集成验证通过、open coordination 和 resumePendingAgentIds 恢复债务清零时，才结束共同 agreement。

收口前检查：是否减少了重复实现、冲突修改、过期消息和多余 worktree；协作日志是否只保留会改变后续行动的事实。存在真实残留才路由 ccdawn-development-cleanup。