swarm

Name: swarm
Author: apple-ouyang

77stars5forks

How to install swarm?

apple-ouyang/book-to-skill/swarm

$npx -y skills add apple-ouyang/book-to-skill --skill swarm

Installs into the current project.

Summary

This skill should be used when the user asks to "create a team", "create agent team", "蜂群", "swarm", "团队协作", "parallel agents", "spawn teammates", "多 agent 协作", "组建团队", or executes "/swarm". Analyzes user tasks, designs optimal team structure (roles, count, prompts), presents pla

Files · 1

View on GitHub

SKILL.md

1	# 蜂群 Swarm
2
3	分析用户任务，自动规划 Agent 团队结构（角色、数量、提示词），确认后执行团队协作。
4
5	## 核心流程
6
7	```
8	分析任务 → 选择团队模式 → 设计角色与提示词 → 用户确认 → 创建团队 → 分配任务 → 监控执行
9	```
10
11	## 第一步：分析任务
12
13	收到用户任务描述后，从以下维度分析：
14
15	\| 维度 \| 评估内容 \|
16	\|------\|---------\|
17	\| 任务类型 \| 功能开发 / 代码审计 / Bug 调试 / 技术选型 / 重构迁移 \|
18	\| 可并行度 \| 哪些子任务可以同时进行 \|
19	\| 文件冲突 \| 不同角色是否会修改同一文件 \|
20	\| 依赖关系 \| 哪些任务必须按顺序执行 \|
21	\| 复杂度 \| 决定团队规模（2-8 人） \|
22
23	## 第二步：选择团队模式
24
25	根据分析结果，从预定义模式中选择最匹配的模式。详见 `references/team-patterns.md`。
26
27	五种基础模式：
28	1. 功能开发 — 新功能、跨层变更
29	2. 代码审计 — PR Review、安全审计
30	3. 调试竞争 — Bug 排查、假设验证
31	4. 研究辩论 — 技术选型、方案评估
32	5. 重构迁移 — 大规模重构、架构迁移
33
34	可混合使用或自定义。如果任务不完全匹配任何模式，基于模式原则自行设计。
35
36	## 第三步：设计角色与提示词
37
38	为每个 teammate 设计：
39
40	1. 角色名称：简短描述（如 `frontend-dev`、`security-reviewer`）
41	2. Agent 类型：根据职责选择（详见 `references/agent-types.md`）
42	3. 模型：根据任务复杂度选择（opus/sonnet/haiku）
43	4. 权限模式：default / plan / bypassPermissions
44	5. 提示词：包含角色、职责、文件范围、输出要求、协作规则
45	6. 文件范围：明确可操作的目录，避免冲突
46
47	提示词结构：
48	```
49	角色：{role}
50	职责：{responsibilities}
51
52	工作范围：
53	- 只修改：{allowed_dirs}
54	- 不要触碰：{excluded_dirs}
55
56	输出要求：
57	- {output_format}
58
59	协作规则：
60	- 发现跨模块影响时，通过消息通知 {related_teammate}
61	- 完成后标记任务为 completed
62
63	完成标准：
64	- {completion_criteria}
65	```
66
67	## 第四步：展示计划并确认
68
69	以结构化格式展示团队计划，等待用户确认：
70
71	```markdown
72	## 团队计划
73
74	任务：{task_description}
75	模式：{pattern_name}
76	团队规模：{count} 人
77
78	### 角色分配
79
80	\| # \| 角色 \| Agent 类型 \| 模型 \| 职责概要 \|
81	\|---\|------\|-----------\|------\|---------\|
82	\| 1 \| {name} \| {type} \| {model} \| {summary} \|
83	\| ...
84
85	### 任务列表与依赖
86
87	\| ID \| 任务 \| 负责人 \| 依赖 \|
88	\|----\|------\|--------\|------\|
89	\| 1 \| {task} \| {owner} \| - \|
90	\| 2 \| {task} \| {owner} \| blockedBy: 1 \|
91	\| ...
92
93	### 文件分工（避免冲突）
94
95	\| 角色 \| 可操作目录 \|
96	\|------\|-----------\|
97	\| {name} \| {dirs} \|
98	\| ...
99
100	确认此计划？(Y/修改建议)
101	```
102
103	使用 `AskUserQuestion` 工具让用户确认或提出修改。
104
105	## 第五步：创建团队并执行
106
107	用户确认后，按以下顺序执行：
108
109	### 5.1 创建团队
110
111	```
112	TeamCreate → team_name: "{task-slug}"
113	```
114
115	### 5.2 创建任务列表
116
117	按计划创建所有任务（TaskCreate），设置依赖关系（TaskUpdate + addBlockedBy）。
118
119	### 5.3 启动 Teammates
120
121	对每个角色，使用 Task 工具启动 teammate：
122
123	```
124	Task → subagent_type: "{agent_type}"
125	name: "{role_name}"
126	team_name: "{team_name}"
127	model: "{model}"
128	mode: "{permission_mode}"
129	prompt: "{designed_prompt}"
130	```
131
132	### 5.4 分配任务
133
134	通过 TaskUpdate 将任务分配给对应 teammate（设置 owner）。
135
136	## 第六步：监控与协调
137
138	团队运行期间：
139
140	1. 接收消息：teammate 消息自动送达，及时回应
141	2. 解决冲突：如果多个 teammate 需要修改同一文件，协调顺序
142	3. 重新分配：如果某 teammate 卡住，重新分配任务或提供帮助
143	4. 质量把关：审查 teammate 的输出，不合格则要求修改
144	5. 合成结果：所有任务完成后，汇总最终成果
145
146	## 第七步：清理
147
148	所有任务完成后：
149
150	1. 向所有 teammate 发送 shutdown_request
151	2. 等待所有 teammate 关闭
152	3. 调用 TeamDelete 清理资源
153	4. 向用户汇报最终结果
154
155	## 关键规则
156
157	### 避免文件冲突
158
159	最重要的规则：不同 teammate 不能同时修改同一文件。
160
161	- 按目录/模块划分文件范围
162	- 共享文件（如配置文件）由领导统一修改
163	- 需要跨模块变更时，通过消息协调
164
165	### 控制团队规模
166
167	- 宁少勿多，每增加一个 teammate 都增加 token 消耗
168	- 简单任务（单模块）：2-3 人
169	- 中等任务（跨模块）：3-4 人
170	- 复杂任务（跨层）：4-6 人
171
172	### 使用 Delegate 模式
173
174	领导应专注协调，不直接写代码。如果发现自己在实现任务，停下来分配给 teammate。
175
176	### 提示词要具体
177
178	模糊的提示词导致 teammate 偏离方向。包含：
179	- 具体的文件路径和目录
180	- 明确的输出格式
181	- 清晰的完成标准
182
183	## 参考资源
184
185	### Reference Files
186
187	- `references/team-patterns.md` — 五种团队模式模板、决策树、规模建议
188	- `references/agent-types.md` — Agent 类型能力对照、模型选择、提示词模板

