CCteam-creator-cn

Name: CCteam-creator-cn
Author: jessepwj

301stars46forks

How to install CCteam-creator-cn?

jessepwj/ccteam-creator/ccteam-creator-cn

$npx -y skills add jessepwj/CCteam-creator --skill CCteam-creator-cn

Installs into the current project.

Summary

Set up a complete agent team with file-based planning for complex multi-agent projects. Use when: (1) user asks to start a new complex project with a team/swarm, (2) user says "set up team", "create team", "build a team for X", "start project X", (3) user invokes /CCteam-creator-

Files · 1

View on GitHub

SKILL.md

1	# 团队项目设置
2
3	为复杂项目设置多智能体团队，使用持久化文件进行规划和进度追踪。
4
5	## 前置条件
6
7	在开始第 1 步之前，你（team-lead）必须直接读取所有参考文件到自己的上下文中：
8
9	```
10	Read references/onboarding.md
11	Read references/templates.md
12	Read references/roles.md
13	```
14
15	不要委托给子智能体（Explore、general-purpose 等）去读取。子智能体只会返回摘要，丢失关键细节——你需要完整的模板和入职 prompt 才能正确生成文件和启动智能体。
16
17	## 流程
18
19	第 0 步 Update Check（自动）：后台拉取最新 version 对比本地，如有新版一行通知后继续
20	第 0 步 Detect（自动）：检查 `.plans/` 是否已存在 → 如有，提供恢复选项
21
22	1. 需求咨询 — 向用户介绍团队机制、了解需求
23	2. 确认方案 — 汇总需求，让用户确认团队配置
24	3. 创建规划文件（含智能体子目录）
25	4. 创建团队 + 生成智能体
26	5. 确认设置 + 引导用户压缩上下文
27
28	## 第 0 步 Update Check：版本自检（自动 — 在一切之前，~2 秒）
29
30	在进入任何其他步骤之前，做一次轻量的版本检查。不需要用户同意，不要问任何问题。
31
32	1. 远程版本：WebFetch `https://raw.githubusercontent.com/jessepwj/CCteam-creator/master/.claude-plugin/plugin.json`，prompt 写："What is the value of the version field? Respond with just the version string."
33	2. 本地版本：用 Bash 读本地 plugin.json（按顺序试以下路径，用第一个存在的）：
34
35	```bash
36	cat ~/.claude/plugins/cache/ccteam/CCteam-creator/*/.claude-plugin/plugin.json 2>/dev/null \|\| \
37	cat ~/.claude/plugins/cache/ccteam/CCteam-creator-cn/*/.claude-plugin/plugin.json 2>/dev/null \|\| \
38	cat ~/.claude/skills/CCteam-creator/.claude-plugin/plugin.json 2>/dev/null
39	```
40
41	从输出中提取 version 字段。
42	3. 对比：
43	- 远程 ≤ 本地或 WebFetch 失败或本地 plugin.json 找不到 → 完全静默跳过，直接进入下一步。不要打印"版本检查通过"之类的确认
44	- 远程 > 本地 → 打印一行通知（仅一行，然后立即继续，不等用户回复）：
45	> ℹ️ CCteam-creator 有新版本可用（<本地版本> → <远程版本>）。下次启动 Claude Code 时自动生效，本次 session 继续使用 <本地版本>。如需立即生效：`/plugin marketplace update ccteam` → `/exit` → 重启 → 重新触发本 skill。
46
47	硬性规则：
48	- ❌ 不要问用户"是否继续使用旧版本" — 不要做任何确认
49	- ❌ 不要尝试 Bash 更新 plugin 缓存 — 那是 Claude Code 的职责，不是 skill 的
50	- ❌ 不要把版本检查作为 TodoWrite/TaskCreate 里的可见任务 — 它应当在后台无感完成
51	- ❌ 如果网络失败，不要重试 — 直接进入下一步
52	- ✅ 最多一行通知，然后立即进入下一步
53
54	## 第 0 步 Detect：检测已有项目（自动 — 在一切之前）
55
56	开始搭建前，检查当前工作目录是否存在 `.plans/` 目录。
57
58	如果 `.plans/` 存在：
59
60	1. 读取项目 CLAUDE.md（自动加载）获取团队花名册和项目上下文
61	2. 扫描 `.plans/` 的项目目录——如有多个则列出
62	3. 告诉用户："发现已有项目 [名称]，团队成员 [花名册]。恢复该项目还是新建？"
63	4. 恢复：
64	a. 检查 `.plans/<project>/team-snapshot.md` 是否存在
65	b. 如快照存在：读快照头的元数据。对比 skill 源文件时间戳 vs 快照生成时间：
66	- 源文件未变：使用快照中的缓存入职 prompt，直接启动智能体（跳过读 skill 参考文件）
67	- 源文件已变：通知用户："Skill 文件在快照生成后被修改了。用缓存配置快速恢复，还是重新读最新 skill 文件来获取最新协议？"用户选择
68	c. 快照不存在：回退为读所有 skill 参考文件（onboarding.md、roles.md）来重建入职 prompt，然后启动智能体
69	d. 启动后，检查 TaskList / 读取各 agent progress 文件接续工作
70	5. 新建：正常进入第 1 步
71
72	如果 `.plans/` 不存在：直接跳到第 1 步。
73
74	## 第 1 步：需求咨询（先沟通，后动手）
75
76	这一步的目标：让用户充分理解团队是怎么运作的，同时收集用户的真实需求。不要急于创建任何文件或团队。
77
78	### 1.1 向用户介绍团队机制
79
80	用自然对话的方式（不要照搬下面的原文，根据上下文灵活表达），向用户解释以下要点：
81
82	团队是什么：
83
84	- 你（Claude）作为 team-lead，会同时指挥多个 AI 智能体并行工作
85	- Team-lead 是主对话的控制平面，不是一个被生成的 teammate
86	- 每个智能体有明确的角色分工（开发、研究、测试、审查等）
87	- 智能体之间可以直接沟通（如 dev 直接找 reviewer 审查代码）
88	- 所有进度通过文件系统持久化，不怕上下文丢失
89
90	适合什么场景：
91
92	- 多模块并行开发的项目（前后端同时推进）
93	- 需要调研 + 开发 + 测试多阶段协作的任务
94	- 代码量较大，需要审查和质量把关的项目
95
96	运作逻辑：
97
98	- team-lead（你自己）负责分配任务、协调进度、做决策
99	- team-lead 还负责用户对齐、阶段推进以及团队持久化运营规则的维护
100	- 每个智能体有自己的工作目录（`.plans/<项目>/`），记录任务、发现和进度
101	- 智能体遇到问题会上报 team-lead，team-lead 裁决后给出方向
102	- 代码开发完成后，dev 会自动找 reviewer 做代码审查
103
104	### 1.2 了解用户需求
105
106	在介绍完机制后，通过对话了解：
107
108	1. 工作语言 — 观察用户使用的语言。如果用户用中文沟通，团队默认中文回复；如果用户用英文沟通，团队应使用英文，不要把"默认中文回复"写入 CLAUDE.md 和入职 prompt
109	2. 任务类型 — 是软件开发、调研分析、内容创作、数据处理，还是混合型？这决定了标准角色是否直接适用还是需要调整
110	3. 用户想达成什么 — 项目目标、交付物、成功标准
111	4. 当前状态 — 是从零开始还是有已有工作？已有哪些工具/技术/资源？
112	5. 用户的参与度 — 想全程参与决策，还是希望团队自主推进？
113	6. 特殊要求 — 领域特定标准、质量要求、时间约束
114	7. 质量优先级 — 除了"代码能工作"外，这个项目最重视什么？例子：产品深度（处理真实用户会遇到的边界情况）、视觉精美、性能、API 设计优雅、测试覆盖深度。这些会成为 Review Dimensions（reviewer 在每次审查时评分）。推荐 3-5 个维度，各配一个权重（高/中/低）和具体的校准例子（这个项目中 STRONG vs WEAK 是什么样的）
115
116	注意：不要一次性抛出所有问题。根据用户的回答逐步深入，像正常对话一样自然交流。如果用户的需求已经很清晰，可以跳过部分问题。
117
118	### 1.3 推荐团队配置
119
120	根据用户需求，推荐合适的角色组合。解释每个角色的作用和为什么推荐它。
121
122	以下标准角色为软件开发项目优化。对于非软件或混合型任务，团队框架是通用的（文件持久化、任务文件夹、阶段门禁、审查协议）——但角色应根据实际工作调整。参见下方"非软件项目适配"。
123
124	可用的标准角色（软件开发）：
125
126
127	\| 角色 \| 名称 \| 参考智能体 \| model \| 核心能力 \|
128	\| ----- \| ------------ \| ---------------- \| ------ \| --------------------------- \|
129	\| 后端开发 \| backend-dev \| tdd-guide \| sonnet \| 写代码 + TDD

