/CCteam-creator-cn

name: CCteam-creator-cn
description: >
  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-cn with a project name, (4) user wants to organize a multi-phase project
  with parallel agent workers and persistent progress tracking. Creates TeamCreate, planning
  files (.plans/project/), per-agent work directories, and spawns configured
  teammates. TRIGGER on: "team", "swarm", "start project", "set up project", "create team
  for", "build team", "organize project", "multi-agent project".
  IMPORTANT: You (team-lead) MUST read all reference files directly — do NOT delegate to subagents.
  NOTE: After initial setup, you can add new teammates at any time — just spawn a new Agent with the team_name and follow the same onboarding pattern. The team is not locked after creation.

团队项目设置

为复杂项目设置多智能体团队，使用持久化文件进行规划和进度追踪。

前置条件

**在开始第 1 步之前**，你（team-lead）必须直接读取所有参考文件到自己的上下文中：

Read references/onboarding.md
Read references/templates.md
Read references/roles.md

不要委托给子智能体（Explore、general-purpose 等）去读取。子智能体只会返回摘要，丢失关键细节——你需要完整的模板和入职 prompt 才能正确生成文件和启动智能体。

流程

**第 0 步 Update Check（自动）**：后台拉取最新 version 对比本地，如有新版一行通知后继续 **第 0 步 Detect（自动）**：检查 `.plans/` 是否已存在 → 如有，提供恢复选项

1. **需求咨询** — 向用户介绍团队机制、了解需求 2. **确认方案** — 汇总需求，让用户确认团队配置 3. 创建规划文件（含智能体子目录） 4. 创建团队 + 生成智能体 5. 确认设置 + 引导用户压缩上下文

第 0 步 Update Check：版本自检（自动 — 在一切之前，~2 秒）

在进入任何其他步骤之前，做一次轻量的版本检查。**不需要用户同意，不要问任何问题。**

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." 2. **本地版本**：用 Bash 读本地 plugin.json（按顺序试以下路径，用第一个存在的）：

   cat ~/.claude/plugins/cache/ccteam/CCteam-creator/*/.claude-plugin/plugin.json 2>/dev/null || \
   cat ~/.claude/plugins/cache/ccteam/CCteam-creator-cn/*/.claude-plugin/plugin.json 2>/dev/null || \
   cat ~/.claude/skills/CCteam-creator/.claude-plugin/plugin.json 2>/dev/null

从输出中提取 version 字段。 3. **对比**：

• **远程 ≤ 本地** 或 **WebFetch 失败** 或 **本地 plugin.json 找不到** → **完全静默** 跳过，直接进入下一步。不要打印"版本检查通过"之类的确认
• **远程 > 本地** → 打印**一行**通知（仅一行，然后立即继续，不等用户回复）：

> ℹ️ CCteam-creator 有新版本可用（<本地版本> → <远程版本>）。下次启动 Claude Code 时自动生效，本次 session 继续使用 <本地版本>。如需立即生效：`/plugin marketplace update ccteam` → `/exit` → 重启 → 重新触发本 skill。

**硬性规则**：

• ❌ 不要问用户"是否继续使用旧版本" — 不要做任何确认
• ❌ 不要尝试 Bash 更新 plugin 缓存 — 那是 Claude Code 的职责，不是 skill 的
• ❌ 不要把版本检查作为 TodoWrite/TaskCreate 里的可见任务 — 它应当在后台无感完成
• ❌ 如果网络失败，**不要重试** — 直接进入下一步
• ✅ 最多一行通知，然后**立即**进入下一步

第 0 步 Detect：检测已有项目（自动 — 在一切之前）

开始搭建前，检查当前工作目录是否存在 `.plans/` 目录。

**如果 `.plans/` 存在**：

1. 读取项目 CLAUDE.md（自动加载）获取团队花名册和项目上下文 2. 扫描 `.plans/` 的项目目录——如有多个则列出 3. 告诉用户："发现已有项目 [名称]，团队成员 [花名册]。恢复该项目还是新建？" 4. **恢复**： a. 检查 `.plans/<project>/team-snapshot.md` 是否存在 b. **如快照存在**：读快照头的元数据。对比 skill 源文件时间戳 vs 快照生成时间：

• **源文件未变**：使用快照中的缓存入职 prompt，直接启动智能体（跳过读 skill 参考文件）
• **源文件已变**：通知用户："Skill 文件在快照生成后被修改了。用缓存配置快速恢复，还是重新读最新 skill 文件来获取最新协议？"用户选择

c. **快照不存在**：回退为读所有 skill 参考文件（onboarding.md、roles.md）来重建入职 prompt，然后启动智能体 d. 启动后，检查 TaskList / 读取各 agent progress 文件接续工作 5. **新建**：正常进入第 1 步

**如果 `.plans/` 不存在**：直接跳到第 1 步。

第 1 步：需求咨询（先沟通，后动手）

**这一步的目标**：让用户充分理解团队是怎么运作的，同时收集用户的真实需求。不要急于创建任何文件或团队。

