# Impl

> 根据需求分解提交单元，选择最小正确方案并实现。适用于用户要求实现、开发、修复或重构代码，实现任务卡或 impl。

- Skill: `zuozh11/impl` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add zuozh11/impl`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zuozh11/impl/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zuozh11 (https://skillmd.com/u/zuozh11)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zuozh11/impl

---


# Impl

完成当前已确认需求，按完整业务结果组织本地提交，再收集评审 brief 交给 `code-review` 判定维度及必要修复。

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

## 流程

### 1. 加载项目上下文

按项目知识协议加载相关 CONTEXT 与 RULE；已有知识覆盖本轮任务时复用，范围变化时补充。过目 scope 返回的全部 sceneId 与 ruleName，加载与本轮实现相关的场景或原子 RULE。仅采用与当前任务直接适用、仍有效且未被本次明确要求取代的规则。知识不可用时继续可完成的工作并说明缺口，且不得声称已遵守。

### 2. 分解提交单元

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

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

### 3. 实施并提交

逐个提交单元执行：

1. 查看现有代码，将需求映射到实际结构，并从入口到所有者追踪本次改动的真实调用路径。修复缺陷时搜索待修改位置的全部调用者，找到共同根因；不要只在报告症状的调用点打补丁。映射后尚未覆盖的相关场景或原子 RULE 补 load。
2. 读取 [MIN-IMPL.md](../codebase-design/MIN-IMPL.md)，按阶梯停在第一个能满足需求的方案。不添加需求与规则之外的抽象、依赖、扩展点、脚手架、兜底或防御性设计。不为缩短代码删除显式需求、信任边界校验、安全、无障碍或防止数据丢失的必要行为。
3. 需要新增或改变模块职责、接口表面积、接缝、adapter 或测试面时，读取 `codebase-design`。存在影响显著且无法自行决定的必要方案分歧时，调用 `ask-me` 与用户确认。
4. 在真实所有者处完成选定方案。根因能够集中修复时只修一次，不在兄弟调用者复制分支；不要为了 diff 小而修改错误层级。
5. 复用已有验证结果，完成项目要求及与改动相称的必要检查。只有现有证据不足以判断结果时补充测试；证据足够后继续交付。
6. 需求材料与已确认事实不符时，按本节末尾的分类处理，并在调用 `atomic-commit` 前完成回写。
7. 调用 `atomic-commit`，以当前提交单元完成一个本地提交。
8. 收集本提交单元的评审 brief，不选择维度、不传 `--std` / `--spec`：
   - 固定范围：本单元 `atomic-commit` 得到的那一笔 commit，记录 SHA；
   - 本单元业务结果：一句话；
   - 候选依据：本单元加载且视为有约束力的全部 `ruleId`（含行为、校验、权限类），`AGENTS.md` / `CLAUDE.md` 中与本次改动直接相关的工程条款，本次作为依据的 PRD、API 清单、任务卡路径，以及仅存在于本轮对话的已确认需求摘要；不得按「工程 / 需求」预筛。

   候选依据为空时不调用 `code-review`。用户已明确修改目标和实施方案、且无需解释规则或方案判断时也可跳过；但候选依据含信任边界校验、安全、无障碍或防止数据丢失时不得跳过。用户明确要求评审时按其要求执行。
9. 若调用 `code-review`，把 brief 一次性交给它。取得最终报告后逐条判断；只修复真实存在、确有必要且落在本单元范围内的问题。HEAD 对应本单元提交且尚未推送时，用 amend 纳入当前提交；已推送或 HEAD 不是本单元提交时停止并说明，不 force push，不把修复写进其他单元。没有此类问题时不修改提交，不重复评审。

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

需求材料与已确认事实不符时，按以下分类处理；不得把代码现状或实现偏好写回 PRD、API 清单或任务卡。

| 类型 | 判别 | 动作 |
| --- | --- | --- |
| 实现细节 | 文件、模块、接口形状、步骤、代码库能力缺口 | 不回写产品文档 |
| 文档漂移 | 名称、路径、已确认口径过时，且不改变业务目标、规则、权限或外部契约 | 来源是 CONTEXT、本轮用户确认或已锁定决策且无需重新理解：直接修正本单元覆盖的条款，并在会话中给出「原条款 → 新条款」对照。来源只是代码推断，或需要重新理解旧锁定决策：先提问，确认后再改 |
| 契约变更 | 会改变业务目标、状态或数据口径、权限、外部契约或用户锁定决策 | 必须提问。用户确认且交付结构仍成立：修正对应条款，并写入该 PRD 的 Implementation Decisions，来源标「用户确认（实现中）」。交付范围、能力切分或 Out of Scope 被推翻：停止本单元实现，转 `to-prd` 或 `to-task` |

回写在调用 `atomic-commit` 之前完成，只改本提交单元业务结果所覆盖的条款。任务卡就是本单元需求材料时可整卡更新；PRD 与 API 清单只改本单元覆盖的条款。用户不在场时阻塞该条款而不阻塞整单元：不回写、不按猜测实现该条款，继续本单元其余不依赖它的部分；整单元都依赖该条款时停止本单元并留下恢复条件。