amq-spec

AMQ 协作式规范

两个 Agent 独立研究一个设计问题，进行讨论，并就一个方案达成一致。用户批准方案后，任何人才能开始实现。

各阶段按顺序进行： Research -> Discuss -> Draft -> Review -> Present -> Execute

各阶段的命令以及研究和计划模板请参阅 规范工作流。

解析输入

从用户提示中提取：

• topic：简短的 kebab-case 规范名称（例如，auth-token-rotation）
• partner：合作 Agent 的句柄（默认值：codex）
• problem：完整的设计问题陈述

如果 topic/problem 不清楚，请请求澄清。

前置检查

1. 确认 AMQ 可用：which amq
2. 确认可以找到 AMQ 根目录（.amqrc、AMQ 环境变量或默认的 .agent-mail 布局）；否则运行：amq coop init
3. 使用线程名称：spec/<topic>

启动

先将问题发送给合作方，再开始自己的研究。随后两个 Agent 并行研究。原封不动地发送用户的问题；你自己的分析应写在研究消息中，以免影响合作方的判断。

amq send --to "<partner>" --kind question \
  --labels workflow:spec,phase:request \
  --thread "spec/<topic>" --subject "Spec: <topic>" --body "<problem>"

标签

每条规范消息都使用普通的 AMQ 类型，并在 spec/<topic> 线程上附加以下标签：

阶段	类型	标签
问题陈述	question	workflow:spec,phase:request
研究发现	brainstorm	workflow:spec,phase:research
讨论	brainstorm	workflow:spec,phase:discuss
计划草案	review_request	workflow:spec,phase:draft
计划反馈	review_response	workflow:spec,phase:review
最终决定	decision	workflow:spec,phase:decision
进度/预计时间	status	workflow:spec

收到规范消息时

标签	你的操作
phase:request	先自行研究，然后发送类型为 brainstorm、标签为 phase:research 的研究发现。
phase:research	如果你还没有在此线程发送自己的研究内容，先进行研究并发送，然后再阅读合作方的内容。之后阅读线程，并以类型 brainstorm、标签 phase:discuss 开始讨论。
phase:discuss	回复你的分析；持续讨论，直到达成一致。
phase:draft	审查计划，并发送类型为 review_response、标签为 phase:review 的反馈。不要实现。
phase:review	根据需要修订计划，或确认达成一致。
phase:decision	停止。不要实现；请参阅下方的审批关卡。

审批关卡

phase:decision 消息记录的是 Agent 之间达成的共识，并非用户批准。发起方在聊天中向用户呈现最终计划，并按照操作员审批关卡的说明，在 gate/<topic> 线程上向人工句柄（通常为 user）发送审批请求。只有人工在该线程上批准后才能开始实现；之后发起方分配工作，合作方才能开始。

规则

• 等待现有唤醒。 如果有正在注入消息的唤醒，先完成独立工作，然后让出控制权；在它的门铃上运行 amq drain --include-body。不要启动 amq watch、amq monitor 或轮询循环。如果不确定是否具备该能力，请检查 amq wake check --me <handle> --json。只有在没有注入式唤醒时，才将有时限的 watch 作为备用方案。
• 先发送，再研究；先发送研究结果，再阅读合作方的内容。 独立研究是第二个 Agent 能带来的价值。
• 不要跳过阶段。 讨论阶段有助于发现误解。
• 保留 spec/<topic> 线程和标签。 上方的接收方表格依赖这些内容。
• 研究期间保留工具访问权限。 不要进入会阻止工具使用的计划模式。