team-solve

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Team Solve

团队协作解决问题

Investigate and solve one or more problems using parallel research, then serial implementation.

通过并行研究、串行实施的方式调查并解决一个或多个问题。

When to Use

适用场景

A task with multiple distinct problems or themes to address
A codebase change that benefits from researching several areas at once
Work that can be decomposed into independent investigation tracks
Situations where you want structured evidence-gathering before making changes

包含多个不同问题或主题的任务
可通过同时研究多个领域获益的代码库变更
可分解为独立调查路径的工作
需要在做出变更前进行结构化证据收集的场景

Instructions for Claude

给Claude的指令

You are the team lead orchestrating an investigate-then-solve workflow.

你是负责协调“先调查后解决”工作流的团队负责人。

Phase 1: Problem Decomposition

阶段1：问题分解

Parse the user's input to identify distinct problems or themes
If the problems are ambiguous or underspecified, ask clarifying questions before proceeding
Group related problems into 2-5 investigation tracks (one per teammate)
Present the decomposition to the user:
- List each track with its assigned problems
- Name each teammate descriptively (e.g.,
```
filter-investigator
```
  ,
```
output-researcher
```
  )
- Ask: "I'll spin up N investigators in parallel. Proceed?"

解析用户输入，识别不同的问题或主题
如果问题模糊或描述不明确，先提出澄清问题再继续
将相关问题分组为2-5个调查路径（每个路径分配给一名团队成员）
向用户展示分解结果：
- 列出每个路径及其分配的问题
- 给每个团队成员起一个描述性的名字（例如
```
filter-investigator
```
  、
```
output-researcher
```
  ）
- 询问：“我将并行启动N名调查人员。是否继续？”

Phase 2: Parallel Investigation

阶段2：并行调查

Investigations run in parallel.

Create a team with
```
TeamCreate
```
Create tasks for each investigation track with
```
TaskCreate
```
Spawn one
```
general-purpose
```
teammate per track using
```
Task
```
with
```
team_name
```
- Each teammate's prompt must include:
  - The specific problems to investigate
  - Instruction to research only, do not make changes
  - The subagent guidance below (copy it into their prompt)
  - Instruction to report findings via
```
SendMessage
```
    using the report format below
- Spawn all investigators in parallel — do not wait for one to finish before starting the next
Do NOT shut down investigators when they report back — they retain context for Phase 4

调查工作并行开展。

使用
```
TeamCreate
```
创建团队
使用
```
TaskCreate
```
为每个调查路径创建任务
使用带有
```
team_name
```
参数的
```
Task
```
为每个路径生成一名
```
general-purpose
```
（通用型）团队成员
- 每个团队成员的提示语必须包含：
  - 需调查的具体问题
  - 仅进行研究、不做变更的指令
  - 下方的子Agent指导（复制到他们的提示语中）
  - 使用
```
SendMessage
```
    按照下方报告格式提交调查结果的指令
- 并行生成所有调查人员——不要等待一个完成后再启动下一个
调查人员提交报告后不要关闭他们——他们需要保留上下文以用于阶段4

Subagent Guidance for Investigators

调查人员的子Agent指导

Include the following in each investigator's prompt:

Use subagents (
Task
tool) to keep your context focused. Spawn subagents for:
Exploring specific files, modules, or subsystems

Searching through git history, logs, or large codebases

Any research tangent that might not pan out

Each subagent should report back:

Relevant findings — what it discovered that matters to your investigation

Red herrings (1-2 sentences) — anything that looks related but isn't, and why. Calling these out early prevents wasted cycles re-exploring dead ends.

Report red herrings even when your main findings are conclusive — they prevent other agents from re-exploring the same dead ends.

After receiving a subagent's report, decide whether to:

Use its findings directly — if the summary gives you enough to proceed

Dive in yourself — if the subagent found something promising and you want full, first-hand context in that area before drawing conclusions. Examples: conflicting evidence that needs direct examination, low confidence in the subagent's assessment, or complex state/flow where first-hand context matters.

When choosing subagent types, prefer read-only or exploration-focused types for open-ended codebase searches, and full-capability types for targeted analysis that needs deeper tool access.

在每个调查人员的提示语中包含以下内容：

使用子Agent（
Task
工具）保持你的上下文聚焦。在以下场景生成子Agent：
探索特定文件、模块或子系统

搜索git历史、日志或大型代码库

任何可能没有结果的研究分支

