用途：设计评审工作流，回答“我们做出来的东西是否是当初要求的东西”，区别于测试回答的“它能不能用”。
主要能力：定义规格文件存放模式，如 specs/feature-{name}.md、specs/issue-{number}-{type}.md；设计截图捕获点（初始状态、关键操作、最终状态）；按严重程度分类问题（blocker 阻止发布且损害体验、tech_debt 可用的质量问题需记录、skippable 打磨或偏好类可忽略）；搭建自动解决循环（发现 blocker 则 /patch、/implement 后重新评审，最多 3 次重试）；配置证据存储，可选本地 agents/{adw_id}/review_img/、云端 R2/S3 等公开 URL、或随评审产物提交到 Git。
使用方式：评审命令读取 spec_file 变量，先读规格、理解需求与成功标准，再通过 git diff origin/main 分析变更，对照规格捕获 1-5 张关键功能截图（命名如 01_name.png），随后分级问题并输出包含 success、review_summary、review_issues 的结果；每个 issue 含 issue_description、issue_resolution、issue_severity。
适用场景：为功能搭建评审流程、创建价值证明工作流、设计基于规格的验证、实现自动解决循环；可接入 SDLC 流程 /plan、/build、/test、/review、/patch、/document。
限制与最佳实践：仅 blocker 需立即修复，重试次数应设上限以避免死循环，tech_debt 需记录以免信息丢失；截图是给相关方看的交付证据，评审须以规格为准而非假设。具体集成工具与运行环境要求暂未提供。