# Briefbound Multi Agent Orchestration

> 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.

- Skill: `ccdawn/briefbound-multi-agent-orchestration` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ccdawn/briefbound-multi-agent-orchestration`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ccdawn/briefbound-multi-agent-orchestration/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: CCDawn (https://skillmd.com/u/ccdawn)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ccdawn/briefbound-multi-agent-orchestration

---


# Briefbound Peer-Agent Collaboration

## 目标

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

## Briefbound task contract

- 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、`briefbound-autonomous-collaboration-loop`、`briefbound-thread-coordination`、`briefbound-pr-review`、`briefbound-development-cleanup`、`briefbound-router` 或 BLOCKED。

## 统一调用契约

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

## 进入闸门

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

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

本 skill 维护平级协作协议，不负责持续驱动。用户已确认自动推进所有 peer、恢复冲突并合入本地 `main` 时，以 `briefbound-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 Target / Current Integration Claim / Evidence / Exit Condition`。`Coordination Owner` 仅维护共同决定，`Integration Owner` 仅负责合入验证，均不拥有其他 Agent。开始协作时可以没有 Integration Owner。

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

### 3. 动态认领集成责任

首个交付进入 integration queue 时，相关 Agent 只检查一次 `lane=integration/<target-key>`。无有效 claim 时，有本地权限的 peer 应主动原子认领队列，即使暂受 baseline/dirty main 阻塞；已有 claim 时，其余 Agent只发 `MERGE_READY`，不重复 rebase/gate/merge。用户指定优先；负责人无法维护队列才交接释放。细节交 `briefbound-thread-coordination`。

### 4. 用信息价值降低熵

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

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

### 5. 协商冲突与依赖

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

### 6. 协同集成而非收编结果

每个 Agent 独立报告 `Base / Head or Artifact / Changed Scope / Tests / Assumptions / Risks`。当前有效 integration claim 的 owner 用 Git 与测试重验，不把消息当事实源；队列已有交付但 claim 为空时，先完成动态认领，不把合并义务留给用户。

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

## 完成与降熵门

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

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