用途：以“局外人”视角对一个计划、PR、设计文档或代码变更做深度审查。与快速提交前检查的 review 不同，scrutinize 针对意图和端到端正确性存疑的场景，先问“这件事是否应该存在”，再验证它是否真的做到了所声称的事情。
触发方式：用户运行 /scrutinize；说“review this PR”“audit this”“sanity check”“second opinion”“does this change do what it says”“review this design doc”“validate this design”，或在重要合并前问“should we ship this”。
主要能力与工作流：
- 意图：用一句话复述目标；若无法复述，说明该产出规格不足并停止。随后评估是否存在更简单、更小或更优雅的做法，包括不做、复用现有代码、更小改动、换层解决；若存在更优替代，先明确点名并给出理由。
- 追踪：对变更声称的每个行为，沿真实代码端到端追踪入口→调用点→分支→状态变更→退出/返回/副作用，包含 diff 两侧未改动的代码；对计划或设计文档，则把提议流程与现有系统对照，找出不成立的假设。
- 验证：对每条声明明确写出“它声称 X，路径 A→B→C，在 C 观察到……，因此成立/不成立”；考察边界输入、并发调用、错误路径、部分失败、重试、空/超大输入、顺序假设；找出静默改变（性能、错误语义、可观测性、契约、格式）；检查测试是否真正覆盖所追踪路径，而非用 mock 掩盖问题。
- 报告：每条发现一节，按 blocker → major → nit 排序，含一句具体描述（尽量注明 file:line）、后果、暴露它的追踪证据、最小具体改动建议，最后给出单行结论：ship / fix-then-ship / rework / reject，并附最大原因。
限制与规则：不得“橡皮图章”式通过；所有关于代码的判断必须引用具体路径、文件或行；区分“PR 声称”与“我追踪后确认/反驳”；必须做一次更简替代方案检查，除非用户明确说“don't question scope”；存在结构性问题时不堆砌风格小问题；不提安全专项、规格验证等，应改用 security-review、spec-review、post-mortem 等相关技能。
价格、平台、安装方式等：暂未提供。