详细实现。触发:/hany:implement。基于hany:require确认的示例和方案,拆解任务+分配Agent→并行实现→完成前验证→提交。
触发方式:/hany:implement
调用方:可独立触发
/hany:implement,也可由hany-autoStep 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 条规则全程生效。
[按需加载] 本文件包含完整步骤手册。执行时:
- 启动阶段:仅读快速参考卡和"Step 0"即可开始
- 执行阶段:用 Read(offset/limit) 跳读到对应 Step 章节(参考下方行号区间)
- 已完成阶段:用 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 |
必须满足才能开始:
docs/hany/requirements/ 下存在已确认的需求文档[NEEDS CLARIFICATION] 标记前置条件不满足时,提示用户先执行
/hany:require。
启动时检查 docs/hany/plans/ 下是否有未完成的计划文档。如果有,使用 AskUserQuestion 询问:继续上次 / 重新开始。
见上方快速参考卡(按顺序从 Step 0 到 Step 11)。
⚠️ 若由
hany-auto调用,跳过此步(auto 已在之前阶段完成整体思考)。
触发后,先思考再执行。
思考完后,输出思路再进入 Step 1。
docs/hany/requirements/ 下是否存在已确认的需求文档/hany:require 确认需求和示例"实现前检查是否符合项目原则。不通过则不能进入实现。
详见
hany-common/procedures/constitutional_guard.md
门禁不通过 → 记录为例外并说明理由,用 AskUserQuestion 让用户确认是否接受。
定义任务前,先列出所有要创建/修改的文件及职责。
### 新建文件
| 文件路径 | 职责 |
### 修改文件
| 文件路径 | 修改内容 |
### 删除文件
| 文件路径 | 原因 |
用 AskUserQuestion 确认:确认 / 调整 / 取消。
### 故事 N:[标题]
- **作为** [角色] **我想要** [功能] **以便** [价值]
- **验收标准**:
- [ ] 给定 [前置条件],当 [操作],那么 [预期结果]
- **状态**:passes: false
将故事拆解为具体步骤,按并行组分配 Agent。
分配原则:同一文件修改分配给同一 Agent,同一故事步骤尽量分配给同一 Agent,每个 Agent prompt 必须自包含。
用 AskUserQuestion 确认:确认执行 / 调整步骤 / 调整分配 / 取消。
| 自查项 | 检查内容 |
|---|---|
| 需求覆盖度 | 每个需求都有对应故事/步骤 |
| 占位符扫描 | TBD/TODO/待定必须消除 |
| 类型一致性 | 函数签名、数据类型一致 |
| 依赖完整性 | 步骤间依赖完整标注 |
| 验收标准 | 每个故事有可测试的验收标准 |
自查不通过 → 修改 → 重新自查。
写入 docs/hany/plans/YYYY-MM-DD-<主题>.md,含目标、架构、技术栈、文件结构、用户故事、实现步骤、checkbox 跟踪。
用 AskUserQuestion 确认:确认写入 / 修改 / 取消。
严格按 Step 4 的分配方案,将每个并行组分发给对应 Agent。
并行处理规则见
hany-common/procedures/split_parallel.md
在启动并行组之前,必须分析文件依赖关系:
| 依赖强度 | 判定标准 | 并行策略 |
|---|---|---|
| 强依赖 | A文件被B文件直接引用;修改A会导致B必须同步修改 | 不并行,串行执行 |
| 中等依赖 | A和B都依赖同一个模块,但彼此不直接依赖 | 可并行,但需统一接口 |
| 无依赖 | 两个文件完全独立,修改互不影响 | 可以并行 |
[进度 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,原因:[说明])
发现偏差 → 立即暂停汇报 → 等用户决定 → 继续。
不信任 Agent 报告。每个 Agent 返回后独立验证:git diff + 文件内容 + 语法/构建。验证通过后更新对应故事的 passes: true。
方案不可行 / 需求遗漏 / 发现更好方式 / Agent 失败 → 暂停 → 汇报 → 用户决定 → 继续。
任何 Agent 说"完成"之前,必须先通过验证门禁。
| 门禁项 | 检查方式 |
|---|---|
| 运行验证命令 | 必须实际运行语法检查、构建、测试命令,看到输出 |
| 红旗词检测 | 检查报告中"应该"、"可能"、"看起来"等不确定词 → 不允许 |
| 证据附带 | 每个"完成"声明必须附带验证命令输出 |
铁律:没有验证命令输出的"完成"声明不算数。
| 检查项 | 要求 |
|---|---|
| 语法检查 | 使用语言对应工具验证 |
| 引用依据 | 所有引用给出来源文件路径和行号 |
| 可验证 | 每项改动附带验证方式 |
| 方案一致性 | 实现与确认的方案一致 |
| 故事验收 | 每个故事验收标准都满足(passes: true) |
| 错误类型 | 处理方式 |
|---|---|
| 编码习惯问题(如忘处理 null) | 写入 docs/hany/rules.md 作为项目规则 |
| 项目特定问题(如某 API 特殊行为) | 写入项目笔记 |
| 一次性失误(如打错字) | 加测试覆盖 |
能写成测试的错误,必须写成测试。能写成规则的错误,必须写成规则。不能只修 bug 不留防線。
实现完成并验证通过后,按规范提交。
<type>: <subject>
<body with decision trailers>
Type:feat / fix / refactor / docs / test / chore
决策 Trailer(可选):
Constraint: [技术/业务约束]
Rejected: [被排除的方案及原因]
Confidence: [高/中/低]
AskUserQuestion 确认:确认完成 / 有遗漏 / 需要调整确认通过:由 hany-auto 编排器自动路由至验证阶段(verify-small / verify-project)。