People who liked this also viewed

6 picks

Type

swarm

77stars5forks

View on GitHub

How to install swarm?

apple-ouyang/book-to-skill/swarm

$npx -y skills add apple-ouyang/book-to-skill --skill swarm

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# 蜂群 Swarm
2
3	分析用户任务，自动规划 Agent 团队结构（角色、数量、提示词），确认后执行团队协作。
4
5	## 核心流程
6
7	```
8	分析任务 → 选择团队模式 → 设计角色与提示词 → 用户确认 → 创建团队 → 分配任务 → 监控执行
9	```
10
11	## 第一步：分析任务
12
13	收到用户任务描述后，从以下维度分析：
14
15	\| 维度 \| 评估内容 \|
16	\|------\|---------\|
17	\| 任务类型 \| 功能开发 / 代码审计 / Bug 调试 / 技术选型 / 重构迁移 \|
18	\| 可并行度 \| 哪些子任务可以同时进行 \|
19	\| 文件冲突 \| 不同角色是否会修改同一文件 \|
20	\| 依赖关系 \| 哪些任务必须按顺序执行 \|
21	\| 复杂度 \| 决定团队规模（2-8 人） \|
22
23	## 第二步：选择团队模式
24
25	根据分析结果，从预定义模式中选择最匹配的模式。详见 `references/team-patterns.md`。
26
27	五种基础模式：
28	1. 功能开发 — 新功能、跨层变更
29	2. 代码审计 — PR Review、安全审计
30	3. 调试竞争 — Bug 排查、假设验证
31	4. 研究辩论 — 技术选型、方案评估
32	5. 重构迁移 — 大规模重构、架构迁移
33
34	可混合使用或自定义。如果任务不完全匹配任何模式，基于模式原则自行设计。
35
36	## 第三步：设计角色与提示词
37
38	为每个 teammate 设计：
39
40	1. 角色名称：简短描述（如 `frontend-dev`、`security-reviewer`）
41	2. Agent 类型：根据职责选择（详见 `references/agent-types.md`）
42	3. 模型：根据任务复杂度选择（opus/sonnet/haiku）
43	4. 权限模式：default / plan / bypassPermissions
44	5. 提示词：包含角色、职责、文件范围、输出要求、协作规则
45	6. 文件范围：明确可操作的目录，避免冲突
46
47	提示词结构：
48	```
49	角色：{role}
50	职责：{responsibilities}
51
52	工作范围：
53	- 只修改：{allowed_dirs}
54	- 不要触碰：{excluded_dirs}
55
56	输出要求：
57	- {output_format}
58
59	协作规则：
60	- 发现跨模块影响时，通过消息通知 {related_teammate}
61	- 完成后标记任务为 completed
62
63	完成标准：
64	- {completion_criteria}
65	```
66
67	## 第四步：展示计划并确认
68
69	以结构化格式展示团队计划，等待用户确认：
70
71	```markdown
72	## 团队计划
73
74	任务：{task_description}
75	模式：{pattern_name}
76	团队规模：{count} 人
77
78	### 角色分配
79
80	\| # \| 角色 \| Agent 类型 \| 模型 \| 职责概要 \|
81	\|---\|------\|-----------\|------\|---------\|
82	\| 1 \| {name} \| {type} \| {model} \| {summary} \|
83	\| ...
84
85	### 任务列表与依赖
86
87	\| ID \| 任务 \| 负责人 \| 依赖 \|
88	\|----\|------\|--------\|------\|
89	\| 1 \| {task} \| {owner} \| - \|
90	\| 2 \| {task} \| {owner} \| blockedBy: 1 \|
91	\| ...
92
93	### 文件分工（避免冲突）
94
95	\| 角色 \| 可操作目录 \|
96	\|------\|-----------\|
97	\| {name} \| {dirs} \|
98	\| ...
99
100	确认此计划？(Y/修改建议)
101	```
102
103	使用 `AskUserQuestion` 工具让用户确认或提出修改。
104
105	## 第五步：创建团队并执行
106
107	用户确认后，按以下顺序执行：
108
109	### 5.1 创建团队
110
111	```
112	TeamCreate → team_name: "{task-slug}"
113	```
114
115	### 5.2 创建任务列表
116
117	按计划创建所有任务（TaskCreate），设置依赖关系（TaskUpdate + addBlockedBy）。
118
119	### 5.3 启动 Teammates
120
121	对每个角色，使用 Task 工具启动 teammate：
122
123	```
124	Task → subagent_type: "{agent_type}"
125	name: "{role_name}"
126	team_name: "{team_name}"
127	model: "{model}"
128	mode: "{permission_mode}"
129	prompt: "{designed_prompt}"
130	```
131
132	### 5.4 分配任务
133
134	通过 TaskUpdate 将任务分配给对应 teammate（设置 owner）。
135
136	## 第六步：监控与协调
137
138	团队运行期间：
139
140	1. 接收消息：teammate 消息自动送达，及时回应
141	2. 解决冲突：如果多个 teammate 需要修改同一文件，协调顺序
142	3. 重新分配：如果某 teammate 卡住，重新分配任务或提供帮助
143	4. 质量把关：审查 teammate 的输出，不合格则要求修改
144	5. 合成结果：所有任务完成后，汇总最终成果
145
146	## 第七步：清理
147
148	所有任务完成后：
149
150	1. 向所有 teammate 发送 shutdown_request
151	2. 等待所有 teammate 关闭
152	3. 调用 TeamDelete 清理资源
153	4. 向用户汇报最终结果
154
155	## 关键规则
156
157	### 避免文件冲突
158
159	最重要的规则：不同 teammate 不能同时修改同一文件。
160
161	- 按目录/模块划分文件范围
162	- 共享文件（如配置文件）由领导统一修改
163	- 需要跨模块变更时，通过消息协调
164
165	### 控制团队规模
166
167	- 宁少勿多，每增加一个 teammate 都增加 token 消耗
168	- 简单任务（单模块）：2-3 人
169	- 中等任务（跨模块）：3-4 人
170	- 复杂任务（跨层）：4-6 人
171
172	### 使用 Delegate 模式
173
174	领导应专注协调，不直接写代码。如果发现自己在实现任务，停下来分配给 teammate。
175
176	### 提示词要具体
177
178	模糊的提示词导致 teammate 偏离方向。包含：
179	- 具体的文件路径和目录
180	- 明确的输出格式
181	- 清晰的完成标准
182
183	## 参考资源
184
185	### Reference Files
186
187	- `references/team-patterns.md` — 五种团队模式模板、决策树、规模建议
188	- `references/agent-types.md` — Agent 类型能力对照、模型选择、提示词模板

People who liked this also viewed

6 picks

Type