hany-implement

name	hany-implement
description	详细实现。触发：/hany:implement。基于hany:require确认的示例和方案，拆解任务+分配Agent→并行实现→完成前验证→提交。
author	hany
version	1.1

hany-implement — 详细实现

触发方式：/hany:implement

调用方：可独立触发 /hany:implement，也可由 hany-auto Step 3 自动调用。

核心原则：严格按照确认的方案执行，不自行调整。不确定的地方必须问。发现问题必须指出。优先并行。时刻汇报进度。偏差立即汇报。

快速路径：AI 在 Step 0 中自动判断复杂度，简单任务自动跳过 Constitutional 门禁、文件结构映射和计划自检走 Step 0→1→4(快速拆解，含文件列表)→7→8→10→11。复杂任务走全流程。

强制交互规则

详见 hany-common/procedures/interaction_rules.md

质量模式

详见 hany-common/procedures/quality_modes.md

编码约束：读取 hany-common/rules/rules.md，11 条规则全程生效。

概览（必读）

[按需加载] 本文件包含完整步骤手册。执行时：

1. 启动阶段：仅读快速参考卡和"Step 0"即可开始
2. 执行阶段：用 Read(offset/limit) 跳读到对应 Step 章节（参考下方行号区间）
3. 已完成阶段：用 3 行摘要替代详细内容，释放上下文

行号参考（offset 跳读用）：Step 0 约第 72 行 | Step 1 约第 85 行 | Step 2 约第 92 行 | Step 3 约第 100 行 | Step 4 约第 117 行 | Step 5 约第 137 行 | Step 6 约第 149 行 | Step 7 约第 155 行 | Step 8 约第 202 行 | Step 9 约第 214 行 | Step 10 约第 234 行 | Step 11 约第 253 行

快速参考卡

阶段	核心动作	确认节点
Step 0	先想想看，输出思路	—
Step 1	检查前置条件（需求文档是否存在）	—
Step 2	Constitutional 门禁	AskUserQuestion（不通过时）
Step 3	文件结构映射（新建/修改/删除文件清单）	AskUserQuestion
Step 4	PRD 故事拆解 + Agent 分配	AskUserQuestion
Step 5	计划自检（5 项自查）	—
Step 6	结构化计划文档写入 docs/hany/plans/	AskUserQuestion
Step 7	并行实现（Team 分配 + 实时进度）	偏差时 AskUserQuestion
Step 8	完成前验证门禁（运行命令+红旗词检测）	—
Step 9	过程检查 + 错误→规则抽象	—
Step 10	提交协议	—
Step 11	完成确认	AskUserQuestion

前置条件

必须满足才能开始：

1. docs/hany/requirements/ 下存在已确认的需求文档
2. 需求文档中无 [NEEDS CLARIFICATION] 标记

前置条件不满足时，提示用户先执行 /hany:require。

恢复检查

启动时检查 docs/hany/plans/ 下是否有未完成的计划文档。如果有，使用 AskUserQuestion 询问：继续上次 / 重新开始。

概览工作流程

见上方快速参考卡（按顺序从 Step 0 到 Step 11）。

---

Step 0：先想想看 [进度 2%]

⚠️ 若由 hany-auto 调用，跳过此步（auto 已在之前阶段完成整体思考）。

触发后，先思考再执行。

1. 需求文档里的核心目标是什么？
2. 实现范围大概涉及多少个文件/模块？
3. 有没有技术难点或风险点？
4. 适合并行执行还是顺序执行？

思考完后，输出思路再进入 Step 1。

Step 1：检查前置条件 [进度 5%]

1. 检查 docs/hany/requirements/ 下是否存在已确认的需求文档
2. 如果没有，提示用户："请先执行 /hany:require 确认需求和示例"
3. 如果有，读取并理解需求文档和示例代码
4. 如果发现多个需求文档（拆分子系统场景），按子系统分别处理，按依赖顺序执行

Step 2：Constitutional 门禁 [进度 10%]

实现前检查是否符合项目原则。不通过则不能进入实现。

详见 hany-common/procedures/constitutional_guard.md

门禁不通过 → 记录为例外并说明理由，用 AskUserQuestion 让用户确认是否接受。

Step 3：文件结构映射 [进度 15%]

定义任务前，先列出所有要创建/修改的文件及职责。

### 新建文件
| 文件路径 | 职责 |

### 修改文件
| 文件路径 | 修改内容 |

### 删除文件
| 文件路径 | 原因 |

用 AskUserQuestion 确认：确认 / 调整 / 取消。

Step 4：PRD 故事拆解 + 分配 Agent/Team [进度 25%]

4.1 故事拆解

### 故事 N：[标题]
- **作为** [角色] **我想要** [功能] **以便** [价值]
- **验收标准**：
  - [ ] 给定 [前置条件]，当 [操作]，那么 [预期结果]
