figure-it-out

自行判断

当任务不符合任何操作手册时，就设计一个。编写任何代码之前，交付物必须是工作流本身：一系列阶段，其严谨程度与任务相匹配，遵循科学方法，并留下决策记录，让人离开后也能审计。

以粗体标出的原则都在 principles 技能中。调用 Skill 工具时，将 principles 作为任务列表中的第一项；应用每项命名的原则时，都要阅读其文件。

开始

创建任务列表（使用你所用工具链中的任务工具；如果没有任务工具，则在 ~/.local/state/ox/checklists/<repo>-<branch>.md 创建清单文件），并将阅读 principles 索引作为第一项。然后将以下阶段添加为待办事项。

阶段 A：界定

先了解情况，再做决定。在能够陈述以下内容之前，不要开始执行：

• 根据 证明它有效，将完成定义为可证伪的判定条件。
• 量化范围：估算单位和工作量，以及了解情况时发现的阻碍。
• 严谨程度要偏高。不可逆的决策和影响范围大的事项需要更严谨；可逆且风险较低的步骤则可以放宽。严谨程度体现在关卡和产物上，而不是“更加努力”。

将界定内容及其权衡写入决策日志，作为第一批记录（阶段 D），然后开始执行。根据 永不等待人工响应，可逆的工作无需等待即可推进。

阶段 B：设计工作流

将工作拆解为原子化、可独立交付的单元。优先处理未知风险最高的部分。根据 基础思维，先搭建脚手架并验证，再开发功能。

• 在开始工作前，于仓库之外构建验证检查，并基于变更前状态记录基线，这样检查就能对比“旧值与新值”。根据 证明它有效。
• 对于不可逆的设计决策，调用 Skill 工具并使用 architect（它会运行 arena）。对于形态已明确的机械性工作，则跳过这一步。根据 惰性协议，对已确定的设计再次运行 arena 属于过度设计。
• 确定哪些工作可以并行展开。仅在工作边界清晰时并行；根据 先分离，再序列化共享状态，先提交所有准备工作，然后为每位工作者运行 git worktree add <path> -b <branch> <that commit>，为其创建独立的 Git 工作树。若要同时使用多位工作者，请调用 Skill 工具并使用 swarm。不要过度并行。
• 记录设计好的阶段列表，供人工审查。

然后执行该设计。将各步骤作为具体事项添加到任务列表中的阶段 C 和阶段 D 条目之间。每一步都遵循阶段 C 的循环纪律，并在执行过程中穿插记录阶段 D 日志：每完成一步就记录一行，不要等到最后才补全全部记录。

阶段 C：运行循环

每个单元都是一次实验。说明假设，做最小改动，根据真实产物和判定条件进行衡量；如果改动带来了进展，就保留；如果没有，就撤销。应用 将工作拆分为可验证的单元，每完成一个单元就先验证，再开始下一个，而不是把所有检查都留到最后。

• 通过检查产物来验证，绝不依赖自我报告。若某项检查过于轻松就通过了，应先怀疑观察方法，而不是系统本身。
• 委派工作时，必须配备评审者。如果工作者钻了验证关卡的空子，就重置并强化约定。如果关卡本身有问题，就通过单独的变更修复关卡，而不是绕过它。
• 结论只能是 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE。INCONCLUSIVE 不算通过。不要隐瞒负面结果。

阶段 D：保留审计记录

通过 show-me-your-work 技能记录执行过程（调用 Skill 工具并使用该技能）。figure-it-out 的工作通常颇具雄心，因此一般应提交记录，以便评审者能在 PR 中阅读。记录加上差异内容，才能让人工审查者回来后仍能信任这项工作。

阶段 E：验证并交接

针对真实产物（而不只是测试框架）检查整个流程是否符合阶段 A 中的判定条件。根据 将经验教训固化到结构中，将任何反复出现的修正编码为门禁、lint 规则、检查或脚本。

**回复：**你设计的操作手册、严谨程度及原因、决策轨迹路径、已根据判定条件验证的内容，以及仍待解决的问题。