⚡

多角色产品规划会话Skill dyad:swarm-to-plan

这个技能用于通过产品经理、UX设计师和工程负责人等多角色代理进行协作辩论、识别模糊点、澄清范围并生成详细规格文档，适用于软件开发和产品管理中的需求分析和规划过程，关键词包括产品规划、团队协作、需求分析、规格文档、敏捷开发。

需求分析 0 次安装 0 次浏览 更新于 3/15/2026

名称: dyad:swarm-to-plan 描述: 群组规划会话，涉及产品经理、UX设计师和工程负责人等多角色代理进行辩论、提出澄清问题，并生成详细规格文档，写入 plans/$plan-name.md。

群组规划会话

此技能使用一组专业代理（产品经理、UX设计师、工程负责人）协作辩论一个想法，识别模糊点，与人类澄清范围，并生成全面的计划。

参数

  • $ARGUMENTS: 要规划的想法或功能（例如，“添加协作编辑”、“重新设计设置页面”）

概述

  1. 创建一个包含PM、UX和Eng代理的规划团队
  2. 每个代理从各自角度分析想法
  3. 代理辩论并挑战彼此的假设
  4. 团队负责人综合未解决的问题并向人类请求澄清
  5. 澄清后，代理完善分析
  6. 团队负责人编译最终计划并写入 plans/$plan-name.md

工作流程

步骤1: 设置上下文

从 $ARGUMENTS 读取想法。简要探索代码库以理解：

  • 当前技术栈和架构（检查package.json、关键配置文件）
  • 与想法相关的现有模式
  • 可能受影响的文件和模块

重要: 读取 rules/product-principles.md 并在与团队共享的上下文摘要中包含产品设计原则。所有代理应使用这些原则自主指导决策——只有在原则内真正无法解决时，才向用户标记张力或权衡。

准备一个简短的上下文摘要与团队共享。

步骤2: 创建规划团队

使用 TeamCreate 创建团队：

TeamCreate:
  team_name: "plan-<slugified-idea-name>"
  description: "规划会话用于: <idea>"

步骤3: 创建任务

创建4个任务：

  1. “从产品角度分析想法” - 分配给 pm
  2. “从UX角度分析想法” - 分配给 ux
  3. “从工程角度分析想法” - 分配给 eng
  4. “辩论和完善计划” - 被任务1-3阻塞，无所有者

步骤4: 生成团队成员

使用 Task 工具并行生成所有3个团队成员，设置 team_name 为团队名称。每个团队成员应为 general-purpose 子代理。

重要: 每个团队成员的提示必须包括：

  1. 他们的角色描述（来自 references/ 中的相应文件）
  2. 完整的想法描述
  3. 步骤1中收集的代码库上下文摘要
  4. 通过SendMessage发送分析的指令

团队成员提示模板

对于每个团队成员，提示应遵循此结构：

您是一个产品规划团队中的[角色名称]。仔细阅读您的角色描述：

<role>
[references/<role>.md的内容]
</role>

您正在规划此想法：“<想法描述>”

<codebase_context>
[技术栈、相关架构和现有模式的简要摘要]
</codebase_context>

## 指令

1. 仔细阅读您的角色描述，并从您的专家角度分析想法。
2. 按照角色描述中描述的输出格式，生成彻底的分析。
3. 识别2-5个**未解决的问题**——模糊、未指定或可能多种方式的事项。对于每个问题，解释答案为何重要（答案如何影响变化）。
4. 使用SendMessage将分析发送给团队负责人。

发送初始分析后，等待团队负责人分享其他团队成员的分析。当收到时：

- **同意**您认为正确的观点
- **挑战**您不同意的观点，给出具体推理
- **构建**来自其他角色与您专业知识相交的想法
- **标记**从阅读他人分析中浮现的新问题

专注于真正的权衡和真实的分歧，而不是表面的共识。

步骤5: 收集初始分析

等待所有3个团队成员发送初始分析。

步骤6: 促进跨角色辩论

所有初始分析完成后：

  1. 向每个团队成员发送包含所有三个角色分析的消息
  2. 要求他们辩论：同意、挑战、构建或标记新问题
  3. 等待辩论响应

