用途：这是两阶段代码审查的第二阶段，专注代码质量、可维护性与工程最佳实践。运行前置条件是规格审查（spec review）必须先通过。触发方式包括“quality review”“check code quality”或 /review stage 2。
主要能力：检查代码质量与可读性、SOLID 原则、错误处理、测试质量、性能考量与基础安全；不重复检查功能完整性与 TDD 合规。按 Kent Beck 的 Test Desiderata 评估测试，关注 Behavioral、Structure-insensitive、Deterministic、Specific 四项，单元测试若 mock 依赖超过 3 个会提示可能属于层级错配。执行静态分析、安全扫描及可选的上下文经济、运营韧性、工作流确定性等检查，并查询质量信号与收敛状态后给出 APPROVED 或 NEEDS_FIXES 裁定。
使用方式：该技能由编排器在子代理中运行，而非内联执行。编排器负责先生成 diff（如 git diff main...HEAD > /tmp/stack-diff.patch）并随分派提示传入 diff 内容、状态文件路径及规格审查结果；子代理不自行生成 diff，读取状态文件解析产物路径后对工作区运行静态分析与安全脚本，最后返回结构化 JSON 裁定，字段包括 verdict、summary、issues、test_results。review 键必须为 kebab-case 的 reviews["quality-review"]，其值必须是含 status 字段的对象。HIGH 级问题触发修复循环，最多迭代 3 次，可用 /exarchos:review --max-fix-iterations 5 覆盖；修复后需重新验证规格合规。
适用场景与限制：适用于规格审查已通过、准备进入综合/合并前的代码质量评估。资料未提供价格、平台支持范围、具体性能数据或兼容性说明；部分步骤（如伴随插件、runbook 可用性）依赖运行环境，缺失时需回退到 describe 获取 schema。