用途：当对话记录、提交历史、Sentry、GitHub、CI、代码评审或 Garfield 记录显示反复出现的失败模式，可能转化为可机械执行的硬性检查时，使用 odie。它分析重复失败证据，产出硬规则计划：哪些模式能被机械强制、由哪个现有工具执行、检查应运行在哪里、哪些模式必须保留人工判断。
主要能力：收集用户提供的 issue、PR、Sentry、transcript、commit、CI 或评审链接与摘要，以及提交历史簇、Sentry 问题组、GitHub 讨论、CI 与本地验证、Garfield 发现等证据；把证据聚类为反复症状、受影响模块、已观察修复、来源数与置信度；先发现仓库既有工具，再推荐新工具；只推荐具有明确通过/失败信号的硬规则；优先强化既有工具而非新增重复工具。
用法：按工作流执行——解析证据源与目标仓库，聚类证据并交叉核对，转换为候选规则，通过“硬规则门槛”（精确信号、精确执行、框架契合、范围、例外、示例、运行器），检查现有工具并选择最小执行面，再做一次“判断验证”去除仍需人工判断的候选，按影响、复现、误报风险、落地成本和直接捕获证据的程度排序，最终输出计划而非改动。默认检查面包括 manifest、lockfile、package scripts、Makefile/justfile/Taskfile、CI 配置、pre-commit、lint/type/test 配置、结构化搜索配置、文档检查、生成物检查与必需状态检查。
限制：除非用户明确要求实现，否则不实现检查、不安装依赖、不编辑 CI、不改配置；不为一次性、重判断、产品需求或有意接受的权衡提出检查；证据不足时需说明缺失证据，单条轶事不视为复现，除非影响高且信号机械明确。新推荐工具的能力、安装命令或迁移路径若仓库中不存在，应从官方文档核实并在交接中引用来源。输出只报告 odie: plan 或 odie: blocked，包括证据缺口、证据簇、现有工具摘要、待新增硬规则、被拒的判断类候选、自定义脚本理由（如有）、首个推荐实现切片，以及咨询过的官方文档链接。