用途：MFR 要求先产出显式问题模型，再在模型内推理与实现，用于减少因问题空间未定义而产生的幻觉。基于 Kumar & Rana（2025）的论文（arXiv:2512.14474）。
主要能力：分两阶段。阶段一仅产出模型，不写代码与解决步骤；阶段二只能在冻结模型内实现，不得引入新实体、状态、动作或约束。模型可用自然语言、半结构化文本或 JSON 表达，代码任务推荐使用 MODEL_TEMPLATE.json 的结构，包含 deliverable、entities、state_variables、actions、constraints、initial_state、goal、assumptions、unknowns、requirement_trace、test_oracles。
用法要点：模型创建后先做 MODEL AUDIT，检查覆盖性、可操作性、一致性、可测试性；不通过则回到阶段一修订。审计通过后模型视为只读事实来源。若实现中发现缺失信息，输出最小 MODEL PATCH 并从头重启阶段二。可写入 model.json 后用命令 python scripts/validate-model.py model.json 校验：退出码 0 表示有效可进入阶段二，1 表示结构无效需修复，2 表示有效但存在 unknowns，须停在阶段一。若 unknowns 非空则停止，不得实现。实现阶段输出编号计划（每步须是已定义动作的实例）、代码、覆盖全部 test_oracles 的测试，以及每条约束的验证映射（代码位置与测试）。
适用场景：复杂状态机、含不变量的业务逻辑、输入输出契约重要的数据转换、有依赖的多步工作流、安全关键功能、作为文档的协作规格。不适用于显式建模成本高于收益的简单单步任务。
限制：该技能要求严格分阶段，若模型未完成或审计未通过不得进入实现；发现未在模型中的需求须输出 MODEL INCOMPLETE 并停止；不得虚构 API 或依赖，未提供的要么询问（unknowns）要么创建明确标记 STUB 的桩。与其他推理策略（CoT、ReAct、规划智能体）互补而非竞争。官方文本与具体收费、平台、安装方式资料暂未提供。