Technical Review 是一个技术评审技能，定位为“资深软件架构师”角色，要求评审者以从未见过该代码的新鲜视角，验证每个计划任务是否被正确实现、测试是否充分、是否达到专业质量标准，并对产品从整体上做出评估。
用途与工作流位置
该技能可用于两种方式：顺序使用，即在计划功能实现完成之后进行评审；独立使用，作为契约入口，对照计划评审任意实现。无论哪种方式，目标都是验证计划任务已实现、测试充分、符合质量标准，然后对产品做整体评估。
所需输入
必需输入包括：评审范围（单个、多个或全部）和计划内容（用于验证的任务与验收标准，可为一个或多个计划）。可选输入为规格说明内容，用于提供设计决策的上下文。在继续之前需确认必需输入可用；若缺失则停止，直到问题解决。若未提供计划，会输出提示要求用户指向计划文件（例如 .workflows/planning/{topic}/plan.md）并停止等待响应。若计划引用了找不到的规格，会提示用户确认规格位置，并说明可以不带规格继续，但规格能提供更好的评审上下文；规格是可选输入，仅凭计划也可继续评审。若评审模式为“仅分析”，表示已请求分析现有评审发现，评审已完成，直接进入后续步骤。
上下文刷新后的恢复协议
当检测到上下文刷新（压缩）发生——对话突然变短、缺少近期步骤记忆、或消息前出现摘要——需遵循恢复协议：完整重读该技能文件，不依赖摘要；读取当前主题的所有跟踪与状态文件（计划索引文件、评审跟踪文件、实现跟踪文件或该技能创建的任何工作文档），这些是进度的权威来源；检查 git 状态，运行 git status 和 git log --oneline -10 查看近期提交，提交信息遵循约定模式可揭示已完成内容；在继续之前向用户声明自己认为所处的步骤、已完成内容和下一步，并等待确认。不要猜测进度或凭记忆继续，磁盘上的文件和 git 历史是权威，记忆不是。
硬性规则
评审所有任务——不要抽样，验证每个计划任务；不修复代码——识别问题，不解决问题；不重新实现——是在评审，不是构建；要具体——说“测试未覆盖 X”而非“测试需要改进”；引用工件——将发现链接到计划/规格，使用 file:line 引用；平衡测试评审——同时标记测试不足和过度测试；保持新鲜视角——从未见过此代码，质疑一切。
输出格式
在宣布新步骤时，在步骤标题前单独一行输出 ── ── ── ── ──。
流程步骤
步骤 1：读取计划与规格。读取所选范围提供的所有计划。对每个计划：读取计划，理解阶段、任务和验收标准；读取链接的规格（如有），加载设计上下文；提取所有阶段中的所有任务。若不存在规格，计划是设计决策的唯一权威来源。然后进入步骤 2。
步骤 2：项目技能发现。若 .claude/skills/ 不存在或为空，提示未找到项目技能，将在没有项目特定约定下继续，进入步骤 3。若存在项目技能，扫描 .claude/skills/ 中的项目特定技能目录，记录与评审相关的技能（框架指南、代码风格、架构模式），进入步骤 3。
步骤 3：QA 验证。加载 invoke-task-verifiers.md 并按其说明执行。停止，直到所有任务验证器返回并汇总发现后，再进入步骤 4。
步骤 4：产出评审。加载 produce-review.md 并按其说明执行，然后进入步骤 5。
步骤 5：评审动作。加载 review-actions-loop.md 并按其说明执行。
限制与缺失信息
该技能的具体实现细节、依赖的辅助文件（invoke-task-verifiers.md、produce-review.md、review-actions-loop.md）内容、支持的平台、收费方式、价格、实际效果等，资料中暂未提供。