claude-devfleet

claude-devfleet 技能概览

claude-devfleet 的作用

claude-devfleet 是一个协调型技能，用于通过 Claude DevFleet 运行多智能体编程工作，而不是通用编程提示词。它的职责是把一个较大的工程需求拆成一组有计划的任务，分发到隔离的 git worktree 中，并返回结构化的进度与完成报告。

适合谁安装

这个 claude-devfleet 技能最适合已经有本地或团队 DevFleet 环境，并且希望进行带依赖顺序的并行执行的用户。它非常适合功能开发、重构、测试补齐，或天然可以拆成独立任务或分阶段任务的实施计划。如果你只需要改一个地方、改一个文件，或者快速得到一个答案，它就不太适合。

为什么用户会选它而不是普通提示词

它的核心差异在于编排：规划、审批、派发、监控和汇报都是明确步骤。它不是让一个 agent “把所有事都做完”，而是借助 claude-devfleet for Agent Orchestration，把工作拆成带依赖关系的任务，再放到不同 worktree 里并行执行，避免并发修改一开始就互相冲突。

最大的采用门槛

最大的门槛在于实际环境：这个技能要求有一个正在运行、并通过 MCP 连接的 Claude DevFleet 实例。如果 DevFleet 没有安装、无法访问，或者没有暴露在预期的 MCP 端点上，这个技能就做不了任何有用的事。要把它理解成建立在既有基础设施之上的执行工作流，而不是一个独立安装器。

如何使用 claude-devfleet 技能

安装上下文与前置连接

在尝试 claude-devfleet 的使用之前，先确认 Claude Code 能通过 MCP 访问 DevFleet。技能源码明确要求有一个正在运行的实例，并给出了这种连接方式：

claude mcp add devfleet --transport http http://localhost:18801/mcp

如果你的 DevFleet 服务器在其他主机或端口上，就把这个 URL 改掉。实际的安装决策很直接：如果你的环境不允许本地 MCP 服务，那就先别用这个技能，等这一步解决后再说。

claude-devfleet 在实际中如何调用

核心流程是：

1. 用 plan_project(prompt) 把一个宽泛需求整理成项目和任务 DAG。
2. 在执行前和用户一起审查方案。
3. 用 dispatch_mission(mission_id, model?, max_turns?) 启动任务。
4. 在配置好依赖关系后，让相关任务自动派发。
5. 用 get_report(mission_id) 汇总 files_changed、已完成工作、错误和下一步。

如果你已经清楚任务拆分，也可以直接用 create_project(...) 和 create_mission(...) 手动搭建计划。当你更重视依赖图而不是头脑风暴时，手动创建会更合适。

把模糊目标改写成强提示词

弱输入：“Build a REST API.”

更适合 claude-devfleet 技能的输入应该包含：

• 仓库路径或目标代码库
• 期望的端点和认证方式
• 持久化层
• 测试预期
• 非目标范围
• 排序约束

示例：
“为 ./app 制定一个项目计划：新增一个面向 projects 和 tasks 的 REST API，使用 JWT auth，基于现有 DB layer 接入 PostgreSQL，保留当前路由，添加 integration tests，并让 schema 变更与 endpoint 开发相互隔离。优先安排那些可以安全并行执行的任务。”

之所以有效，是因为 plan_project 在知道边界、接口和顺序约束后，才能生成更好的任务图。没有这些信息时，往往只会得到一个泛泛的计划，或者彼此重叠过多的任务。

建议的工作流和先读什么

先读 SKILL.md，因为这个仓库真正的操作约定就在这里。重点看：

• 必需的 MCP 依赖
• plan → approve → dispatch → report 的工作流
• 可用工具及其参数
• 通过 depends_on 和 auto_dispatch 处理依赖关系

一个更稳妥的工作流是：

1. 先只要求出计划。
2. 检查任务是否真的可以拆开。
3. 批准或调整任务图。
4. 先派发一个小任务，验证环境和仓库假设。
5. 只有在第一份报告成功后，再扩大并行派发规模。

claude-devfleet 技能 FAQ

claude-devfleet 适合新手吗？

只有在新手已经把 DevFleet 跑起来的情况下才算适合。这个编排模型本身不难理解，但真正的门槛是基础设施和任务拆分。没有 MCP 或 worktree 经验的新手，往往还没看到价值就先卡住了。

什么时候该用它，而不是普通编程提示词？

当任务足够大，值得做任务规划、隔离执行和结构化汇报时，就该用 claude-devfleet。单文件修改、快速排错或探索性问题，不适合用它。在这些场景里，普通提示词更快，操作开销也更小。

这个技能的边界是什么？

这个 claude-devfleet 指南覆盖的是编排行为，不是完整的环境部署。它默认 DevFleet 已存在，并且像 plan_project、create_mission、dispatch_mission、cancel_mission 和 get_report 这样的工具可以通过 MCP 使用。如果这些工具缺失，这个技能基本上就不可用。

它适合团队工作流吗？

适合，尤其适合团队想要一个可见的任务图，并通过隔离的 git worktree 获得更安全的并行执行时。对于很小的仓库，或者不希望在编码流程里引入自动合并和依赖驱动自动化的团队来说，它的吸引力就没那么强。

如何改进 claude-devfleet 技能

提供更好的规划输入

提升 claude-devfleet 输出的最快方法，是一开始就把架构约束和拆分提示说清楚。要提到：

• 目标仓库/路径
• 验收标准
• 可能引发冲突的共享文件
• 必须先做的任务
• 可以并行执行的任务

这样可以减少糟糕的任务图，也能避免两个 agent 同时改到同一片高冲突区域。

注意常见失败模式

主要的失败模式是可预见的：

• 没有与 DevFleet 建立 MCP 连接
• 任务范围太大
• 依赖任务过早派发
• 并行 worktree 中出现重叠修改
• 对复杂任务来说 max_turns 不足

如果某个任务一直卡住，先缩小范围，再考虑换模型或增加 agent。

在第一份报告之后继续迭代

不要把第一版计划当成最终版。拿到 get_report(...) 之后，可以通过下面方式继续优化项目：

• 把没做完的内容拆成更细的后续任务
• 补上漏掉的依赖关系
• 取消重复劳动的任务
• 重写提示词，明确文件、接口或测试目标

这正是 claude-devfleet for Agent Orchestration 比单个长提示词更有价值的地方：它的工作流就是为反复修订设计的，而不是追求一次到位的完美。

用更紧凑的任务提示词提升结果

好的任务提示词会明确代码区域、期望产出和完成定义。例如：
“在 server/auth 中实现 JWT auth middleware，把它接入现有的受保护路由，为 token 验证和过期 token 添加单元测试，不要修改数据库 schema。”

这种细粒度说明能提升交接质量，降低合并风险，也让最终报告更可执行。