每个子Agent应返回以下内容：

相关发现——与你的调查相关的重要发现

干扰项（1-2句话）——看似相关但实际无关的内容，以及原因。尽早指出这些内容可避免重复探索无效路径。

即使你的主要发现是确定的，也要报告干扰项——这能防止其他Agent重复探索相同的无效路径。

收到子Agent的报告后，决定：

直接使用其发现——如果摘要足够支撑你继续推进

亲自深入研究——如果子Agent发现了有前景的内容，且你需要该领域的完整一手上下文才能得出结论。例如：需要直接检查的矛盾证据、对子Agent评估的低信心、或需要一手上下文的复杂状态/流程。

选择子Agent类型时，针对开放式代码库搜索优先选择只读或探索型类型，针对需要更深工具访问的定向分析选择全功能类型。

Investigator Report Format

调查人员报告格式

Each investigator should structure their report as:

undefined

每个调查人员的报告应按以下结构撰写：

undefined

Track: {description}

Findings

{what was discovered, root causes, relevant code paths}

{what was discovered, root causes, relevant code paths}

Proposed Approach

{what to change, which files, how}

{what to change, which files, how}

Risks & Edge Cases

{what could go wrong with this approach}
{what adjacent code/features could be affected}
{what happens if data is unexpected or flow is interrupted}

{what could go wrong with this approach}
{what adjacent code/features could be affected}
{what happens if data is unexpected or flow is interrupted}

Red Herrings

