Menu
详细实现。触发：/hany:implement。基于hany:require确认的示例和方案，拆解任务+分配Agent→并行实现→完成前验证→提交。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
自动化编排。触发：/hany:auto。根据用户描述自动调用 hany-require → planreview → hany-implement → 智能验证路由(verify-small/verify-project)，渐进式加载+验证修复循环+错误回退。
需求确认+示例原型。触发：/hany:require。Brainstorming+Deep-interview式提问→歧义评分→确认需求→输出可行示例+技术说明+架构图+思维过程。
项目级验证。触发：/hany:verify-project。针对大功能、架构调整、多文件改动的完整验证：多视角并行审查+功能测试+回归验证+边界检查+修复循环+质量清单+根因分析。
hany skill 公共层：共享规则库、公共流程模式、公共配置。所有 hany-* skill 共享。
需求文档评审优化。触发：/hany:planreview。针对已创建的需求文档，挑战不合理性并优化文档质量。
引导用户形成完整技术问题描述，生成结构化问题草稿。
| name | hany-implement |
| description | 详细实现。触发：/hany:implement。基于hany:require确认的示例和方案，拆解任务+分配Agent→并行实现→完成前验证→提交。 |
| author | hany |
| version | 1.1 |
触发方式：/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）。