用途：按资深工程师标准端到端实现一个新功能，产出安全、快速、可靠的改动。每次只会输出两种结果之一：已实现的功能，或在初始歧义闸门失败时只输出 2-3 个澄清问题、不做其他任何事。
主要能力：强调反臆测，先发现项目真实命令（不假定 bun、npm、make 存在），读 CLAUDE.md，检查 Makefile、justfile、package.json、pyproject.toml，并验证工具是否存在；测试命令必须来自项目实际使用。总结中的数字必须来自本会话实际运行的命令。遵循 Lean Code：先复用代码库、标准库、框架和依赖，只构建当前具体需求所需，避免投机性抽象；但输入校验、错误处理、安全与可访问性不可省略，故意简化需用 // LEAN-DEBT: 标注。
使用方式：调用形式为 /implement-feature <功能描述>。工作流分阶段：Phase 0 歧义闸门与项目发现；Phase 1 联网研究当前最佳实践、查 Context7 库文档并探索代码库；Phase 2 进入计划模式并需用户批准；Phase 3 实现，最多约 3 个并行工作流，子代理需显式指定模型（实现用 sonnet，探索用 haiku，不用 opus），完成后审查 diff 并提交；Phase 4 运行发现到的测试、lint、类型检查/构建并修复失败；Phase 5 最终提交；Phase 6 仅 UI 功能用 agent-browser 做手动测试，命令如 agent-browser open <url>、agent-browser snapshot -i、agent-browser click @e1、agent-browser close。
任务跟踪为可选：仅当改动涉及 4+ 文件或需要 3+ 阶段跟踪时才创建任务系统条目；阈值以下按顺序执行阶段、不调用任务系统。无任务工具时跳过跟踪与并行子代理，全部串行完成。在评估或沙箱环境中不应调用真实任务工具；若要求写入文件（如 outputs/tasks.json），则把完整任务链写入该文件作为交付物。
适用场景：新增功能、带验证的 REST 接口、以新行为为导向的重构（如把支付模块迁移为策略模式）。限制：资料未提供具体收费、价格、平台与效果数据；不适用纯后端无 UI 的手动测试，且任何检查失败都不能标记完成。