1.1 向用户介绍团队机制

用自然对话的方式（不要照搬下面的原文，根据上下文灵活表达），向用户解释以下要点：

**团队是什么**：

• 你（Claude）作为 team-lead，会同时指挥多个 AI 智能体并行工作
• Team-lead 是**主对话的控制平面**，不是一个被生成的 teammate
• 每个智能体有明确的角色分工（开发、研究、测试、审查等）
• 智能体之间可以直接沟通（如 dev 直接找 reviewer 审查代码）
• 所有进度通过文件系统持久化，不怕上下文丢失

**适合什么场景**：

• 多模块并行开发的项目（前后端同时推进）
• 需要调研 + 开发 + 测试多阶段协作的任务
• 代码量较大，需要审查和质量把关的项目

**运作逻辑**：

• team-lead（你自己）负责分配任务、协调进度、做决策
• team-lead 还负责用户对齐、阶段推进以及团队持久化运营规则的维护
• 每个智能体有自己的工作目录（`.plans/<项目>/`），记录任务、发现和进度
• 智能体遇到问题会上报 team-lead，team-lead 裁决后给出方向
• 代码开发完成后，dev 会自动找 reviewer 做代码审查

1.2 了解用户需求

在介绍完机制后，通过对话了解：

1. **工作语言** — 观察用户使用的语言。如果用户用中文沟通，团队默认中文回复；如果用户用英文沟通，团队应使用英文，不要把"默认中文回复"写入 CLAUDE.md 和入职 prompt 2. **任务类型** — 是软件开发、调研分析、内容创作、数据处理，还是混合型？这决定了标准角色是否直接适用还是需要调整 3. **用户想达成什么** — 项目目标、交付物、成功标准 4. **当前状态** — 是从零开始还是有已有工作？已有哪些工具/技术/资源？ 5. **用户的参与度** — 想全程参与决策，还是希望团队自主推进？ 6. **特殊要求** — 领域特定标准、质量要求、时间约束 7. **质量优先级** — 除了"代码能工作"外，这个项目最重视什么？例子：产品深度（处理真实用户会遇到的边界情况）、视觉精美、性能、API 设计优雅、测试覆盖深度。这些会成为 Review Dimensions（reviewer 在每次审查时评分）。推荐 3-5 个维度，各配一个权重（高/中/低）和具体的校准例子（这个项目中 STRONG vs WEAK 是什么样的）

**注意**：不要一次性抛出所有问题。根据用户的回答逐步深入，像正常对话一样自然交流。如果用户的需求已经很清晰，可以跳过部分问题。

1.3 推荐团队配置

根据用户需求，推荐合适的角色组合。解释每个角色的作用和为什么推荐它。

**以下标准角色为软件开发项目优化。** 对于非软件或混合型任务，团队**框架**是通用的（文件持久化、任务文件夹、阶段门禁、审查协议）——但**角色应根据实际工作调整**。参见下方"非软件项目适配"。

可用的标准角色（软件开发）：

| 角色 | 名称 | 参考智能体 | model | 核心能力 | | ----- | ------------ | ---------------- | ------ | --------------------------- | | 后端开发 | backend-dev | tdd-guide | sonnet | 写代码 + TDD + 大任务按 task 分文件夹 | | 前端开发 | frontend-dev | tdd-guide | sonnet | 写代码 + TDD + 大任务按 task 分文件夹 | | 探索/研究 | researcher | — | sonnet | 代码搜索 + 网页搜索 + 只读不改代码 | | 联调测试 | e2e-tester | e2e-runner | sonnet | E2E 测试 + 浏览器自动化 + Bug 记录 | | 代码审查 | reviewer | code-reviewer | sonnet | 只读审查 + 安全/质量/性能深度检查 | | 管家 | custodian | refactor-cleaner | sonnet | 约束合规 + 文档治理 + 模式→自动化 + 代码清理 |

> **模型默认值**：所有角色默认使用 `sonnet`。仅在用户要求、不考虑成本、或角色涉及关键/复杂逻辑（如安全敏感审查、复杂业务逻辑）时，才将特定角色升级为 `opus`。不确定时在第 1 步与用户确认。

参见 [references/roles.md](references/roles.md) 了解角色详细定义和能力。

**推荐原则**：

• 不是角色越多越好，根据项目实际需要选择
• 小项目可能只需要 1 个 dev + 1 个 researcher
• 大项目可以配齐全部角色
• **多实例 researcher**：当调研工作量大到值得并行处理时，启动多个 researcher。两种模式：
• **按量拆分**（最常见）：同样的工作，按数量分。如 30 个源文件要分析 → researcher-1 负责模块 A-M，researcher-2 负责 N-Z。职责相同，纯粹靠并行加速
• **按方向拆分**：完全独立的调研主题。如技术选型 + 代码库分析 + 竞品调研——各自产出结论，互不依赖
• 按量拆分时按编号命名（`researcher-1`/`researcher-2`），按方向拆分时按方向命名（`researcher-api`/`researcher-arch`）。每