技能介绍

解决的问题

多 Agent 协作最常见的失败不是模型能力不足，而是上下文在并行分支间断裂：前端 agent 不知道后端 API 改了签名，QA 拿到的是开发三天前的假设，冲刺到一半 chat 超过 100 条消息后整个上下文窗口被挤爆，只能从头再讲一遍需求。这个技能把人类明确定义为「消息总线」——你不是写代码的人，你是负责在多个独立 VS Code 窗口之间搬运决策和状态的人。

如何工作

核心是一份不可简化的 PROJECT_BRIEF.md，作为所有并行 chat 的唯一事实来源。它包含 14 个必需章节，其中最关键的是第 12 条 Cross-Chat Handoff Protocol（定义上下文如何跨窗口存活）和第 13 条 Bug & Fix Tracking（GitHub Issues 而非聊天记录作为唯一追踪源）。

冲刺执行采用三文件结构：

docs/sprint-N/plan.md：按优先级排列的任务与成功标准
docs/sprint-N/progress.md：实时更新的状态追踪器，用于恢复中断的 chat
docs/sprint-N/done.md：冲刺结束时的交接文档

团队角色预设了七个 Agent：Producer Remy 负责范围控制和 PR 合并、Product Designer Kira 关注用户体验、Visual Director Milo 负责设计系统、Frontend Nova、Backend Sage、DevOps Dash、QA Ivy。你可以重命名或裁剪这些角色——不是每个项目都需要全套阵容。

当 chat 超过 100 条消息时，触发 Context Recovery 流程：先更新 progress.md，再改写 PROJECT_BRIEF.md 的第 7、8 节，最后写 done.md，然后用 cold start prompt 在全新窗口重启。

适用边界

这套设计假设你能为每个角色开独立窗口并接受 Git 工作流约束。Anti-Patterns 明确禁止 rebase 功能分支（会丢 commit）、禁止 Producer 直接写代码、禁止把 bug 只留在 chat 里。如果你的项目无法使用 GitHub Issues 作为追踪源，或无法接受「一个 fix 一个 commit 并关联 issue」的纪律，这套流程会退化成形式。

另外，Brainstorm 阶段要求至少 2 次真实分歧来防止群体思维——如果你习惯让 AI 直接给出「正确答案」，这种要求冲突的脑暴格式会让你觉得啰嗦。