"name": {
            "description": "Name for the spawned agent",
            "type": "string"
          },
          "team_name": {
            "description": "Team name for spawning. Uses current team context if omitted.",
            "type": "string"
          },
          "mode": {
            "description": "Permission mode for spawned teammate (e.g., \"plan\" to require plan approval).",
            "type": "string",
            "enum": [
              "acceptEdits",
              "bypassPermissions",
              "default",
              "delegate",
              "dontAsk",
              "plan"
            ]

{
  "type": "message",
  "recipient": "researcher",
  "content": "请开始调研认证模块",
  "summary": "认证模块调研任务分配"
}

{
  "type": "broadcast",
  "content": "发现严重 bug，所有人暂停当前工作",
  "summary": "紧急：发现阻塞性问题"
}

{
  "type": "shutdown_request",
  "recipient": "researcher",
  "content": "任务完成，准备结束会话"
}

{
  "type": "shutdown_response",
  "request_id": "abc-123",
  "approve": true
}

{
  "type": "shutdown_response",
  "request_id": "abc-123",
  "approve": false,
  "content": "任务 #3 还在进行中，还需要 5 分钟"
}

{
  "type": "plan_approval_response",
  "request_id": "abc-123",
  "recipient": "researcher",
  "approve": true
}

{
  "type": "plan_approval_response",
  "request_id": "abc-123",
  "recipient": "researcher",
  "approve": false,
  "content": "请为 API 调用添加错误处理"
}

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

---

我正在设计一个CLI工具，帮助开发者追踪代码库中的TODO注释。
请创建一个团队从不同角度来探讨这个问题：一位负责用户体验，一位负责技术架构，还有一位扮演"唱反调"的角色。

{
  "team_name": "todo-tracker-design",
  "description": "从UX、技术架构和批判性视角探讨TODO追踪CLI工具的设计"
}

{
  "subject": "从用户体验角度分析TODO追踪CLI工具设计",
  "description": "作为UX专家，深入分析一个帮助开发者追踪代码库中TODO注释的CLI工具的用户体验设计。需要涵盖：\n1. 目标用户画像和使用场景\n2. CLI交互设计（命令结构、输出格式、颜色方案）\n3. 工作流集成（如何融入开发者日常工作流）\n4. 信息层级和展示方式（如何让开发者快速获取关键信息）\n5. 与现有工具（IDE、CI/CD）的集成体验\n6. 具体的命令设计建议和示例\n\n请用简体中文输出，给出具体、可操作的建议。",
  "activeForm": "分析用户体验设计"
}

{
  "subject": "从技术架构角度分析TODO追踪CLI工具设计",
  "description": "作为技术架构师，深入分析一个帮助开发者追踪代码库中TODO注释的CLI工具的技术方案。需要涵盖：\n1. 核心解析引擎设计（如何高效扫描和解析不同语言的TODO注释）\n2. 数据模型设计（TODO的元数据结构：作者、日期、优先级、关联issue等）\n3. 存储方案（本地缓存、增量扫描、性能优化）\n4. 可扩展性设计（插件系统、自定义规则、多语言支持）\n5. 技术栈选择建议（语言、关键依赖库）\n6. 与Git集成的技术方案（blame信息、commit关联）\n7. 给出核心数据结构和架构图的文字描述\n\n请用简体中文输出，给出具体的技术方案。",
  "activeForm": "分析技术架构设计"
}

{
  "subject": "从批判性角度挑战TODO追踪CLI工具的设计假设",
  "description": "作为\"唱反调\"的角色（Devil's Advocate），对这个TODO追踪CLI工具的设想进行批判性审视。需要涵盖：\n1. 这个工具真的有必要吗？现有方案（grep、IDE内置搜索、GitHub Issues）有什么不足需要新工具来解决？\n2. TODO注释本身是不是一种代码异味（code smell）？鼓励追踪它们是否在纵容坏习惯？\n3. 可能的失败模式和风险（工具过期、维护负担、团队采用阻力）\n4. 竞品分析：市面上已有的类似工具（todo-tree、fixme、leasot等）和它们的不足\n5. 最可能让这个项目失败的三个原因\n6. 如果一定要做，什么是最小可行产品（MVP）应该聚焦的核心功能？\n7. 哪些功能看起来诱人但应该果断砍掉？\n\n请用简体中文输出，尖锐但建设性地提出挑战。",
  "activeForm": "从批判角度审视设计"
}

{
  "description": "UX专家分析TODO CLI",
  "subagent_type": "tr:investigator",
  "name": "ux-expert",
  "team_name": "todo-tracker-design",
  "prompt": "你是一位资深的CLI用户体验设计专家。请认领任务#1并完成它。\n\n你的角色：从开发者用户体验角度，深入分析一个帮助追踪代码库中TODO注释的CLI工具应该如何设计。\n\n请涵盖以下方面，给出具体、可操作的建议：\n\n1. **目标用户画像和使用场景**：谁会用这个工具？在什么场景下使用？\n2. **CLI交互设计**：命令结构设计（子命令、参数、flags）、输出格式、颜色方案、交互式模式等\n3. **工作流集成**：如何融入开发者的日常工作流（pre-commit hooks、CI/CD、编辑器集成等）\n4. **信息层级和展示方式**：如何让开发者快速获取关键信息，避免信息过载\n5. **与现有工具的集成体验**：IDE、GitHub/GitLab、项目管理工具等\n6. **具体的命令设计建议**：给出5-8个核心命令的具体示例和输出样例\n\n请参考优秀的CLI工具设计（如 gh, ripgrep, exa/eza, jq）的交互模式。\n用简体中文输出。完成后用 TaskUpdate 将任务标记为 completed，然后向 team-lead 发送消息汇报你的分析结果。"
}

{
  "taskId": "1",
  "owner": "ux-expert",
  "status": "in_progress"
}

{
  "taskId": "2",
  "owner": "architect",
  "status": "in_progress"
}

{
  "taskId": "3",
  "owner": "devils-advocate",
  "status": "in_progress"
}

# Agent Teammate Communication

IMPORTANT: You are running as an agent in a team. To communicate with anyone on your team:

- Use the SendMessage tool with type `message` to send messages to specific teammates
- Use the SendMessage tool with type `broadcast` sparingly for team-wide announcements

Just writing a response in text is not visible to others on your team - you MUST use the SendMessage tool.

The user interacts primarily with the team lead. Your work is coordinated through the task system and teammate messaging.

Notes:

- Agent threads always have their cwd reset between bash calls, as a result please only use absolute file paths.
- In your final response always share relevant file names and code snippets. Any file paths you return in your response MUST be absolute. Do NOT use relative paths.
- For clear communication with the user the assistant MUST avoid using emojis.
- Do not use a colon before tool calls. Text like \"Let me read the file:\" followed by a read tool call should just be \"Let me read the file.\" with a period.

Here is useful information about the environment you are running in:
<env>
Working directory: /Users/test/code/empty
Is directory a git repo: No
Platform: darwin
OS Version: Darwin 25.2.0
Today's date: 2026-02-07
</env>
You are powered by the model named Opus 4.6. The exact model ID is claude-opus-4-6.

Assistant knowledge cutoff is May 2025.

<claude_background_info>
The most recent frontier Claude model is Claude Opus 4.6 (model ID: 'claude-opus-4-6').
</claude_background_info>",

---

# Agent 队友沟通

重要提示：你正在作为团队中的一个 Agent 运行。与团队中的任何人沟通时：

- 使用 SendMessage 工具，类型设为 `message`，向特定队友发送消息
- 谨慎使用 SendMessage 工具，类型设为 `broadcast`，用于全团队公告

仅用文字回复对团队中的其他人是不可见的——你必须使用 SendMessage 工具。

用户主要与团队负责人交互。你的工作通过任务系统和队友消息进行协调。

注意事项：

- Agent 线程在每次 bash 调用之间会重置当前工作目录，因此请只使用绝对文件路径。
- 在最终回复中，请务必分享相关的文件名和代码片段。回复中返回的任何文件路径必须是绝对路径，不要使用相对路径。
- 为了与用户清晰沟通，助手必须避免使用表情符号。
- 在调用工具之前不要使用冒号。例如"让我读取这个文件："后接读取工具调用，应该改为"让我读取这个文件。"使用句号结尾。

以下是你运行环境的有用信息：
<env>
工作目录：/Users/test/code/empty
该目录是否为 git 仓库：否
平台：darwin
操作系统版本：Darwin 25.2.0
今天的日期：2026-02-07
</env>
你由名为 Opus 4.6 的模型驱动。确切的模型 ID 是 claude-opus-4-6。

助手的知识截止日期是 2025 年 5 月。

<claude_background_info>
最新的前沿 Claude 模型是 Claude Opus 4.6（模型 ID：'claude-opus-4-6'）。
</claude_background_info>",

<teammate-message teammate_id="team-lead" summary="反对者挑战TODO CLI">
你是一位经验丰富的"唱反调"角色（Devil's Advocate）。请认领任务#3并完成它。

你的角色：对这个"帮助开发者追踪代码库中TODO注释的CLI工具"进行尖锐但建设性的批判。你的工作是确保团队不会盲目乐观，能看到潜在的问题和风险。

请先搜索一下市面上已有的类似工具和竞品情况，然后涵盖以下方面：

1. **必要性质疑**：这个工具真的有必要吗？`grep -rn "TODO" .` 有什么不够用的？IDE内置的TODO面板、GitHub Issues、Jira等工具已经能解决这个问题了吗？
2. **TODO本身的问题**：TODO注释是否本身就是代码异味？追踪它们是在解决问题还是在纵容坏习惯？
3. **竞品分析**：搜索市面上已有的类似工具（如 todo-tree VS Code插件、leasot、fixme、todo-txt 等），它们做得怎么样？为什么还需要一个新的？
4. **失败风险**：最可能让这个项目失败的3-5个原因
5. **范围蔓延风险**：哪些功能看起来诱人但应该果断砍掉？
6. **采用阻力**：开发团队为什么可能不愿意用这个工具？
7. **如果一定要做**：MVP应该聚焦什么？什么是这个工具能提供的、现有方案真正缺失的独特价值？

请尖锐但建设性。目标不是否定这个项目，而是帮助团队做出更好的决策。
用简体中文输出。完成后用 TaskUpdate 将任务标记为 completed，然后向 team-lead 发送消息汇报你的分析结果。
</teammate-message>