这份文档讨论的是一组“很有价值，但不适合直接塞进项目模板默认目录”的进阶能力：
- task system
- agent teams
- 多会话协作
它们和 commands、skills、agents 不冲突，但层级不同。
前者更像：
- 用户或团队的协作操作系统
后者更像：
- 当前仓库里的项目能力与执行手册
很多团队在项目模板刚刚建立时，就容易产生一个冲动：
- “既然 tasks 和 teams 很强，那是不是也应该直接放进
project-root/？”
通常不建议这么做。
原因不是它们没用，而是：
- 它们更偏工作方式，不只是项目结构
- 它们经常跨多个仓库使用
- 它们往往和个人账号、个人习惯或组织协作流程绑定
- 一旦默认塞进模板，新读者会很难分清“哪些是项目必需，哪些是进阶增强”
所以更好的方式通常是：
- 先在
docs/里讲清楚能力边界 - 再由具体团队决定是否启用
这里说的 task system，不是普通待办列表，而是围绕 Claude Code 的任务拆分和状态管理能力。
它通常适合回答：
- 现在有哪些并行任务
- 每个任务的状态是什么
- 哪些任务已经交给不同会话或不同角色推进
- 哪些任务需要后续追踪
它的价值主要在于：
- 降低并行工作时的信息散落
- 让长链路任务不必全靠一段聊天历史维持
- 让“后面继续做”有更清晰的承接点
agent teams 更像一层协作编排能力。
它解决的问题通常是：
- 一个复杂任务需要多个稳定视角长期配合
- 这些视角不只是临时调用一下 reviewer
- 团队希望把分工模式长期化、结构化
例如：
- 前端方向的人持续盯交互质量
- 后端方向的人持续盯接口和权限
- 测试方向的人持续盯关键链路回归
这时，agent teams 的意义在于：
- 把协作关系从“临时串联”提升到“长期组织”
这是最容易混淆的一点。
项目里的 agent 通常是：
- 当前仓库里的一个稳定视角
- 解决某类评审或分析问题
例如：
frontend-reviewerbackend-reviewere2e-reviewer
subagent 更像：
- 一次任务中的临时分工单位
它通常用于：
- 当前问题太复杂，需要拆给另一个视角短时间处理
agent team 更像：
- 多个长期视角的编排关系
- 一套跨任务复用的协作组织
所以可以粗略理解成：
agent是角色subagent是临时调用agent team是长期编组
通常满足这些条件时，task system 开始有价值：
- 同时有多个并行任务
- 任务持续时间较长
- 任务之间存在依赖关系
- 单靠聊天线程已经很难追踪状态
- 团队需要“稍后继续”“换人继续”“异步继续”
如果只是：
- 单次小修复
- 一条短命令
- 一次性页面搭建
那通常没必要上 task system。
通常满足这些条件时，agent teams 开始有价值：
- 某类协作模式反复出现
- 每次都需要几个固定角色一起判断
- 团队希望把“怎么协作”也沉淀下来
- 单个 command 串技能已经不够表达长期分工
如果只是：
- 某一次任务临时叫几个 reviewer 看一眼
那更适合继续用 command + skill + agent 组合，而不是上升到 team。
project-root/ 的默认模板应该优先承载：
- 项目约定
- 高频入口
- 团队共享规则
- 最小可用工作流
task system 和 agent teams 如果默认塞进去，常见问题是：
- 新读者以为这是项目必须项
- 团队还没形成共识，就先背上了复杂度
- 个人工作方式和项目结构混在一起
- 模板不再“可复制即用”，而变成“需要先理解一套协作平台”
所以更稳妥的策略是：
- 默认模板不内置
- 文档说明先补齐
- 真正有需要时，再由团队在全局层或组织层启用
如果一个团队未来想用这类能力，推荐顺序通常是：
- 先把项目模板本身跑顺
- 先让
commands、skills、agents分工清楚 - 再让
memory和settings稳定下来 - 并行任务真的多起来后，再考虑 task system
- 长期协作模式真的固定下来后，再考虑 agent teams
这个顺序的核心是：
- 先解决项目内协作
- 再解决跨任务协作
- 最后才解决跨会话 / 跨角色编排
通常更推荐：
- 放在用户全局层
- 或放在团队另行约定的协作层
而不是直接放进每个业务仓库的默认 project-root/。
因为它们更多回答的是：
- 这个团队跨项目怎么工作
而不是：
- 这个仓库内部结构长什么样
对 claude-directory 来说，这篇文档的定位是：
- 说明进阶协作能力存在
- 说明它和项目模板的边界
- 说明什么时候值得上升到这一层
它的定位不是：
- 要求所有使用者现在就启用 tasks
- 要求所有项目都定义 agent teams
- 把平台级协作系统直接复制进模板
- 先把项目模板做小、做稳
- 先把 command / skill / agent 用顺
- 当并行任务明显增多时，再考虑 task system
- 当长期协作模式稳定复现时，再考虑 agent teams
- 这类能力优先写进文档说明，不要先做成项目默认结构
如果你正在理解这套目录，推荐阅读顺序是：
commands-vs-agents-vs-skills.mdglobal-vs-project-scope.md- 再读这篇 task / teams 文档
这样更容易先理解项目层，再理解进阶协作层。