Impl

完成当前已确认需求，按完整业务结果组织本地提交，再按适用依据决定评审及必要修复。

-w 使用隔离 worktree，-a 使用子 Agent 或 workflow 编排；两个选项独立且可组合。用户明确要求 worktree 或子 Agent / workflow 时，分别按对应选项执行。使用 -w 或 -a 时，实施前完整读取 [ISOLATION.md](./ISOLATION.md)。

流程

1. 加载项目上下文

按项目知识协议加载相关 CONTEXT 与 RULE；已有知识覆盖本轮任务时复用，范围变化时补充。仅采用与当前任务直接适用、仍有效且未被本次明确要求取代的规则。知识不可用时继续可完成的工作并说明缺口。

2. 分解提交单元

提交单元以可独立说明的业务意义为边界：完成后，用户、角色或系统获得一项完整能力，或者产生一个可观察的业务结果。从任务卡、PRD、API 清单或当前对话中识别这些结果；共同完成同一结果所需的代码、测试、配置、迁移和文档放在同一单元，不按文件、技术层、接口数量或改动类型拆分。

只有形成不同且各自完整的业务结果时才拆分。每个提交单元还需满足 atomic-commit 的交付完整性与直接回滚标准。

3. 实施并提交

逐个提交单元执行：

1. 将需求映射到实际代码和调用路径。修复缺陷时检查受影响的调用者，在共同根因的所有者处修复。
2. 遵循项目惯用法并复用现有能力，在完整满足需求的方案中选择概念和改动负担最少的一项。不增加需求与规则之外的抽象、依赖、扩展点或兜底；保留显式需求及正确性、安全、无障碍和防止数据丢失所必需的行为。
3. 常规实现选择自行完成；存在复杂职责归属或接口取舍时读取 codebase-design，再完成实现。
4. 复用已有验证结果，完成项目要求及与改动相称的必要检查。只有现有证据不足以判断结果时补充测试；证据足够后继续交付。
5. 调用 atomic-commit，以当前提交单元为交付单元完成一个本地提交。
6. 按以下规则决定是否评审：

- 存在需要明确遵守的 RULE（工程规范）：code-review --std； - 存在直接作为本次需求依据的 PRD、任务卡等需求材料：code-review --spec； - 两类依据都有：完整 code-review；都没有：不调用。

RULE 属于 Standards，PRD、任务卡等需求属于 Spec。仅读取或加载不构成评审依据。用户已明确修改目标和实施方案、无需解释规则或进行方案判断的改动，跳过自动评审；用户明确要求评审时按其要求执行。

1. 若调用了 code-review，取得最终报告后逐条判断；只修复真实存在且确有必要的问题，并通过 amend 将修复纳入当前提交。没有此类问题时不修改提交，不重复评审。

实现路径不可行时，在既定目标和授权范围内调整并继续。只有必须改变业务目标、外部契约、授权范围或用户明确锁定的选择时才提问；复杂且相互依赖的取舍可调用 ask-me。受阻时说明具体缺口，并继续不依赖它的工作。