القائمة
HarnessFlow 独立评审。plan 层工件(plan.md / spec.md / design.md)与实现代码完成后,必须经本技能给出落盘的评审结论才能推进。核心纪律:评审只承认 subagent 或全新会话,主会话冷读是降级路径且不得自我确认;代码评审者必须自己跑测试、自己读 diff。不修改被评审对象,只产出结论与 findings。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
C++ 编程规范扩展。绑定阶段: build。触发条件: 项目主要语言为 C++(存在 CMakeLists.txt / *.cpp 主体代码)。约束 C++ 项目在实现阶段的测试组织(GoogleTest)、资源管理与常见测试反模式。
UI 设计领域扩展。绑定阶段: plan、build、verify。触发条件: 特性包含用户界面(页面、组件、可视交互)。为计划阶段追加 UI 设计章节要求(信息架构、交互状态、design token、可访问性),为实现与验证阶段追加前端验收纪律(交互三态测试、真实渲染冒烟证据)。
HarnessFlow build 阶段(TDD)。计划已批准(或档位 1 的 frame 已完成)、任务清单存在未完成任务时使用,也用于代码评审返回"需修改"后的修订。以红-绿-重构循环逐个完成任务,每次测试运行都必须通过 hf_gate.py run 落盘为证据日志。gate check --to build 未通过时不得使用,先回上游。
HarnessFlow frame 阶段(主链入口)。任何新特性、行为变更或缺陷修复开始时使用:把用户意图定格为一页 frame.md——意图、范围、风险档位(1 微改/2 标准/3 高危)及理由,并用 hf_gate.py run 建立环境基线(全量测试/构建能否真实运行)。不写需求细节、不做设计。产出的档位决定后续流程形态。
HarnessFlow plan 阶段。frame 完成且风险档位 ≥2 时使用:档位 2 产出一份 plan.md(需求+设计+任务清单),档位 3 先产出 spec.md 评审通过后再产出 design.md。也用于 plan 层评审返回"需修改"后的修订。档位 1 不使用本技能。前提不满足(gate check --to plan 失败)时回 hf-frame。
HarnessFlow ship 阶段。verify 完成(gate check --to ship 通过)后使用:逐条对照需求验收闭环、同步文档、收尾状态并向用户交付总结报告。gate check --to ship 未通过时不得使用。
| name | hf-review |
| description | HarnessFlow 独立评审。plan 层工件(plan.md / spec.md / design.md)与实现代码完成后,必须经本技能给出落盘的评审结论才能推进。核心纪律:评审只承认 subagent 或全新会话,主会话冷读是降级路径且不得自我确认;代码评审者必须自己跑测试、自己读 diff。不修改被评审对象,只产出结论与 findings。 |
评审的产出是落盘的结论,不是聊天里一句"看起来不错"。评审存在的理由是对抗模型的自我偏好——模型系统性高估自己的产出,且只有当评审方"不知道作者是自己"时偏差才消失。所以独立性是硬约束,不是姿态。
| 执行方式 | 效力 | 要求 |
|---|---|---|
| subagent(如 Cursor/Claude Code 的 Task 工具) | 完整 | 只给被评审工件路径、上游工件路径、本技能与 checklist 路径;不带作者会话的推理过程 |
| 全新会话 | 完整 | 同上,由用户或编排器开启 |
| 主会话冷读 | 降级 | 仅当前两者都不可用;结论只能是"待独立复核"或"需修改",不得给"通过" |
降级评审的处理:interactive 模式下把 findings 与"待独立复核"结论呈给用户,由用户裁决后在记录中写 - 用户确认: <日期>;auto 模式下这是硬停点,必须停下等用户。降级评审的确认行禁止写 auto-approved(gate 会机械拦截)。
| 评审对象 | Checklist | 记录路径 |
|---|---|---|
spec.md | references/requirements-checklist.md | reviews/spec-review.md |
plan.md(档位 2) | requirements + design 两份 checklist,一轮完成 | reviews/plan-review.md |
design.md | references/design-checklist.md | reviews/design-review.md |
| 实现代码 + 测试 | references/code-checklist.md | reviews/code-review.md |
通读被评审工件与其上游(评 design 要读 spec;评代码要读计划与 frame)。读 progress.md 的"已加载扩展",把各扩展 SKILL.md 中声明的对应阶段评审检查项并入本轮 checklist。
评审者必须自己动手,不采信作者叙述:
evidence/ 日志与任务的对应关系(red 是否真是行为缺失、有无手工编辑痕迹)- [严重|一般|建议] <位置>: <问题描述> → <修改建议>
写入对应的 reviews/*.md:
# <对象> 评审 (第 N 轮)
- 日期: YYYY-MM-DD
- 评审方式: subagent | 独立会话 | 主会话降级
- 结论: 通过 | 需修改 | 待独立复核
## Findings
<逐条列出;"通过"且无 findings 时写"无">
结论规则:存在严重或一般 finding → 需修改;只有建议级 → 可以 通过 并附带建议;降级方式不得给 通过。不允许"通过但是……"的混合结论。
需修改 → 回作者阶段(hf-plan / hf-build),只修 findings 指出的问题,再送复审;复审只确认 findings 是否闭合,不从头再评、不翻案已闭合项。通过 → interactive 模式下向用户展示 1-2 句结论摘要并等待确认,确认后追加 - 用户确认: <日期>;auto 模式(且评审方式非降级)写 - 用户确认: auto-approved <日期>。确认必须落盘在结论行之后——这是 gate 机械判定"已批准"的依据。