People who liked this also viewed

6 picks

Type

CCteam-creator-cn

301stars46forks

View on GitHub

How to install CCteam-creator-cn?

jessepwj/ccteam-creator/ccteam-creator-cn

$npx -y skills add jessepwj/CCteam-creator --skill CCteam-creator-cn

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# 团队项目设置
2
3	为复杂项目设置多智能体团队，使用持久化文件进行规划和进度追踪。
4
5	## 前置条件
6
7	在开始第 1 步之前，你（team-lead）必须直接读取所有参考文件到自己的上下文中：
8
9	```
10	Read references/onboarding.md
11	Read references/templates.md
12	Read references/roles.md
13	```
14
15	不要委托给子智能体（Explore、general-purpose 等）去读取。子智能体只会返回摘要，丢失关键细节——你需要完整的模板和入职 prompt 才能正确生成文件和启动智能体。
16
17	## 流程
18
19	第 0 步 Update Check（自动）：后台拉取最新 version 对比本地，如有新版一行通知后继续
20	第 0 步 Detect（自动）：检查 `.plans/` 是否已存在 → 如有，提供恢复选项
21
22	1. 需求咨询 — 向用户介绍团队机制、了解需求
23	2. 确认方案 — 汇总需求，让用户确认团队配置
24	3. 创建规划文件（含智能体子目录）
25	4. 创建团队 + 生成智能体
26	5. 确认设置 + 引导用户压缩上下文
27
28	## 第 0 步 Update Check：版本自检（自动 — 在一切之前，~2 秒）
29
30	在进入任何其他步骤之前，做一次轻量的版本检查。不需要用户同意，不要问任何问题。
31
32	1. 远程版本：WebFetch `https://raw.githubusercontent.com/jessepwj/CCteam-creator/master/.claude-plugin/plugin.json`，prompt 写："What is the value of the version field? Respond with just the version string."
33	2. 本地版本：用 Bash 读本地 plugin.json（按顺序试以下路径，用第一个存在的）：
34
35	```bash
36	cat ~/.claude/plugins/cache/ccteam/CCteam-creator/*/.claude-plugin/plugin.json 2>/dev/null \|\| \
37	cat ~/.claude/plugins/cache/ccteam/CCteam-creator-cn/*/.claude-plugin/plugin.json 2>/dev/null \|\| \
38	cat ~/.claude/skills/CCteam-creator/.claude-plugin/plugin.json 2>/dev/null
39	```
40
41	从输出中提取 version 字段。
42	3. 对比：
43	- 远程 ≤ 本地或 WebFetch 失败或本地 plugin.json 找不到 → 完全静默跳过，直接进入下一步。不要打印"版本检查通过"之类的确认
44	- 远程 > 本地 → 打印一行通知（仅一行，然后立即继续，不等用户回复）：
45	> ℹ️ CCteam-creator 有新版本可用（<本地版本> → <远程版本>）。下次启动 Claude Code 时自动生效，本次 session 继续使用 <本地版本>。如需立即生效：`/plugin marketplace update ccteam` → `/exit` → 重启 → 重新触发本 skill。
46
47	硬性规则：
48	- ❌ 不要问用户"是否继续使用旧版本" — 不要做任何确认
49	- ❌ 不要尝试 Bash 更新 plugin 缓存 — 那是 Claude Code 的职责，不是 skill 的
50	- ❌ 不要把版本检查作为 TodoWrite/TaskCreate 里的可见任务 — 它应当在后台无感完成
51	- ❌ 如果网络失败，不要重试 — 直接进入下一步
52	- ✅ 最多一行通知，然后立即进入下一步
53
54	## 第 0 步 Detect：检测已有项目（自动 — 在一切之前）
55
56	开始搭建前，检查当前工作目录是否存在 `.plans/` 目录。
57
58	如果 `.plans/` 存在：
59
60	1. 读取项目 CLAUDE.md（自动加载）获取团队花名册和项目上下文
61	2. 扫描 `.plans/` 的项目目录——如有多个则列出
62	3. 告诉用户："发现已有项目 [名称]，团队成员 [花名册]。恢复该项目还是新建？"
63	4. 恢复：
64	a. 检查 `.plans/<project>/team-snapshot.md` 是否存在
65	b. 如快照存在：读快照头的元数据。对比 skill 源文件时间戳 vs 快照生成时间：
66	- 源文件未变：使用快照中的缓存入职 prompt，直接启动智能体（跳过读 skill 参考文件）
67	- 源文件已变：通知用户："Skill 文件在快照生成后被修改了。用缓存配置快速恢复，还是重新读最新 skill 文件来获取最新协议？"用户选择
68	c. 快照不存在：回退为读所有 skill 参考文件（onboarding.md、roles.md）来重建入职 prompt，然后启动智能体
69	d. 启动后，检查 TaskList / 读取各 agent progress 文件接续工作
70	5. 新建：正常进入第 1 步
71
72	如果 `.plans/` 不存在：直接跳到第 1 步。
73
74	## 第 1 步：需求咨询（先沟通，后动手）
75
76	这一步的目标：让用户充分理解团队是怎么运作的，同时收集用户的真实需求。不要急于创建任何文件或团队。
77
78	### 1.1 向用户介绍团队机制
79
80	用自然对话的方式（不要照搬下面的原文，根据上下文灵活表达），向用户解释以下要点：
81
82	团队是什么：
83
84	- 你（Claude）作为 team-lead，会同时指挥多个 AI 智能体并行工作
85	- Team-lead 是主对话的控制平面，不是一个被生成的 teammate
86	- 每个智能体有明确的角色分工（开发、研究、测试、审查等）
87	- 智能体之间可以直接沟通（如 dev 直接找 reviewer 审查代码）
88	- 所有进度通过文件系统持久化，不怕上下文丢失
89
90	适合什么场景：
91
92	- 多模块并行开发的项目（前后端同时推进）
93	- 需要调研 + 开发 + 测试多阶段协作的任务
94	- 代码量较大，需要审查和质量把关的项目
95
96	运作逻辑：
97
98	- team-lead（你自己）负责分配任务、协调进度、做决策
99	- team-lead 还负责用户对齐、阶段推进以及团队持久化运营规则的维护
100	- 每个智能体有自己的工作目录（`.plans/<项目>/`），记录任务、发现和进度
101	- 智能体遇到问题会上报 team-lead，team-lead 裁决后给出方向
102	- 代码开发完成后，dev 会自动找 reviewer 做代码审查
103
104	### 1.2 了解用户需求
105
106	在介绍完机制后，通过对话了解：
107
108	1. 工作语言 — 观察用户使用的语言。如果用户用中文沟通，团队默认中文回复；如果用户用英文沟通，团队应使用英文，不要把"默认中文回复"写入 CLAUDE.md 和入职 prompt
109	2. 任务类型 — 是软件开发、调研分析、内容创作、数据处理，还是混合型？这决定了标准角色是否直接适用还是需要调整
110	3. 用户想达成什么 — 项目目标、交付物、成功标准
111	4. 当前状态 — 是从零开始还是有已有工作？已有哪些工具/技术/资源？
112	5. 用户的参与度 — 想全程参与决策，还是希望团队自主推进？
113	6. 特殊要求 — 领域特定标准、质量要求、时间约束
114	7. 质量优先级 — 除了"代码能工作"外，这个项目最重视什么？例子：产品深度（处理真实用户会遇到的边界情况）、视觉精美、性能、API 设计优雅、测试覆盖深度。这些会成为 Review Dimensions（reviewer 在每次审查时评分）。推荐 3-5 个维度，各配一个权重（高/中/低）和具体的校准例子（这个项目中 STRONG vs WEAK 是什么样的）
115
116	注意：不要一次性抛出所有问题。根据用户的回答逐步深入，像正常对话一样自然交流。如果用户的需求已经很清晰，可以跳过部分问题。
117
118	### 1.3 推荐团队配置
119
120	根据用户需求，推荐合适的角色组合。解释每个角色的作用和为什么推荐它。
121
122	以下标准角色为软件开发项目优化。对于非软件或混合型任务，团队框架是通用的（文件持久化、任务文件夹、阶段门禁、审查协议）——但角色应根据实际工作调整。参见下方"非软件项目适配"。
123
124	可用的标准角色（软件开发）：
125
126
127	\| 角色 \| 名称 \| 参考智能体 \| model \| 核心能力 \|
128	\| ----- \| ------------ \| ---------------- \| ------ \| --------------------------- \|
129	\| 后端开发 \| backend-dev \| tdd-guide \| sonnet \| 写代码 + TDD

People who liked this also viewed

6 picks

Type