do — 功能开发编排器
把功能开发拆成五阶段流程，由多个子代理并行完成代码理解、设计、实现与评审，编排器本身从不直接写代码。
加分点：allowed-tools 白名单限定为两个 python3 脚本，数据流（任务目录、worktree、环境变量）披露较清楚，只读/写入代理有区分，卸载脚本可回滚。扣分点：install.py 静默向用户全局 ~/.claude/settings. 注入 Stop/SubagentStop 钩子（钩子会阻止会话退出直到 5 阶段完成），未获得显式确认；verify-loop.py 用 shell=True 从 task. 读取 verify_commands 执行，任意命令面较大且无白名单；依赖仓库内未随附的 codeagent-wrapper 二进制，来源完整性无法在静态审查中验证。
加分点：钩子脚本结构完整、有超时和 MAX_ITERATIONS=5 防死循环安全阀、错误信息可读（指出如何取消）。扣分点：README 与 SKILL.md 互相矛盾——README 称 Phase 2 为 MANDATORY，SKILL.md 称条件跳过；README 提到 task. 与 Context Pack、hooks. 指向 verify-loop.py 但 SKILL.md 全程只描述 task.md；该 skill 自身无任何测试（CI 只测 Go 的 codeagent-wrapper），setup-do.py 与 task.py 源码未在提供文件中出现，关键路径不可静态复核。
加分点：场景清晰（结构化特性开发），触发条件（/do 命令）明确，输入输出格式和阶段边界有定义。扣分点：未声明非适用范围（小改动是否过重、无 git 项目如何处理 worktree 均未说明）；核心功能完全依赖 codeagent-wrapper 及 Codex/Claude/Gemini/OpenCode 等海外后端 CLI，对中国大陆网络可达性构成实际风险但文档未披露；无中文支持说明。
加分点：文档分层较好（SKILL.md 渐进披露 + README 详细 + 代理提示词独立文件），仓库级 AGPL-3.0 许可与版本号明确，提供 FAQ 和卸载路径。扣分点：skill 级无版本/changelog；文档间不一致（阶段强制性、task.md/task.）会误导用户；维护责任仅在仓库层面体现，未验证发布者身份；setup-do.py 缺失使安装说明与实际文件不完整对应。
加分点：多代理并行编排相对手动开发有理论上的边际价值，输出格式（任务目录、完成信号、验证命令）定义具体。扣分点：无任何执行证据证明 5 阶段流程能产出可直接使用的结果；强依赖外部 wrapper 和多后端配置（models.），失败点众多，静态审查无法确认核心任务可完成；长时调用、重试策略会把调试成本转嫁给用户。
加分点：全部源码可审计，仓库含真实 CI/Release 工作流。扣分点：CI 测试只覆盖 Go 的 codeagent-wrapper，与本 skill 的关键路径（钩子、安装、工作流）无关；skills/harness 下的测试属其他 skill，不构成对 do 的佐证；无第三方执行证据，README 中的行为描述只能视为作者声明。
- install.py 会自动修改全局 ~/.claude/settings. 注入钩子，且 Stop 钩子会阻止会话退出直至 5 阶段完成——安装前请知情并确认可接受；提前退出需手动编辑 task 状态文件。
- verify-loop.py 以 shell=True 执行 task. 中的 verify_commands，请勿在不可信的 task 状态文件中写入命令。
- 核心依赖 codeagent-wrapper 及 Codex/Claude/Gemini/OpenCode 等海外后端，中国大陆网络环境下可能不可达或需额外配置；文档未披露此限制。
- 文档间存在矛盾（Phase 2 是否强制、task.md 与 task.、钩子行为），使用前请以 SKILL.md 为准并自行验证；本 skill 无自身测试，结论仅为静态审查。
- 发布者未经 FollowSkills 企业注册表验证，身份未知。
这个 Skill 能做什么，适合哪些场景？
do 是 myclaude 仓库中的一个技能，通过 /do 命令触发，用于结构化的功能开发。它运行一个五阶段工作流：理解、澄清、设计、实现与完成，通过 codeagent-wrapper 调度 code-explorer、code-architect、code-reviewer 和 develop 四类代理，前三阶段的探索与设计任务并行执行。任务状态由 setup-do.py 和 task.py 两个 Python 脚本管理，实现阶段可选择在 git worktree 中隔离改动。该技能属于 AGPL-3.0 许可的 myclaude 技能集合，需要安装 codeagent-wrapper 及至少一个后端 CLI（Codex、Claude、Gemini 或 OpenCode）才能运行。
用户执行 /do <任务> 后，技能先运行 setup-do.py 在 .claude/do-tasks/ 下创建任务目录（含 YAML 元数据的 task.md）；第一阶段并行派出 code-architect（需求完整度评分）和多个 code-explorer（相似功能追踪、架构映射、测试约定识别）；第二阶段仅在存在阻塞性问题时向用户提问；第三阶段由 code-architect 产出最小改动实现方案；第四阶段询问是否使用 worktree，随后调用 develop 代理写代码并跑测试（全栈项目可按 backend/frontend 拆分并行任务），再由两个 code-reviewer 并行做正确性与简洁性评审，阻塞问题需用户确认、次要问题自动修复；第五阶段由 code-reviewer 撰写完成总结并输出 <promise>DO_COMPLETE</promise> 信号。各阶段通过 task.py update-phase 更新状态。
- 希望在现有代码库中开发新功能、并要求先自动摸清架构与相似实现再动手的开发者
- 维护大型全栈项目、需要将后端与前端改动拆分为并行子任务的团队
- 希望在独立 git worktree 中隔离实验性改动、避免污染主分支的用户
- 希望每次代码变更都附带正确性与简洁性双重评审、并区分阻塞与次要问题的工程团队
- 使用 Codex、Claude、Gemini 或 OpenCode 作为执行后端、想要统一编排入口的 Claude Code 用户
这个 Skill 有哪些优点和局限？
- 流程结构清晰：五阶段覆盖理解、澄清、设计、实现、评审与文档化，减少凭感觉改代码
- 前三阶段只读且并行执行，前期探索效率高、不改动代码
- 评审问题分级明确：阻塞问题必须用户确认，风格类次要问题自动修复，减少打断
- worktree 延迟到实现阶段才决定，只读阶段无需隔离开销
- 强制编排器不直接写码，所有改动经 codeagent-wrapper 代理执行，职责分离
- 强依赖 codeagent-wrapper 与至少一个后端 CLI，未安装这些组件则完全无法运行
- SKILL.md 使用 Claude Code 专有机制（/do 斜杠命令、AskUserQuestion、allowed-tools Bash 权限语法），迁移到其他平台需要改写
- SKILL.md 中提到的部分注入技能（如 golang-base-practices、frontend-design）需要另行安装，来源文档未说明其获取方式
- README 未提供测试套件或基准数据，实际效果缺少量化证据
- 高推理模式的长时调用可能耗时明显，技能自身也承认超时需缩小范围重试
如何安装这个 Skill？
通过 npx github:stellarlinkco/myclaude 运行交互式安装器（默认安装到 ~/.claude），或在 config. 中将 "do" 模块设为 enabled: true。已安装的模块可用 npx github:stellarlinkco/myclaude --update 从 GitHub 更新。安装后技能位于 ~/.claude/skills/do/。注意：安装器说明中未提及是否自动安装 codeagent-wrapper，若 /do 无法运行，可按 README 故障排查章节单独安装 wrapper。
如何使用这个 Skill？
在 Claude Code 会话中输入 /do <任务描述>，例如 /do 给用户模块添加邮箱登录。技能会自动创建任务目录并进入第一阶段，期间会在第二阶段（如有阻塞问题）和第四阶段（是否使用 worktree）向你提问。任务进度可用 python3 ~/.claude/skills/do/scripts/task.py status 或 list 查看。SKILL.md 未单独说明各后端 CLI 的切换方式，相关配置见仓库 codeagent-wrapper 文档。
这个 Skill 与同类方案有什么区别？
同一仓库内的 omo 技能定位于带智能路由的 bug 调查与修复，README 的选型指南将功能开发（默认场景）指向 do，将缺陷排查指向 omo；仓库还提供轻量的 dev 和 essentials 模块（如 /code、/debug）适合简单任务。若需求是端到端开发编排而非快速修问题，do 是官方推荐入口。