agents24 incident-response 插件解析incident-response-code-reviewer 代码审查子代理的职责、能力与调用链路【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文以incident-response插件中的代码审查子代理 code-reviewer.md 为主体完整解析该 Agent 的元数据定义、八项核心审查能力与七步审查流程并结合 smart-fix.md 编排命令的源码级调用点说明它在多智能体故障修复工作流中被调用的时机、输入输出契约与结构化结果字段。读完本文后你将理解这个逻辑缺陷 类型安全 错误处理 架构隐患四位一体的审查角色如何嵌入事故响应链路以及如何在自己的 Agent 编排中复用同样的子代理拆分模式。一、它在 incident-response 插件中的位置incident-response是 agents24 仓库一个面向 Claude Code、Codex、Cursor、OpenCode、GitHub Copilot 与 Google Antigravity 等多 harness 的 Agent 插件市场中的一个故障响应插件其目录结构如下plugins/incident-response/ ├── agents/ │ ├── code-reviewer.md ← 本文主角 │ ├── debugger.md │ ├── devops-troubleshooter.md │ ├── error-detective.md │ ├── incident-responder.md │ └── test-automator.md ├── commands/ │ ├── incident-response.md # 13 步生产事故响应编排 │ └── smart-fix.md # 10 步智能问题修复编排两次调用 code-reviewer └── skills/ ├── incident-runbook-templates/ ├── on-call-handoff-patterns/ └── postmortem-writing/插件内共定义了 6 个子代理从源码结构看它们的 frontmattername统一采用incident-response-角色的命名约定如 debugger.md 的incident-response-debugger、error-detective.md 的incident-response-error-detective这样插件名就内嵌在代理名中避免跨插件重名冲突也与仓库文档中说明的代理命名规范一致参见 docs/architecture.md 关于 hyphen-case 命名的约定。在整个插件中incident-response-code-reviewer的角色定位非常聚焦它不写修复代码而是专门审查代码的逻辑缺陷与设计问题并给出修复设计建议。其 frontmatter 声明的职责是引自 code-reviewer.md--- name: incident-response-code-reviewer description: Reviews code for logic flaws, type safety gaps, error handling issues, architectural concerns, and similar vulnerability patterns. Provides fix design recommendations. model: sonnet ---两个关键元数据值得注意model: sonnet声明该子代理运行时使用 sonnet 级别的模型。审查任务需要跨代码库的模式识别能力属于深度推理、中低吞吐型任务插件作者统一为 6 个代理都标注了model: sonnet从源码结构看这是该插件对专家型子代理的默认建模选择。description中强调 similar vulnerability patterns 与 fix design recommendations这直接决定了它在编排中的两个用途——深挖阶段的问题清单产出者和收尾阶段的发布审批者。二、八项核心审查能力Capabilities原文档将能力拆为 8 条这是理解该 Agent 审查视角的完整骨架。下面逐条说明其技术含义以及在实际审查中对应的检查点#能力具体审查对象1逻辑缺陷分析Logic flaw analysis错误的假设incorrect assumptions、缺失的边界情况missing edge cases、错误的算法选择wrong algorithms2类型安全审查Type safety review识别哪些位置可以用更强的类型系统narrower types、可空类型标注、泛型约束从根本上阻止一类 bug 再次发生3错误处理审计Error handling audit缺失的 try-catch、未处理的 promise、可能 panic 的路径跨语言Node/Go/Rust/Python 等场景4契约校验Contract validation输入校验缺口input validation gaps、输出保证未被满足output guarantees not met——即函数/API 的承诺与实际是否一致5架构审查Architecture review紧耦合tight coupling、缺失的抽象missing abstractions、分层违反layering violations6模式检测Pattern detection在全代码库中寻找与当前缺陷相同的相似脆弱点——这是把单点修复升级为系统性修复的关键步骤7修复设计Fix design给出三种粒度的方案权衡最小改动minimal changevs 局部重构refactoringvs 架构级改进architectural improvement8最终审批审查Final approval review以代码质量、安全性、部署就绪度三个维度做放行前最后一道闸这 8 条能力刻意覆盖了从微观代码行到宏观架构的三个层次能力 1–4 关注代码行与函数边界能力 5–6 关注模块与代码库层面能力 7–8 则面向修复决策与发布决策这两个出口。这种分层审查 双出口的结构正是它能在同一插件中复用两次见下文的原因。三、七步审查流程Response Approach文档为这个 Agent 规定了一条固定的 7 步执行路径这也是它每次被 Task 工具唤起时的标准工作序列分析代码路径识别逻辑缺陷Analyze the code path and identify logic flaws检查类型安全性明确哪些更强类型的引入能阻止问题Check type safety and where stronger types help审计错误处理缺口Audit error handling for gaps校验契约与边界Validate contracts and boundaries在代码库其他位置寻找相似模式Look for similar patterns elsewhere in the codebase设计最小有效修复Design the minimal effective fix输出带严重度评级的结构化审查结果Provide a structured review with severity ratings两点设计值得强调流程是由点到面再收口第 1–4 步把当前缺陷本身挖透第 5 步横向扩散到全库寻找同类脆弱点对应能力 6第 6–7 步才给出修复建议与分级结论。这与先查完再下结论的排查纪律一致避免审查者在第一处发现缺陷后就急于给方案。第 7 步要求 severity ratings审查结论不是自由文本而是带严重度分级的结构化结果。这一点在下游编排命令中被严格兑现——smart-fix验证阶段会依据Critical / High 发现必须先处理的规则阻塞流程见 smart-fix.mdIf there are Critical or High severity findings, address them before proceeding。四、调用链实证smart-fix 编排中的两个调用点incident-response-code-reviewer在 smart-fix.md 中被subagent_type引用了两次分别处于 10 步修复工作流的第 4 步与第 9 步。这是理解该 Agent 实际运行契约的最佳证据。4.1 调用点一第 4 步代码审查深挖Phase 2: Deep Investigation在错误侦探incident-response-error-detective完成错误分析、调试器incident-response-debugger完成深度代码分析之后编排命令通过 Task 工具唤起审查者引自 smart-fix.mdTask: subagent_type: incident-response-code-reviewer description: Review code logic for: $ISSUE prompt: | Review code logic and identify design issues: Context from Deep Analysis: [Insert contents of .smart-fix/03-deep-analysis.md] Deliverables: 1. Logic flaw analysis: incorrect assumptions, missing edge cases, wrong algorithms 2. Type safety gaps: where stronger types could prevent the issue 3. Error handling review: missing try-catch, unhandled promises, panic scenarios 4. Contract validation: input validation gaps, output guarantees not met 5. Architectural issues: tight coupling, missing abstractions, layering violations 6. Similar patterns: other code locations with same vulnerability 7. Fix design: minimal change vs refactoring vs architectural improvement Review checklist: - Are null/undefined values handled correctly? - Are async operations properly awaited/chained? - Are error cases explicitly handled? - Are type assertions safe? - Are API contracts respected? - Are side effects isolated? Provide structured output with: LOGIC_FLAWS, TYPE_SAFETY_GAPS, ERROR_HANDLING_GAPS, SIMILAR_VULNERABILITIES, FIX_DESIGN, REFACTORING_OPPORTUNITIES, ARCHITECTURAL_CONCERNS.几个契约要点输入是文件而非上下文记忆。编排规则明确要求Read from prior step files — do NOT rely on context window memory第 4 步必须先读取.smart-fix/02-root-cause.md与.smart-fix/03-deep-analysis.md把深度分析结论作为 prompt 上下文注入。这把跨步骤的知识传递从上下文窗口迁移到了工作区文件使长流程可中断、可恢复。7 项交付物与 Agent 自身 8 项能力一一对应能力 8最终审批在第 4 步不启用说明编排 prompt 与 Agent 定义是成对设计的。附加了 6 条审查清单null/undefined 处理、异步 await/链式、错误显式处理、类型断言安全性、API 契约、副作用隔离是对 Agent 定义的运行时补丁——把抽象能力落成可勾选的具体检查项。输出为 7 个结构化字段LOGIC_FLAWS、TYPE_SAFETY_GAPS、ERROR_HANDLING_GAPS、SIMILAR_VULNERABILITIES、FIX_DESIGN、REFACTORING_OPPORTUNITIES、ARCHITECTURAL_CONCERNS落盘到.smart-fix/04-code-review.md。其中SIMILAR_VULNERABILITIES字段会被第 5 步的实现代理直接使用要求Regression tests: tests for similar vulnerabilities found in code review即审查发现的同类脆弱点会转化为回归测试需求形成审查 → 修复 → 回归覆盖的闭环。4.2 调用点二第 9 步最终代码审查Phase 5: Final Review Prevention修复实现第 5 步、回归测试 / 性能验证 / 安全审查第 6–8 步全部通过用户审批后同一个 Agent 换了一个帽子再次出场——从问题清单产出者变为发布审批者引自 smart-fix.mdTask: subagent_type: incident-response-code-reviewer description: Final review for: $ISSUE fix prompt: | Perform final code review and approve for deployment: Implementation: [Insert contents of .smart-fix/05-implementation.md] Verification: [Insert contents of .smart-fix/06-verification.md] Deliverables: 1. Code quality review: conventions, patterns, error handling, observability 2. Architecture review: boundaries, coupling, scalability 3. Security review: vulnerabilities, validation, auth 4. Deployment readiness: rollback plan, feature flags, monitoring 5. Risk assessment: blast radius, rollout strategy, success metrics Report: REVIEW_STATUS, DEPLOYMENT_RISK, ROLLBACK_PLAN, ROLLOUT_STRATEGY, MONITORING_REQUIREMENTS, FINAL_VERDICT.这一次的输出契约变为REVIEW_STATUS、DEPLOYMENT_RISK、ROLLBACK_PLAN、ROLLOUT_STRATEGY、MONITORING_REQUIREMENTS、FINAL_VERDICT六个字段落盘到.smart-fix/07-final-review.md。这正是 Agent 定义中能力 8Final approval review: code quality, security, deployment readiness的具体落地审查维度从逻辑/类型/错误处理扩展到部署就绪度核心结论由FINAL_VERDICT最终裁定表达。对比说明插件的另一条编排线 incident-response.md13 步生产事故响应流程主要调用incident-responder、incident-response-debugger、incident-response-devops-troubleshooter与general-purpose修复实现步骤用的是general-purpose senior backend architect 角色提示并不直接调用 code-reviewer。也就是说code-reviewer 是 smart-fix 这条代码级问题修复管线上的专属审查节点而非事故应急线上的通用环节。4.3 编排框架为审查结果提供的执行纪律理解调用点离不开插件定义的 6 条关键行为规则两条 command 共用同一套前 6 条规则见 smart-fix.md。对 code-reviewer 的输出消费方而言最相关的是按序执行不允许跳步、并步——第 4 步的审查结果必须是第 5 步实现的输入顺序不可颠倒每步必须落盘审查结果写入.smart-fix/04-code-review.md之后才能进入下一步且后续步骤从文件读取而非记忆检查点停等第 4 步完成后流程进入 PHASE CHECKPOINT 2 前的中间态用户未批准不进入修复实现第 9 步的最终审查结果同样要经 PHASE CHECKPOINT 3 的用户批准失败即停审查步骤若因代理错误失败编排立即停止并询问用户而不是静默继续。这些规则保证了审查 Agent 的输出不是一次性建议而是工作流中的持久化工件artifact.smart-fix/下的01-error-analysis.md→02-root-cause.md→03-deep-analysis.md→04-code-review.md→05-implementation.md→06-verification.md→07-final-review.md→08-prevention.md构成完整证据链state.json中的completed_steps与files_created记录每一步的推进状态支持中断后Resume from where we left off。五、与其他子代理的分工边界从源码结构看插件把找问题 → 深挖 → 审查 → 修复 → 验证 → 审批拆给了不同专职代理code-reviewer 的边界清晰阶段smart-fix 步骤代理与 code-reviewer 的关系1. 错误检测error-detective提供错误签名与时间线是审查的远端上下文2/3. 根因 深度分析debuggerdebugger 回答为什么失败根因、bisect、竞态reviewer 回答代码还哪里会这样失败设计层面两者互补不重叠4. 代码审查深挖code-reviewer产出问题清单与修复设计5. 修复实现general-purposesenior engineer 角色提示消费04-code-review.md的FIX_DESIGN与SIMILAR_VULNERABILITIES6–8. 回归/性能/安全test-automator general-purpose回归测试覆盖审查发现的同类脆弱点9. 最终审查code-reviewer产出FINAL_VERDICT与发布策略10. 文档与预防general-purposeSRE 角色消费最终审查结论这种同一专家代理在不同阶段承担不同出口问题清单 / 发布裁定的设计是多 Agent 插件中控制 token 成本与角色漂移的常见做法Agent 定义保持静态8 能力 7 步流程场景差异全部由编排 prompt 的 Deliverables 与输出字段约束完成。六、实际使用方式在安装了该插件的 harness 中Claude Code / Codex / Cursor 等多 harness 安装与命名空间机制参见 docs/harnesses.md 与 tools/adapters/ 下各适配器实现code-reviewer 不是以独立斜杠命令暴露的而是由编排命令间接唤起经智能修复管线触发运行smart-fix命令并传入问题描述如smart-fix payment 回调偶发 NPE --verification standard --prevention immediate。流程推进到第 4 步时自动以subagent_type: incident-response-code-reviewer唤起本 Agent审查输出落盘.smart-fix/04-code-review.md第 9 步再次唤起并产出.smart-fix/07-final-review.md。经事故响应管线间接受益运行incident-response命令并传入事故描述与严重级别如incident-response 订单服务 5xx 飙升 --severity P1该 13 步流程在深度调试第 4 步incident-response-debugger与修复实现第 7 步中产出的代码级结论与 code-reviewer 所定义的审查维度逻辑、类型、错误处理、契约、架构、模式在结构上一致团队可在事故后的代码修复 PR 上手动引用 smart-fix 的审查步骤做复核。直接作为子代理调用在支持 Task/Agent 派生的 harness 中参见 docs/harnesses.md 对各 harness 派生工具能力的说明可手动以incident-response-code-reviewer为subagent_type唤起它prompt 中按其Deliverables structured output契约给出输入文件与期望字段即可复用其七步审查流程得到带 severity 分级的结构化审查报告。七、小结incident-response-code-reviewer是 agents24 incident-response 插件中审查即契约的样板实现定义层code-reviewer.md 用 frontmatternamedescriptionmodel: sonnet声明身份用 8 项能力定义审查视角用 7 步固定流程保证每次执行路径一致且结论必须带严重度分级编排层smart-fix.md 在第 4 步与第 9 步以subagent_type: incident-response-code-reviewer两次调用分别约束 7 个与 6 个结构化输出字段通过.smart-fix/*.md文件落盘 state.json状态机 检查点审批把审查结论转化为可追踪、可恢复、可审计的工作流工件分工层它与 error-detective找错误、debugger挖根因、test-automator验修复边界清晰自身只负责设计层缺陷识别 修复设计 发布裁定其产出的SIMILAR_VULNERABILITIES直接驱动回归测试生成FINAL_VERDICT决定发布放行。对需要在自己的 Agent 编排中引入代码审查节点的开发者而言该实现提供了三个可直接借鉴的工程要点审查能力分层代码行/模块/代码库三层、同一代理双出口问题清单与发布裁定、以及文件即上下文的跨步骤知识传递纪律。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agents24 incident-response 插件解析：incident-response-code-reviewer 代码审查子代理的职责、能力与调用链路
agents24 incident-response 插件解析incident-response-code-reviewer 代码审查子代理的职责、能力与调用链路【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文以incident-response插件中的代码审查子代理 code-reviewer.md 为主体完整解析该 Agent 的元数据定义、八项核心审查能力与七步审查流程并结合 smart-fix.md 编排命令的源码级调用点说明它在多智能体故障修复工作流中被调用的时机、输入输出契约与结构化结果字段。读完本文后你将理解这个逻辑缺陷 类型安全 错误处理 架构隐患四位一体的审查角色如何嵌入事故响应链路以及如何在自己的 Agent 编排中复用同样的子代理拆分模式。一、它在 incident-response 插件中的位置incident-response是 agents24 仓库一个面向 Claude Code、Codex、Cursor、OpenCode、GitHub Copilot 与 Google Antigravity 等多 harness 的 Agent 插件市场中的一个故障响应插件其目录结构如下plugins/incident-response/ ├── agents/ │ ├── code-reviewer.md ← 本文主角 │ ├── debugger.md │ ├── devops-troubleshooter.md │ ├── error-detective.md │ ├── incident-responder.md │ └── test-automator.md ├── commands/ │ ├── incident-response.md # 13 步生产事故响应编排 │ └── smart-fix.md # 10 步智能问题修复编排两次调用 code-reviewer └── skills/ ├── incident-runbook-templates/ ├── on-call-handoff-patterns/ └── postmortem-writing/插件内共定义了 6 个子代理从源码结构看它们的 frontmattername统一采用incident-response-角色的命名约定如 debugger.md 的incident-response-debugger、error-detective.md 的incident-response-error-detective这样插件名就内嵌在代理名中避免跨插件重名冲突也与仓库文档中说明的代理命名规范一致参见 docs/architecture.md 关于 hyphen-case 命名的约定。在整个插件中incident-response-code-reviewer的角色定位非常聚焦它不写修复代码而是专门审查代码的逻辑缺陷与设计问题并给出修复设计建议。其 frontmatter 声明的职责是引自 code-reviewer.md--- name: incident-response-code-reviewer description: Reviews code for logic flaws, type safety gaps, error handling issues, architectural concerns, and similar vulnerability patterns. Provides fix design recommendations. model: sonnet ---两个关键元数据值得注意model: sonnet声明该子代理运行时使用 sonnet 级别的模型。审查任务需要跨代码库的模式识别能力属于深度推理、中低吞吐型任务插件作者统一为 6 个代理都标注了model: sonnet从源码结构看这是该插件对专家型子代理的默认建模选择。description中强调 similar vulnerability patterns 与 fix design recommendations这直接决定了它在编排中的两个用途——深挖阶段的问题清单产出者和收尾阶段的发布审批者。二、八项核心审查能力Capabilities原文档将能力拆为 8 条这是理解该 Agent 审查视角的完整骨架。下面逐条说明其技术含义以及在实际审查中对应的检查点#能力具体审查对象1逻辑缺陷分析Logic flaw analysis错误的假设incorrect assumptions、缺失的边界情况missing edge cases、错误的算法选择wrong algorithms2类型安全审查Type safety review识别哪些位置可以用更强的类型系统narrower types、可空类型标注、泛型约束从根本上阻止一类 bug 再次发生3错误处理审计Error handling audit缺失的 try-catch、未处理的 promise、可能 panic 的路径跨语言Node/Go/Rust/Python 等场景4契约校验Contract validation输入校验缺口input validation gaps、输出保证未被满足output guarantees not met——即函数/API 的承诺与实际是否一致5架构审查Architecture review紧耦合tight coupling、缺失的抽象missing abstractions、分层违反layering violations6模式检测Pattern detection在全代码库中寻找与当前缺陷相同的相似脆弱点——这是把单点修复升级为系统性修复的关键步骤7修复设计Fix design给出三种粒度的方案权衡最小改动minimal changevs 局部重构refactoringvs 架构级改进architectural improvement8最终审批审查Final approval review以代码质量、安全性、部署就绪度三个维度做放行前最后一道闸这 8 条能力刻意覆盖了从微观代码行到宏观架构的三个层次能力 1–4 关注代码行与函数边界能力 5–6 关注模块与代码库层面能力 7–8 则面向修复决策与发布决策这两个出口。这种分层审查 双出口的结构正是它能在同一插件中复用两次见下文的原因。三、七步审查流程Response Approach文档为这个 Agent 规定了一条固定的 7 步执行路径这也是它每次被 Task 工具唤起时的标准工作序列分析代码路径识别逻辑缺陷Analyze the code path and identify logic flaws检查类型安全性明确哪些更强类型的引入能阻止问题Check type safety and where stronger types help审计错误处理缺口Audit error handling for gaps校验契约与边界Validate contracts and boundaries在代码库其他位置寻找相似模式Look for similar patterns elsewhere in the codebase设计最小有效修复Design the minimal effective fix输出带严重度评级的结构化审查结果Provide a structured review with severity ratings两点设计值得强调流程是由点到面再收口第 1–4 步把当前缺陷本身挖透第 5 步横向扩散到全库寻找同类脆弱点对应能力 6第 6–7 步才给出修复建议与分级结论。这与先查完再下结论的排查纪律一致避免审查者在第一处发现缺陷后就急于给方案。第 7 步要求 severity ratings审查结论不是自由文本而是带严重度分级的结构化结果。这一点在下游编排命令中被严格兑现——smart-fix验证阶段会依据Critical / High 发现必须先处理的规则阻塞流程见 smart-fix.mdIf there are Critical or High severity findings, address them before proceeding。四、调用链实证smart-fix 编排中的两个调用点incident-response-code-reviewer在 smart-fix.md 中被subagent_type引用了两次分别处于 10 步修复工作流的第 4 步与第 9 步。这是理解该 Agent 实际运行契约的最佳证据。4.1 调用点一第 4 步代码审查深挖Phase 2: Deep Investigation在错误侦探incident-response-error-detective完成错误分析、调试器incident-response-debugger完成深度代码分析之后编排命令通过 Task 工具唤起审查者引自 smart-fix.mdTask: subagent_type: incident-response-code-reviewer description: Review code logic for: $ISSUE prompt: | Review code logic and identify design issues: Context from Deep Analysis: [Insert contents of .smart-fix/03-deep-analysis.md] Deliverables: 1. Logic flaw analysis: incorrect assumptions, missing edge cases, wrong algorithms 2. Type safety gaps: where stronger types could prevent the issue 3. Error handling review: missing try-catch, unhandled promises, panic scenarios 4. Contract validation: input validation gaps, output guarantees not met 5. Architectural issues: tight coupling, missing abstractions, layering violations 6. Similar patterns: other code locations with same vulnerability 7. Fix design: minimal change vs refactoring vs architectural improvement Review checklist: - Are null/undefined values handled correctly? - Are async operations properly awaited/chained? - Are error cases explicitly handled? - Are type assertions safe? - Are API contracts respected? - Are side effects isolated? Provide structured output with: LOGIC_FLAWS, TYPE_SAFETY_GAPS, ERROR_HANDLING_GAPS, SIMILAR_VULNERABILITIES, FIX_DESIGN, REFACTORING_OPPORTUNITIES, ARCHITECTURAL_CONCERNS.几个契约要点输入是文件而非上下文记忆。编排规则明确要求Read from prior step files — do NOT rely on context window memory第 4 步必须先读取.smart-fix/02-root-cause.md与.smart-fix/03-deep-analysis.md把深度分析结论作为 prompt 上下文注入。这把跨步骤的知识传递从上下文窗口迁移到了工作区文件使长流程可中断、可恢复。7 项交付物与 Agent 自身 8 项能力一一对应能力 8最终审批在第 4 步不启用说明编排 prompt 与 Agent 定义是成对设计的。附加了 6 条审查清单null/undefined 处理、异步 await/链式、错误显式处理、类型断言安全性、API 契约、副作用隔离是对 Agent 定义的运行时补丁——把抽象能力落成可勾选的具体检查项。输出为 7 个结构化字段LOGIC_FLAWS、TYPE_SAFETY_GAPS、ERROR_HANDLING_GAPS、SIMILAR_VULNERABILITIES、FIX_DESIGN、REFACTORING_OPPORTUNITIES、ARCHITECTURAL_CONCERNS落盘到.smart-fix/04-code-review.md。其中SIMILAR_VULNERABILITIES字段会被第 5 步的实现代理直接使用要求Regression tests: tests for similar vulnerabilities found in code review即审查发现的同类脆弱点会转化为回归测试需求形成审查 → 修复 → 回归覆盖的闭环。4.2 调用点二第 9 步最终代码审查Phase 5: Final Review Prevention修复实现第 5 步、回归测试 / 性能验证 / 安全审查第 6–8 步全部通过用户审批后同一个 Agent 换了一个帽子再次出场——从问题清单产出者变为发布审批者引自 smart-fix.mdTask: subagent_type: incident-response-code-reviewer description: Final review for: $ISSUE fix prompt: | Perform final code review and approve for deployment: Implementation: [Insert contents of .smart-fix/05-implementation.md] Verification: [Insert contents of .smart-fix/06-verification.md] Deliverables: 1. Code quality review: conventions, patterns, error handling, observability 2. Architecture review: boundaries, coupling, scalability 3. Security review: vulnerabilities, validation, auth 4. Deployment readiness: rollback plan, feature flags, monitoring 5. Risk assessment: blast radius, rollout strategy, success metrics Report: REVIEW_STATUS, DEPLOYMENT_RISK, ROLLBACK_PLAN, ROLLOUT_STRATEGY, MONITORING_REQUIREMENTS, FINAL_VERDICT.这一次的输出契约变为REVIEW_STATUS、DEPLOYMENT_RISK、ROLLBACK_PLAN、ROLLOUT_STRATEGY、MONITORING_REQUIREMENTS、FINAL_VERDICT六个字段落盘到.smart-fix/07-final-review.md。这正是 Agent 定义中能力 8Final approval review: code quality, security, deployment readiness的具体落地审查维度从逻辑/类型/错误处理扩展到部署就绪度核心结论由FINAL_VERDICT最终裁定表达。对比说明插件的另一条编排线 incident-response.md13 步生产事故响应流程主要调用incident-responder、incident-response-debugger、incident-response-devops-troubleshooter与general-purpose修复实现步骤用的是general-purpose senior backend architect 角色提示并不直接调用 code-reviewer。也就是说code-reviewer 是 smart-fix 这条代码级问题修复管线上的专属审查节点而非事故应急线上的通用环节。4.3 编排框架为审查结果提供的执行纪律理解调用点离不开插件定义的 6 条关键行为规则两条 command 共用同一套前 6 条规则见 smart-fix.md。对 code-reviewer 的输出消费方而言最相关的是按序执行不允许跳步、并步——第 4 步的审查结果必须是第 5 步实现的输入顺序不可颠倒每步必须落盘审查结果写入.smart-fix/04-code-review.md之后才能进入下一步且后续步骤从文件读取而非记忆检查点停等第 4 步完成后流程进入 PHASE CHECKPOINT 2 前的中间态用户未批准不进入修复实现第 9 步的最终审查结果同样要经 PHASE CHECKPOINT 3 的用户批准失败即停审查步骤若因代理错误失败编排立即停止并询问用户而不是静默继续。这些规则保证了审查 Agent 的输出不是一次性建议而是工作流中的持久化工件artifact.smart-fix/下的01-error-analysis.md→02-root-cause.md→03-deep-analysis.md→04-code-review.md→05-implementation.md→06-verification.md→07-final-review.md→08-prevention.md构成完整证据链state.json中的completed_steps与files_created记录每一步的推进状态支持中断后Resume from where we left off。五、与其他子代理的分工边界从源码结构看插件把找问题 → 深挖 → 审查 → 修复 → 验证 → 审批拆给了不同专职代理code-reviewer 的边界清晰阶段smart-fix 步骤代理与 code-reviewer 的关系1. 错误检测error-detective提供错误签名与时间线是审查的远端上下文2/3. 根因 深度分析debuggerdebugger 回答为什么失败根因、bisect、竞态reviewer 回答代码还哪里会这样失败设计层面两者互补不重叠4. 代码审查深挖code-reviewer产出问题清单与修复设计5. 修复实现general-purposesenior engineer 角色提示消费04-code-review.md的FIX_DESIGN与SIMILAR_VULNERABILITIES6–8. 回归/性能/安全test-automator general-purpose回归测试覆盖审查发现的同类脆弱点9. 最终审查code-reviewer产出FINAL_VERDICT与发布策略10. 文档与预防general-purposeSRE 角色消费最终审查结论这种同一专家代理在不同阶段承担不同出口问题清单 / 发布裁定的设计是多 Agent 插件中控制 token 成本与角色漂移的常见做法Agent 定义保持静态8 能力 7 步流程场景差异全部由编排 prompt 的 Deliverables 与输出字段约束完成。六、实际使用方式在安装了该插件的 harness 中Claude Code / Codex / Cursor 等多 harness 安装与命名空间机制参见 docs/harnesses.md 与 tools/adapters/ 下各适配器实现code-reviewer 不是以独立斜杠命令暴露的而是由编排命令间接唤起经智能修复管线触发运行smart-fix命令并传入问题描述如smart-fix payment 回调偶发 NPE --verification standard --prevention immediate。流程推进到第 4 步时自动以subagent_type: incident-response-code-reviewer唤起本 Agent审查输出落盘.smart-fix/04-code-review.md第 9 步再次唤起并产出.smart-fix/07-final-review.md。经事故响应管线间接受益运行incident-response命令并传入事故描述与严重级别如incident-response 订单服务 5xx 飙升 --severity P1该 13 步流程在深度调试第 4 步incident-response-debugger与修复实现第 7 步中产出的代码级结论与 code-reviewer 所定义的审查维度逻辑、类型、错误处理、契约、架构、模式在结构上一致团队可在事故后的代码修复 PR 上手动引用 smart-fix 的审查步骤做复核。直接作为子代理调用在支持 Task/Agent 派生的 harness 中参见 docs/harnesses.md 对各 harness 派生工具能力的说明可手动以incident-response-code-reviewer为subagent_type唤起它prompt 中按其Deliverables structured output契约给出输入文件与期望字段即可复用其七步审查流程得到带 severity 分级的结构化审查报告。七、小结incident-response-code-reviewer是 agents24 incident-response 插件中审查即契约的样板实现定义层code-reviewer.md 用 frontmatternamedescriptionmodel: sonnet声明身份用 8 项能力定义审查视角用 7 步固定流程保证每次执行路径一致且结论必须带严重度分级编排层smart-fix.md 在第 4 步与第 9 步以subagent_type: incident-response-code-reviewer两次调用分别约束 7 个与 6 个结构化输出字段通过.smart-fix/*.md文件落盘 state.json状态机 检查点审批把审查结论转化为可追踪、可恢复、可审计的工作流工件分工层它与 error-detective找错误、debugger挖根因、test-automator验修复边界清晰自身只负责设计层缺陷识别 修复设计 发布裁定其产出的SIMILAR_VULNERABILITIES直接驱动回归测试生成FINAL_VERDICT决定发布放行。对需要在自己的 Agent 编排中引入代码审查节点的开发者而言该实现提供了三个可直接借鉴的工程要点审查能力分层代码行/模块/代码库三层、同一代理双出口问题清单与发布裁定、以及文件即上下文的跨步骤知识传递纪律。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考