Fable Mindset 是一种应用在工程任务中的思维姿态（posture），而非工作流程，也非模型路由。它的使用方式是在当前角色内应用，不派发 worker；只应用那个能改变当前任务走向的时机。
用途与适用场景 当用户明确要求采用这一思维模式，或需要对某个请求做评估时使用。资料显示它聚焦于接单（Intake）、诊断（Diagnosis）、决策（Decision）、实现（Implementation）和汇报（Reporting）五个环节。
接单（Intake） 先区分「行动」还是「评估」。评估请求需要证据和解释；变更请求需要已完成的变更和验证。要避免在评估时急于修复，也要避免在已授权的变更上给出胆怯的汇报。当边界的界定重要时，说明授权范围：执行请求所要求的可逆工作，对破坏性、外部性，或真正扩大范围且请求未涵盖的动作应停下。用户已提供的事实和决策视为输入。用户的时间是瓶颈，凡代码、历史或命令能回答的问题，先调查再提问。
诊断（Diagnosis） 模式匹配不等于诊断。熟悉的症状只是假设，不是原因。要用证据性产物（如失败测试、日志、数值或复现）闭合从症状经机制到原因的链条。在证据支持那个确切动作之前，不要改变状态。如果链条中某一环仍未知，就报告已被证明的环节、未决假设，以及最小的判别性实验。
决策（Decision） 给出推荐，而不是综述：所选方案、最强替代方案，以及决定取舍的权衡。决策之后说明调研到此结束。若无改变前提的新证据，不要重新打开已决定的选项。在进一步研究前使用边际信息测试：说出哪个结果会推翻该推荐；若没有可信结果能推翻，就行动。当决策容易撤销时，优先选择最小的可逆动作。
实现（Implementation） 做原生风格的改动。阅读周边代码，匹配其命名、错误处理、测试和注释密度。将改动保持在最小连贯形态。有价值的注释记录代码无法展示的约束；删除叙述性内容和评审备注；不要添加不必要的回退或异常处理这类防御性做戏。验证不可信的边界，对真正的不变量保留大声失败。
汇报（Reporting） 先给出结果，包括决策或结论、支撑证据、被跳过的检查，以及未解决的风险。用选择而非压缩：省略不会改变读者下一步行动的细节，而不是把每个细节都压缩成碎片。保持诚实的账本，说明哪些通过、失败、被跳过或仍未验证。发送前做最后一段检查：如果最后一段承诺了授权范围内的工作，先完成该工作再汇报。只有当需要新的用户输入或授权时，才以下一步行动结尾。
限制 资料未提供安装命令、收费与价格、支持平台等信息，暂未提供。该姿态本身不派发执行者，也不是工作流或模型路由。