figure-it-out

弄清楚

以粗体或反引号标出的技能名称，或以 /<name> 形式运行的技能，是位于此技能目录旁边的 ../<name>/SKILL.md 文件；不带前缀的原则名称对应 ../principle-<name>/SKILL.md。读取该文件并遵循其中的说明。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。

如果任务不符合任何操作手册，就设计一个。编写任何代码之前，必须先交付工作流本身：制定一系列阶段，使严谨程度与任务相匹配，遵循科学方法，并留下决策记录，以便人类离开后仍能审查。

开始

创建任务列表（使用你的 harness 任务工具；如果没有，则使用 ~/.local/state/pstack/checklists/<repo>-<branch>.md 检查清单文件），并将第一项设为阅读 poteto-mode 技能的 Principles 部分。然后将以下阶段添加为待办事项。

阶段 A：界定任务

先打好基础，再做出承诺。在能够明确说明以下内容之前，不要开始执行：

• 可证伪的完成定义（prove-it-works 原则技能）。
• 量化的范围：大致的工作单位和工作量，以及打好基础时发现的阻碍。
• 严谨程度，原则上偏高。不可逆的决策和影响范围大的事项需要更高严谨度；可逆且风险低的步骤则可降低严谨度。严谨度体现为关卡和产物，而不是“更努力地尝试”。

做出长期执行的承诺之前，先展示任务界定和权衡。可逆的工作继续推进（never-block-on-the-human 原则技能）；耗时数小时的执行则需设置一个检查点。

阶段 B：设计工作流

将工作拆分为原子化、可独立合并的单元，并优先处理未知风险最高的部分。先搭建脚手架并完成验证，再实现功能（foundational-thinking 原则技能）。

• 在开始工作之前搭建验证工具，并记录变更前的基线，以便检查结果能直观呈现“旧值与新值”的对比。
• 对于不可逆的设计决策，运行 architect 技能（它会运行 arena）。对于形态已经明确的机械性工作，则跳过。对已确定的设计再运行一次 arena 属于过度设计（laziness-protocol 原则技能）。
• 决定哪些工作需要并行展开。仅跨越明确的界面并行处理；为每位工作者通过带有工作树 workspaceStrategy 的 t3_thread_launch 线程分配独立的工作树或分支（separate-before-serializing-shared-state 原则技能）。先提交验证工具和所有准备工作，并将该提交用作 baseRef。不要过度并行。根据 poteto-mode 技能的 Subagents 部分，为每个子 Agent 选择适合任务的推理级别，以及快速或标准速度。
• 将设计好的阶段列表写下来，供人类审阅。

随后执行设计。将每个步骤作为具体待办事项添加到任务列表中，放在阶段 C 和阶段 D 条目之间。按照阶段 C 的循环规范逐项执行，并在每一步完成时将记录穿插到阶段 D 的日志中，而不是等到最后才补写全部记录。

阶段 C：执行循环

每个单元都是一次实验。陈述假设，做出最小改动，针对实际产物按判定条件进行测量；若改动有所推进则保留，否则回退。遵循 sequence-verifiable-units 原则技能，逐个验证每个单元后再开始下一个，而不是把所有检查集中到最后。

• 通过检查产物来验证，绝不依赖自我报告。当某项检查轻而易举就通过时，应先怀疑观测方法，再怀疑系统。
• 委派工作时配对一名评审者。如果工作者钻验证关卡的空子，就重置并强化约定。如果关卡本身有误，就通过单独的变更修正关卡，而不是绕过它。
• 结论只能是 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE。INCONCLUSIVE 不算通过。不要掩盖负面结果。

阶段 D：保留审计记录

使用 show-me-your-work 技能记录执行过程。figure-it-out 的工作通常规模较大，值得提交记录，以便审查者能在 PR 中查看。记录和差异共同构成依据，让人类日后回来时仍能信任这项工作。

阶段 E：验证并交接

在真实产品上对照阶段 A 的谓词检查整体结果，而不只是检查测试框架。将任何反复出现的修正编码为关卡、lint 规则、检查项或脚本（将经验教训编码进结构原则技能）。

**回复：**你设计的操作手册、严格程度及其原因、决策追踪路径、已对照谓词验证的内容，以及仍未解决的问题。