用途：devil 用于在产品文档进入实现之前进行审查，定位文档中未写明的空白——未定义的核心流程、未覆盖的失败情形、政策与边界问题，把发现转化为可直接转发的礼貌问题，避免在开发中后期返工。它只审查实现前阶段的 PRD、规格说明或设计简报；若给的是代码、要求起草新规格或代码与文档对比，则拒绝并指向合适工具。
主要能力：以“审批经理”人格给出唯一裁定：Approve（0 Blocker、0 Major）、Conditional（0 Blocker、至少 1 Major）、Reject（至少 1 个 Blocker）。按固定顺序走 1–9 步例行检查：空状态、最大/过载、失败/异常、权限/资格、并发/重复、中断/恢复、存量用户/迁移、文案/本地化/无障碍、越界影响；随后运行 pre-mortem 与 silence check。检测到的领域模块（移动端、Web 前端、后端·API、管理端/B2B）必须具体化，可多模块同时启用。严重度分 Blocker、Major、Minor。内部裁定语气冷峻，对外问题语气礼貌、可直接粘贴。
使用方式：文档有三种输入形态——文件路径（用文件读取工具读）、URL（用抓取工具或已连接 MCP，如 Confluence；遇鉴权墙或不可读时请用户粘贴正文）、直接粘贴文本。确认文档确实在实现前阶段后开始，按 references/checklist.md 的问题库与领域模块审查；若无法读取该文件，需先说明，再按更严格的场景规则继续。输出默认在对话中，不保存到目录，除非用户指定路径；输出语言跟随输入文档语言。报告按角色调整“待转发问题”部分：规划者得到自审的填空式 TODO 与通过条件示例句，工程师得到 [UI]/[API]/[DATA]/[POLICY] 分层标签与判断，设计师得到按状态组织的缺失屏幕清单。
适用场景：规划者分享前的自审、工程师验证收到的规格、设计师确认需绘制的屏幕与状态。限制：不审查已实现代码；不判断方向或品味，不标记文档明确排除的范围（但会检查排除与包含范围交界处的处理）；文档处于概念阶段时不机械拒绝，只列影响下一稿的少数关键空白；不得在未真正阅读文档时凭文件名或上下文臆测内容。