用途：对 ONE ProcessFlow 的某一个流程（输入为流程名）进行红队式审查，目标是找出问题而非寻求安慰。默认假设当前概念由上下文不足的弱 AI 生成，因此所有断言在核实前都视为可疑。该技能不编辑任何内容，只输出按优先级排序的问题清单。
主要能力：拉取当前画布、报告、评分与图表（需 Chrome 会话令牌）并阅读相关转录段落，做概念↔画布↔图表↔转录的交叉比对；逐条走查 processflow-review/references/guardrails.md 底部的 Fehlermuster-Register 表，主动检查每个模式。常见的致命问题包括：公司名错误、虚构工具/品牌/设备/ERP（用名称与转录 grep 对照）、行业整体错误并贯穿所有字段与图表、场景错误（概念描述的流程与转录本意不符）、重复造 ERP 或产品已有功能（如 IPTOR 原生补货、IDP 工具、Firefly、InboxMate）而未考虑 Build-vs-Buy、AI 技术选型错误（如该用图像嵌入却描述 VLM、客户明确说规则却上重 ML、该用 IDP 却做提示词抽取）、价格或“包含/免费”幻觉（如 Firefly 额度）、动力过度或不足、工时过低、仅第一阶段有分析步骤、默认既有系统免费（BMD）、画布≠概念≠图表≠合规漂移、角色仅写首字母、图表术语过多或故事错误、把 OS 模块当作一次性应用、OS 解决方案类别错误、返工后评分过时、智能体设定的审批或日期问题。当概念提到工具、价格或技术时，用 WebSearch/WebFetch 做网络核实，确认工具正确、价格/层级真实、技术为当前先进，并引用来源。此外评估“最小方案”与“AI 优先”之间的张力：是过度工程，还是在客户期待真正 AI 的地方动力不足，以及 AI 对这位客户是否真的合理。
使用方式：以流程名作为输入；先读取共享的 Team-Update-Feed（GET /api/updates?company=<slug>），因为其他并行智能体可能已标记过行业、虚构工具、共享模块或价格事实，避免重复推导；若批评发现跨流程影响，需注明以便发布到 feed（由 wrapper/worker 执行 POST /api/update）。输出格式为每条问题包含：严重度、短标题、证据（引文或字段）、对应的 guardrail、具体修复建议，并按严重度分组，最后给出一行结论：概念是可靠的还是需要返工（以及在哪一维度）。只有在真正走查过登记表后，“无阻塞问题”才是有效结论。
适用场景与限制：适用于流程概念的独立审查与纠错，清单可直接回喂给 processflow-process。限制与依赖（Chrome 会话令牌、内部 API 端点、guardrails 文件路径等）均来自资料描述，具体环境、权限与部署细节暂未提供。