用途
figure-it-out 面向“没有现成 playbook 可匹配”的任务。典型场景包括：大型迁移、目标宏大的多部分改动，以及执行者离开后需要由人工审查的工作。它的核心交付物不是代码，而是工作流本身：一组按任务调节严谨程度的阶段，运行科学方法，并留下人可以事后审计的决策轨迹。
前置要求
使用前，每个会话需先读取一次 host adapter。它把上游 Cursor 专用的工具、模型、路径和权限指令映射到宿主环境，并设定权限边界。
使用方式
开始时先打开一个 todolist，第一项是阅读 saltmode 技能的 Principles 章节，随后把下列阶段加入 todo。
阶段 A：框定（Frame）
先立地基再承诺。在开始长跑之前，需要能说明：
- 完成定义，写成可证伪的谓词（prove-it-works 原则技能）。
- 量化范围：粗略单元与工作量，以及立地基时暴露出的阻塞项。
- 严谨等级，且偏向高估。单向门和高影响面的步骤要求更多严谨；可逆、低风险的步骤要求较少。严谨指的是闸门与产物，不是“更努力一点”。
- 在承诺长时间运行前，先呈现框定与权衡。可逆工作直接推进（never-block-on-the-human 原则技能），但数小时的运行值得设置一个检查点。
阶段 B：设计工作流
- 拆分为原子化、可独立落地的单元，按“最未知风险优先”排序；脚手架与验证先于功能（foundational-thinking 原则技能）。
- 在工作开始前搭好验证工具链，并从改动前状态捕获基线，使校验呈现为“旧值 vs 新值”。
- 对单向门式的设计决策，运行 architect 技能（它会运行 arena）；对于形态已经具体的机械性工作则跳过，已定设计再开一次 arena 属于过度工程（laziness-protocol 原则技能）。
- 决定哪些部分可以并行：只在接缝处并行，每个工作者拥有独立 worktree 或分支（separate-before-serializing-shared-state 原则技能），避免过度并行。子代理的推理等级与速度按 saltmode 技能 Subagents 章节选择。
- 把设计好的阶段清单写下来，这份清单就是人工审查的对象。
- 然后执行设计：把具体步骤作为条目插入 todolist 的 Phase C 与 Phase D 之间，在 Phase C 循环纪律下运行，并把 Phase D 的记录贯穿其中——每一步落地就记一行，而不是把全部轨迹留到最后。
阶段 C：运行循环
每个单元都是一次实验：陈述假设，做最小改动，针对真实产物按谓词测量，有推进则保留，否则回滚。应用 sequence-verifiable-units 原则技能，逐个单元验证后再开始下一个，而不是把检查批量留到最后。
验证必须检查产物本身，绝不依赖自述。若某项过于轻易通过，先怀疑观测方法再怀疑系统。委派的工作要配上裁判；若工作者钻了闸门的空子，重置并加固契约；若闸门本身有误，在其独立变更中修复闸门，而不是绕过它。结论分为 VERIFIED、NOT VERIFIED、INCONCLUSIVE，INCONCLUSIVE 不算通过，不得隐藏负面结果。
阶段 D：保留审计轨迹
通过 show-me-your-work 技能记录运行。figure-it-out 的工作通常足够重要，值得把轨迹提交，让审查者在 PR 中阅读。轨迹加 diff 才能让人回来信任这项工作。
阶段 E：验证与交接
在真实产品上、按阶段 A 的谓词检查整体，而不只是检查工具链。把任何反复出现的修正固化为闸门、lint 规则、检查或脚本（encode-lessons-in-structure 原则技能）。
回复中应包含：所设计的 playbook、严谨等级及理由、决策轨迹路径、按谓词已验证的内容，以及仍未解决的事项。
明确验证治理
当任务构建或审计已采纳的覆盖策略、证明清单或 CI 闸门时，需阅读治理指南；普通功能或测试改动不采用这些机制。
适用场景与限制
适用于缺少现成方案、且需要可审计决策痕迹的大型或复杂工作。不适用于已有明确形态的机械性工作（此时不应重复开 arena）。使用它需要遵循宿主适配、原则技能与子代理配置；当前资料未提供收费、价格、平台等更多信息。