用途：fresh-eyes 用于实现完成后的质量复核。核心问题是“没有沉没成本偏见的资深评审者会发现什么”。评审者只能看到产出与需求，看不到实现推理，以保证视角独立。
主要能力：形成 Implement → Review（独立代理）→ Resolve（如有问题）的链，最多两轮；若两轮后仍不干净，则标记给用户，提示可能存在更深层设计问题。对安全、认证、加密、数据变更、金钱、PII 等关键代码自动触发。评审者按正确性、边界情况、简化、安全、一致性、输入质量等维度检查，并按严重度与置信度输出问题；低于 5/10 的发现被抑制，5-7/10 标注为不确定，8+/10 视为真实问题。解析者同时看到原始实现与评审意见，逐条给出 FIXED 或 DECLINED，并输出完整修正版本。
使用方式：需要提供待验证的代码/产出、原始需求或提示、相关上下文（周边文件、API 契约、测试）。可热启动（构建会话末尾，规格已知）或冷启动（独立调用，需说明审什么、风险类别、原始意图）。执行前运行 Pre-Dispatch 协议，确定 diff/分支引用、风险类别、既有评审反馈、需求或规格。报告写入 .agents/skill-artifacts/meta/records/[YYYY-MM-DD]-fresh-eyes-<slug>.md，按日期与 slug 命名、不可覆盖，累积为审计轨迹。
适用场景：刚写完代码后的验证、架构/设计决策实施前验证、用户提供的代码复审、任何“再检查一下”的产出。--thorough 模式会用安全、性能等专家评审者并行替代单一通用评审者。
限制：最多两轮；解析者改动超过原始产出 30%、单次处理超过 10 个发现、或引入新回归时，应停止并标记用户。不应对琐碎改动、用户明确要求快速完成、只读操作自动触发。具体模型、命令与平台细节以资料为准，未提供处暂未说明。