- **状态**：passes: false

4.2 步骤分配

将故事拆解为具体步骤，按并行组分配 Agent。

分配原则：同一文件修改分配给同一 Agent，同一故事步骤尽量分配给同一 Agent，每个 Agent prompt 必须自包含。

用 AskUserQuestion 确认：确认执行 / 调整步骤 / 调整分配 / 取消。

Step 5：计划自检 [进度 30%]

自查项	检查内容
需求覆盖度	每个需求都有对应故事/步骤
占位符扫描	TBD/TODO/待定必须消除
类型一致性	函数签名、数据类型一致
依赖完整性	步骤间依赖完整标注
验收标准	每个故事有可测试的验收标准

自查不通过 → 修改 → 重新自查。

Step 6：结构化计划文档 [进度 35%]

写入 docs/hany/plans/YYYY-MM-DD-<主题>.md，含目标、架构、技术栈、文件结构、用户故事、实现步骤、checkbox 跟踪。

用 AskUserQuestion 确认：确认写入 / 修改 / 取消。

Step 7：并行实现（Team 分配执行 + 实时进度汇报） [进度 40-75%]

严格按 Step 4 的分配方案，将每个并行组分发给对应 Agent。

7.0 并行决策检查（强制执行）

并行处理规则见 hany-common/procedures/split_parallel.md

在启动并行组之前，必须分析文件依赖关系：

依赖强度	判定标准	并行策略
强依赖	A文件被B文件直接引用；修改A会导致B必须同步修改	不并行，串行执行
中等依赖	A和B都依赖同一个模块，但彼此不直接依赖	可并行，但需统一接口
无依赖	两个文件完全独立，修改互不影响	可以并行

7.1 启动并行组

1. 为每个 Agent 构建自包含 prompt
2. 优先 team 模式启动，降级 Agent 并发

7.2 实时进度汇报

• [进度 X%] Agent-X 启动：[描述]
• [进度 X%] Agent-X：[子步骤] ✅完成 / ❌失败
• [进度 X%] Agent-X 完成：耗时 [X]，变更文件：[列表]

汇总（每完成一个并行组）：

[并行组 X 完成状态 - 进度 X%]
├── Agent-A: ✅ 完成（步骤 1.1, 1.3）
├── Agent-B: ✅ 完成（步骤 1.2）
└── Agent-C: ❌ 失败（步骤 1.4，原因：[说明]）

7.3 偏差立即汇报

发现偏差 → 立即暂停汇报 → 等用户决定 → 继续。

7.4 Agent 返回后验证

不信任 Agent 报告。每个 Agent 返回后独立验证：git diff + 文件内容 + 语法/构建。验证通过后更新对应故事的 passes: true。

7.5 异常处理

方案不可行 / 需求遗漏 / 发现更好方式 / Agent 失败 → 暂停 → 汇报 → 用户决定 → 继续。

Step 8：完成前验证门禁 [进度 80%]

任何 Agent 说"完成"之前，必须先通过验证门禁。

门禁项	检查方式
运行验证命令	必须实际运行语法检查、构建、测试命令，看到输出
红旗词检测	检查报告中"应该"、"可能"、"看起来"等不确定词 → 不允许
证据附带	每个"完成"声明必须附带验证命令输出

铁律：没有验证命令输出的"完成"声明不算数。

Step 9：过程检查 + 错误→规则抽象 [进度 85%]

检查项	要求
语法检查	使用语言对应工具验证
引用依据	所有引用给出来源文件路径和行号
可验证	每项改动附带验证方式
方案一致性	实现与确认的方案一致
故事验收	每个故事验收标准都满足（passes: true）

9.1 错误→规则抽象

错误类型	处理方式
编码习惯问题（如忘处理 null）	写入 docs/hany/rules.md 作为项目规则
项目特定问题（如某 API 特殊行为）	写入项目笔记
一次性失误（如打错字）	加测试覆盖

能写成测试的错误，必须写成测试。能写成规则的错误，必须写成规则。不能只修 bug 不留防線。

Step 10：提交协议 [进度 90%]

实现完成并验证通过后，按规范提交。

<type>: <subject>

<body with decision trailers>

Type：feat / fix / refactor / docs / test / chore

决策 Trailer（可选）：

Constraint: [技术/业务约束]
Rejected: [被排除的方案及原因]
Confidence: [高/中/低]

Step 11：完成确认 [进度 95%]

1. 汇总实现结果：每个故事验收状态 + 每个步骤完成状态
2. 列出变更文件清单
3. 用 AskUserQuestion 确认：确认完成 / 有遗漏 / 需要调整

确认通过：由 hany-auto 编排器自动路由至验证阶段（verify-small / verify-project）。