Menu
在规格、设计、测试或代码需要独立评审时使用：阶段产物完成后的把关、人要求 review、或对既有产物做专项检查时。评审必须由作者之外的独立上下文执行，产出 findings 与 verdict。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
在实现任何功能或修复任何缺陷、即将编写实现代码时使用；设计确认后的整个实现期都适用。强制测试先行的 RED→GREEN→REFACTOR 循环。不用于规格编写、设计决策或纯文档修改。
在车载软件工作项（ECU、域控、车载服务、整车平台）的规格、设计、实现或评审中使用，涉及功能安全/ASIL、车载 SOA 服务、DTC/诊断、整车启动/休眠/唤醒、SELinux 或跨 ECU 协同时。只承载车载专属约束；内存/实时性、通用服务接口或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。
在后端/服务端工作项（HTTP/REST/GraphQL API、服务与仓库层、数据库访问、缓存、鉴权、限流、后台任务、可观测性、配置与机密、弹性容错、生产就绪）的规格、设计、实现或评审中使用，涉及接口契约、分层与依赖方向、配置与机密、错误模型、数据一致性、幂等、认证授权、依赖超时重试熔断、过载保护、优雅停机时。只承载服务端/API 领域约束；客户端/UI、行业专属服务或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。
在编写、修改或评审 C 代码（.c 源文件、.h 头文件、C 单元测试、C ABI 边界）时使用。提供指针所有权、手动内存与资源释放、缓冲区容量、整数转换、宏、头文件、错误返回的具体规则与正反例。只适用于 C 语言；其他语言或 C++ 代码使用对应语言自己的 coding-standards 技能。
在需要为某种编程语言新建或修订 coding-standards 技能时使用：把团队内部编码规范文档转化为符合 DevFlow 形态的 <language>-coding-standards 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。
在编写、修改或评审 C++ 代码（.cpp/.cc/.hpp、类、模板、RAII、智能指针、C++ 测试、C++ ABI 边界）时使用。提供资源管理、所有权签名、类设计、错误策略、模板纪律与 ABI 的具体规则与正反例。只适用于 C++；C 或其他语言代码使用对应语言自己的 coding-standards 技能。
| name | devflow-review |
| description | 在规格、设计、测试或代码需要独立评审时使用：阶段产物完成后的把关、人要求 review、或对既有产物做专项检查时。评审必须由作者之外的独立上下文执行，产出 findings 与 verdict。 |
评审是 human-on-the-loop 的支点：AI 生产，独立评审暴露问题，人做最终把关。它是工作流的必经节点：specify、design、tdd 每个阶段产物完成后都经评审（R1/R2/R3，见 using-devflow 工作流），通过前不进入下一阶段。三条不变量：
reviews/ 落盘一份记录；findings 的修复过程必须回写同一份记录（resolution 闭环）。口头说"评审过了"而 reviews/ 里没有对应文件与闭环记录，按未评审处理。评审不是流程仪式。一次好的评审 = 带着「这东西哪里会骗我」的怀疑去读：规格会在哪里被两种人读出两种意思？测试会放过哪种错误实现？代码哪里在对读者撒谎？
| 评审目标 | Rubric | 关注核心 |
|---|---|---|
| spec.md | references/spec-review-rubric.md | 可测试性、变更风险显式、无走私的实现细节 |
| design.md（及 component-design-draft.md，如适用） | references/design-review-rubric.md | 契约完整、复杂度有理由、测试设计覆盖、追溯一致 |
| 测试 | references/test-review-rubric.md | 断言强度、覆盖映射、mock 边界、RED 证据 |
| 代码 | references/code-review-rubric.md + devflow-clean-code | 正确性、与设计一致、整洁标准、语言/领域规则 |
派发 devflow-reviewer subagent（agent name: devflow-reviewer，角色定义见 agents/devflow-reviewer.md；OpenCode 通过 task 工具传入 agent name，task prompt 为评审输入）执行评审，输入只给：被评审产物、它的上游工件（评审设计给 spec，评审代码给 design + diff）、对应 rubric、代码评审时的 devflow-clean-code、适用的 coding-standards / 领域技能。不给作者的推理过程和聊天历史。
每条 finding：位置 + 问题 + 为什么是问题 + 严重级 + 分类 + 建议返工阶段。
| 严重级 | 含义 | 例 |
|---|---|---|
critical | 不修不能继续：会导致做错事、留 bug 或不可审 | 验收标准不可测试；测试断言放过 mutation；错误路径资源泄漏 |
important | 完成前应修 | 边界用例缺失；函数职责混杂；命名误导 |
minor | 建议改进 | 措辞、风格微调 |
| 分类 | 含义 | 处理 |
|---|---|---|
LLM-FIXABLE | 信息已足够，作者可按 finding 定向修复 | 不问人，回对应作者阶段修复并复审 |
USER-INPUT | 缺业务事实、优先级、验收阈值、外部来源确认 | 只问 finding 指向的最小问题，拿到回答后再修 |
TEAM-EXPERT | 需要模块架构师、资深工程师或团队规则裁决 | 把问题封装成 1-2 个具体决策点上抛，不在评审或作者阶段擅自决定 |
verdict 三选一：
通过：无 critical/important，或仅剩已被人接受的 minor需修改：findings 可定向修复，修复后复审重新设计：问题出在上游（规格漏洞、设计方向错误），打回对应阶段建议返工阶段按问题本质填写：
| 问题本质 | 返工阶段 |
|---|---|
| 规格不可测试、缺业务事实、Change Type / Existing Behavior 错 | devflow-specify |
| 设计契约、错误模型、测试设计、组件边界错误 | devflow-design |
| R3 中的测试断言、RED 证据、实现 bug、代码整洁问题 | devflow-tdd |
R3 的 需修改 默认回 devflow-tdd：测试弱就先补强或重写会失败的测试，代码问题就用 RED/GREEN/REFACTOR 或纯 REFACTOR 修复。只有 finding 明确证明规格或设计工件本身错误，才回 devflow-specify / devflow-design。
记录写入同一组件根/工件根下 features/<id>/reviews/<目标>-review-<日期>.md（或团队覆盖路径），同一目标的复审追加轮次后缀（-r2、-r3）。每份记录包含：评审对象（含版本/commit）、findings 表（含 Resolution 列、分类、建议返工阶段）、verdict、抽查记录（如做了 mutation 自检，写明改了哪行、哪个测试红了）。格式见 agents/devflow-reviewer.md 的输出模板。
verdict 为 需修改/重新设计 时，作者按 findings 返工，并逐条回写原评审记录的 Resolution 列：
返工顺序：
USER-INPUT 与 TEAM-EXPERT 的答案；同一决策面合并成最少问题，不把整份评审记录丢给人。LLM-FIXABLE findings；只改 finding 指向的行、章节、测试或代码，不借机重写无关内容。全部 critical/important 有 resolution 后才能复审。Resolution 列有空着的 critical/important，门禁不算通过——devflow-ship 的 DoD 会核验这一点。复审必须核对上一轮 Resolution 与实际 diff 一致；问题不能在新记录里“凭空消失”。
同一 R 节点最多自动返工复审 3 轮。第 3 轮仍有未闭环 critical/important，或持续出现新的同级问题，停止自动循环，把剩余问题、已修证据和需要人裁决的具体问题呈给人。
attended（默认）：把评审记录与 verdict 呈给人，人同意后才进入下一阶段；人的否决/接受意见记入评审文件。unattended：不停顿，但本技能的其余动作一项不少——独立评审、落盘记录、critical 阻塞返工与复审照常执行；人工确认列记 N/A(unattended)，供人事后统一审计 reviews/。在 plan.md 门禁表更新本轮门禁状态与记录路径：pending 表示等待评审，passed 表示评审通过，rework 表示必须先回作者阶段修复。R3 评审为 rework 时，下一步是 devflow-tdd，不是再次直接评审，也不是进入 devflow-ship。
reviews/ 没有对应记录文件（= 未评审）需修改 后停在评审上下文里自修，或直接复审而没有作者阶段的 Resolution 与证据| 文件 | 用途 |
|---|---|
references/spec-review-rubric.md | 规格评审检查项 |
references/design-review-rubric.md | 设计评审检查项 |
references/test-review-rubric.md | 测试评审检查项 |
references/code-review-rubric.md | 代码评审检查项 |