给每个团队成员的消息应如下：

所有初始分析已就绪。以下是所有三个角色的观点：

## 产品经理分析:
[PM的完整分析]

## UX设计师分析:
[UX的完整分析]

## 工程负责人分析:
[Eng的完整分析]

请从您的专家角度审查其他团队成员的分析：

- 同意合理观点（说“同意: <观点> — <原因>”）
- 挑战不同意的观点（说“挑战: <观点> — <您的反论点>”）
- 构建与您专业知识相交的想法（说“构建: <观点> — <您的补充>”）
- 标记浮现的新问题（说“标记: <问题> — <为何重要>”）

专注于真正的分歧和真实权衡。不要为了友好而同意一切。

步骤7: 综合问题向人类提问

辩论后，编译所有未解决的问题和未解决的分歧。按主题分组并按影响优先级排序。

使用 AskUserQuestion 向人类提问澄清问题。结构化问题以解决最高影响的模糊点。您可以使用多问题格式一次提问最多4个问题。关键提问内容：

  • 范围决策（MVP vs. 完整功能）
  • 团队分歧的UX权衡
  • 有意义的权衡技术方法选择
  • 优先级和约束（时间线、性能要求等）

如果超过4个问题，先问最关键的问题，然后根据需要跟进附加轮次。

步骤8: 分享澄清并收集最终输入

将人类的答案发送回所有团队成员，并要求每个提供基于新信息的最终完善看法。这应简短——仅基于新信息调整原始分析。

步骤9: 编译最终计划

收到所有团队成员最终输入后，编译一个全面的计划文档。计划应综合所有三个观点为一个一致的规格。

步骤10: 写入计划

如果 plans/ 目录不存在，则创建它，然后将计划写入 plans/<plan-name>.md：

mkdir -p plans

计划文件应遵循此格式：

# <计划标题>

> 由群组规划会话生成于<日期>

## 摘要

<2-3句概述我们构建什么及原因>

## 问题陈述

<从PM角度清晰阐述用户问题>

## 范围

### 范围内（MVP）

- <功能1>
- <功能2>

### 范围外（后续）

- <延迟功能1>
- <延迟功能2>

## 用户故事

- 作为<用户>，我想要<目标>以便<原因>
- ...

## UX设计

### 用户流程

<主要交互的逐步演练>

### 关键状态

- **默认**: <描述>
- **加载中**: <描述>
- **空状态**: <描述>
- **错误**: <描述>

### 交互细节

<特定交互、手势、反馈机制>

### 可访问性

<键盘导航、屏幕阅读器、对比度、动画考虑>

## 技术设计

### 架构

<如何融入现有系统>

### 受影响组件

- `路径/到/文件.ts` — <变化内容>
- ...

### 数据模型变化

<新增或修改的模式、存储、状态>

### API变化

<新增或修改的接口>

## 实施计划

### 阶段1: <名称>

- [ ] <任务1>
- [ ] <任务2>

### 阶段2: <名称>

- [ ] <任务3>
- [ ] <任务4>

## 测试策略

- [ ] <测试内容和方式>

## 风险与缓解

| 风险   | 可能性 | 影响  | 缓解措施 |
| ------ | ---------- | ------- | ---------- |
| <风险> | <高/中/低>    | <高/中/低> | <策略> |

## 未解决问题

<实施期间应解决的任何剩余问题>

## 决策日志

<规划期间做出的关键决策及其推理>

---

_由dyad:swarm-to-plan生成_

步骤11: 关闭团队

写入计划后：

  1. 向所有团队成员发送关闭请求
  2. 等待关闭确认
  3. 使用TeamDelete删除团队
  4. 告知用户计划位置: plans/<plan-name>.md

错误处理

  • 如果团队成员未响应，继续使用其他代理输入
  • 如果人类拒绝回答问题，继续使用团队最佳假设并在计划中注明
  • 即使某些观点不完整，也始终写入计划文件
  • 即使有错误，完成后也始终关闭团队

文件结构

references/
  pm.md   - 产品经理角色描述
  ux.md   - UX设计师角色描述
  eng.md  - 工程负责人角色描述