{things explored that weren't relevant, and why}

{things explored that weren't relevant, and why}

Confidence: {high/medium/low}

{brief justification}

Dependencies

{does this approach depend on or conflict with other tracks?}

undefined

{does this approach depend on or conflict with other tracks?}

undefined

Phase 3: Discussion Checkpoint

阶段3：讨论检查点

As investigators report back, give the user brief progress updates — don't wait silently for all of them
Once all investigators have reported, synthesize findings:
- Key findings per track
- Proposed approaches and confidence levels
- Any conflicts or dependencies between tracks
- Ripple effects — Evaluate across all tracks:
  - "What happens to..." — documentation, adjacent features, API consumers, shared state, caching
  - "What happens if..." — unexpected data, interrupted flows, concurrent access, rollback
- Recommended implementation order (dependencies first, then highest-risk, then the rest)
If investigation reveals the problem is different than expected, say so — propose revised tracks rather than forcing the original plan
Ask the user: "Ready to implement, or want to revise the approach?"

调查人员提交报告时，向用户提供简短的进度更新——不要沉默等待所有报告完成
所有调查人员提交报告后，综合发现：
- 每个路径的关键发现
- 提议的解决方案和信心水平
- 各路径之间的任何冲突或依赖关系
- 连锁影响——跨所有路径评估：
  - “……会发生什么”——文档、相邻功能、API消费者、共享状态、缓存
  - “如果……会发生什么”——意外数据、流程中断、并发访问、回滚
- 推荐的实施顺序（先处理依赖项，再处理高风险项，最后处理其他项）
如果调查发现问题与预期不同，如实告知用户——提议修改路径，而非强行执行原计划
询问用户：“是否准备实施，还是想要修改方案？”

Phase 4: Serial Implementation

阶段4：串行实施

Implementations happen one track at a time. This prevents:

Mixed, unrelated work in a single commit
Confusing build/test failures caused by concurrent changes in flight
File conflicts when teammates touch shared code

For each track (in the order agreed with the user):
- Message the original investigator to begin implementation via
```
SendMessage
```
- Assign their implementation task via
```
TaskUpdate
```
- Include the subagent guidance for implementation below in your message
- When starting subsequent tracks, forward the previous track's "what changed" summary so the investigator has implementation context, not just investigation context
- Wait for completion before starting the next track
- After each track completes, have the teammate report what changed
- Run relevant tests/checks as a quick sanity check before moving to the next track
Parallel exception: Only consider parallel implementation if tracks have zero file overlap AND the codebase has no shared build/test pipeline that could produce confusing interleaved failures. If you think parallel is safe, explain why and ask the user.
Partial failures:
- If an investigator reported low confidence or found nothing actionable, discuss with the user before implementing — options are to drop the track, merge it into another, or investigate further
- If implementation fails mid-track, stop and discuss with the user whether to roll back or adjust the approach before continuing to the next track

实施工作逐个路径进行。这可避免：

单次提交中包含混合、无关的工作
并发变更导致的构建/测试失败难以排查
团队成员修改共享代码时的文件冲突

针对每个路径（按照与用户商定的顺序）：
- 使用
```
SendMessage
```
  通知对应的原调查人员开始实施
- 使用
```
TaskUpdate
```
  分配实施任务
- 在消息中包含下方的实施子Agent指导
- 启动后续路径时，转发前一个路径的“变更内容”摘要，以便调查人员拥有实施上下文（而非仅调查上下文）
- 等待一个路径完成后再启动下一个
- 每个路径完成后，让团队成员报告变更内容
- 进行相关测试/检查作为快速验证，再进入下一个路径
并行例外情况：仅当路径之间完全没有文件重叠，且代码库没有可能产生混淆的交错失败的共享构建/测试流水线时，才考虑并行实施。如果认为并行是安全的，说明原因并询问用户。
部分失败处理：
- 如果调查人员报告信心低或未找到可行方案，实施前与用户讨论——选项包括放弃该路径、合并到其他路径或进一步调查
- 如果实施中途失败，停止并与用户讨论是否回滚或调整方案后再继续

Subagent Guidance for Implementation

实施的子Agent指导

Include the following when sending implementation instructions:

Use subagents to keep your main context focused on implementation logic. Spawn subagents for:

Repetitive edits — similar changes across many files (updating imports, renaming across test files, applying a pattern to multiple modules)

Impact analysis — finding all callers of a function before changing its signature, checking all consumers of an API

Exploratory reading — checking whether a module's assumptions break with your change, verifying edge cases in adjacent code

Background test runs — running tests while you continue working on the next change

发送实施指令时包含以下内容：

使用子Agent让你的主要上下文聚焦于实施逻辑。 在以下场景生成子Agent：

重复编辑——跨多个文件的相似变更（更新导入、跨测试文件重命名、对多个模块应用相同模式）

影响分析——修改函数签名前查找所有调用者，检查API的所有消费者

探索性阅读——检查模块的假设是否会因你的变更而失效，验证相邻代码的边缘情况

后台测试运行——在你继续处理下一个变更时运行测试

Phase 5: Validation

阶段5：验证

Spawn a fresh
```
general-purpose
```
teammate named
```
validator
```
. The validator's spawn prompt must include: the original problems from Phase 1, the agreed implementation approach from Phase 3, and risk areas flagged by investigators. Instruct the validator to:
- Detect the project's test/lint/typecheck tooling and run appropriate checks
- Review all changed files for correctness and consistency
- Check that each problem from Phase 1 is actually addressed
- Look for unintended side effects or regressions
- Report pass/fail with details via
```
SendMessage
```
If validation fails:
- Route failures back to the responsible investigator for fixes
- Re-run validation after fixes
Once validation passes, shut down all teammates and report results to the user

生成一名新的
```
general-purpose
```
团队成员，命名为
```
validator
```
（验证者）。生成验证者的提示语必须包含：阶段1的原始问题、阶段3商定的实施方案，以及调查人员标记的风险区域。指示验证者：
- 识别项目的测试/ lint/类型检查工具并运行相应检查
- 审查所有变更文件的正确性和一致性
- 检查阶段1的每个问题是否真的得到解决
- 查找意外的副作用或回归问题
- 通过
```
SendMessage
```
  报告验证结果（通过/不通过）及细节
如果验证失败：
- 将失败情况反馈给负责的调查人员进行修复
- 修复后重新运行验证
验证通过后，关闭所有团队成员并向用户报告结果

Rules

规则

Investigate in parallel, implement in series — research benefits from parallelism; implementation benefits from sequencing
Subagents are cheap, context is expensive — teammates should offload research tangents and repetitive edits to subagents rather than doing everything inline
3-5 teammates max — if more problems than that, group into themes
Never
git add .
— teammates must add specific files
Validator is always fresh — do not reuse an investigator as validator
If a teammate goes idle, that's normal — send them a message when it's their turn

并行调查，串行实施——研究可从并行中获益；实施可从顺序执行中获益
子Agent成本低，上下文成本高——团队成员应将研究分支和重复编辑工作委托给子Agent，而非全部自行处理
最多3-5名团队成员——如果问题超过这个数量，按主题分组
禁止使用
git add .
——团队成员必须添加特定文件
验证者必须是新生成的——不要重用调查人员作为验证者
如果团队成员处于空闲状态，这是正常的——轮到他们时发送消息即可