figure-it-out

弄清楚

当任务不符合任何操作手册时，就设计一套。编写任何代码之前，先交付工作流本身：一系列阶段，能根据任务调整严谨程度，遵循科学方法，并留下决策记录，让人类离开后也能审计。

开始

创建一个待办清单，第一项是阅读 poteto-mode 技能的 Principles 部分。然后将以下阶段添加为待办事项。

阶段 A：界定

先充分了解，再做决定。在能明确说明以下内容之前，不要开始执行：

• 将完成定义为可证伪的谓词（prove-it-works 原则技能）。
• 量化范围：粗略估算工作单元和工作量，并列出调研发现的阻碍因素。
• 严谨程度，倾向从高。单向门决策和影响范围大的事项要更严谨；可逆、低风险的步骤则可放宽。严谨程度体现在关卡和产物上，而不是“更加努力”。

在投入长时间执行之前，先说明界定结果和权衡。可逆的工作继续推进（never-block-on-the-human 原则技能），但数小时的执行过程应设置一个检查点。

阶段 B：设计工作流

将工作拆解为原子化、可独立交付的单元。优先处理最不确定、风险最高的事项。先搭建脚手架并完成验证，再开发功能（foundational-thinking 原则技能）。

• 在开始工作前搭建验证测试框架，并从变更前状态采集基线，这样检查结果就能体现为“旧值与新值”。
• 对单向门设计决策，运行 architect 技能（它会运行 arena）。对于形态已明确的机械性工作，则跳过。设计已经敲定后再进行第二轮 arena 就属于过度设计（laziness-protocol 原则技能）。
• 决定哪些工作可以并行展开。只在边界清晰的任务之间并行，并为每个工作者分配各自的 worktree 或分支（separate-before-serializing-shared-state 原则技能）。不要过度并行。根据工作内容，为每个子 Agent 选择合适的推理级别，参照 poteto-mode 技能的 Subagents 部分。
• 记录设计好的阶段列表。这份列表供人类审阅。

然后执行设计。将其中的步骤作为具体事项，添加到待办清单中 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 中查看。记录加上差异，是人类日后重拾工作并信任成果的依据。

阶段 E：验证并交接

根据真实产品上的 Phase A 谓词检查整体成果，而不只是测试框架。将反复出现的修正编码为关卡、lint 规则、检查或脚本（encode-lessons-in-structure 原则技能）。

**回复：**你设计的操作手册、严谨程度及其原因、决策记录的路径、根据谓词已验证的内容，以及仍未解决的事项。