Back to Details

figure-it-out

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Figure it out

自行探索解决方案（figure it out）

When the task matches no playbook, design one. The deliverable before any code is the workflow itself: a sequence of phases that scales rigor to the task, runs the scientific method, and leaves a decision trail a human can audit after stepping away. Bias toward more rigor. The cost of building the wrong thing dwarfs the cost of being careful.
Don't reinvent a playbook you already have. A focused single-unit task that matches Bug fix, Perf, Feature, Visual parity, Eval, or Multi-phase plan routes there. But a large or cross-cutting version of one (a migration across many call sites, an ambitious multi-part change), or work the user reviews after stepping away, belongs here even though a single-unit version would be a Feature. The rigor and the audit trail are the point.
当现有工作手册均不匹配当前任务时，需设计一份新的工作手册。编写代码前的交付物就是工作流本身：一系列能根据任务调整严谨程度、遵循科学方法、并留下可供人员事后审核的决策轨迹的阶段。倾向于更高的严谨性，因为构建错误产物的成本远高于谨慎行事的成本。
不要重复发明已有的工作手册。聚焦的单一单元任务如果符合Bug修复、性能优化、功能开发、视觉一致性、评估或多阶段计划的范畴，请沿用对应工作手册。但如果是这类任务的大型或跨领域版本（例如涉及多个调用点的迁移、宏大的多阶段变更），或是需要用户事后审核的工作，即使单一单元版本属于功能开发范畴，也应使用本工作手册。严谨性和审计轨迹是核心。

Start

启动

Open a todolist whose first item is to read the Principles section of the poteto-mode skill. Then add the phases below as todos.
创建一个待办事项列表，第一项是阅读poteto-mode技能的原则部分。然后将以下阶段添加为待办事项。

Phase A: Frame

阶段A：框架搭建

Ground first, then commit. Don't start the run until you can state:
  • The definition of done as a falsifiable predicate (the prove-it-works principle skill). "Done well" has to be checkable.
  • Scope, quantified: rough units and effort, plus the blockers grounding surfaced. Raise them before spending hours, not after fifty doomed commits.
  • The rigor level, biased high. One-way doors and high blast radius get more; reversible low-stakes steps get less. Rigor is gates and artifacts, not "try harder".
Present the framing and tradeoffs before committing to a long run. Reversible work proceeds (the never-block-on-the-human principle skill), but a multi-hour run earns one checkpoint.
先夯实基础，再投入执行。在能够明确以下内容之前，不要开始执行：
  • 可证伪的完成定义（遵循prove-it-works原则技能）。“出色完成”必须是可验证的。
  • 量化的范围：大致的工作量和投入，以及基础分析中发现的障碍。在花费数小时工作前就提出这些问题，而不是在提交五十次注定失败的代码后才提及。
  • 偏向高标准的严谨程度。单向决策和影响范围广的任务需要更高的严谨性；可逆的低风险步骤则可适当降低。严谨性体现在关卡和产出物上，而非“更努力尝试”。
在投入长时间工作前，先展示框架和权衡方案。可逆工作可以推进（遵循never-block-on-the-human原则技能），但耗时数小时的工作需要设置一个检查点。

Phase B: Design the workflow

阶段B：设计工作流

Decompose into atomic, independently-landable units. Sequence riskiest-unknown-first so option value stays high. Scaffold and verification come before features (the foundational-thinking principle skill).
  • Build the verification harness before the work, with the baseline captured from the pre-change state, so the check reads as "old value vs new value".
  • For one-way-door design decisions, run the architect skill (it runs arena) with diverse, isolated, opinionated candidates and a read-only judge on a different model family. Skip it for mechanical work whose shape is already concrete. A second arena over a settled design is over-engineering (the laziness-protocol principle skill).
  • Decide what fans out. Parallelize only across genuine seams, and give each worker its own worktree or branch (the separate-before-serializing-shared-state principle skill). Don't over-fan.
  • Write the designed phase list down. That list is what the human reviews.
Then put the design into motion. Add its steps to the todolist as concrete items, after the Phase C entry and before Phase D. Run each under the Phase C loop discipline, and weave the Phase D log through them, a row as each step lands, rather than saving the whole trail for the end.
将任务分解为原子化、可独立交付的单元。按风险未知程度从高到低排序，以保持较高的选项价值。先搭建基础架构并完成验证，再开发功能（遵循foundational-thinking原则技能）。
  • 在开始工作前构建验证工具，从变更前的状态捕获基线，以便检查时可以对比“旧值 vs 新值”。
  • 对于单向决策的设计方案，运行architect技能（该技能会调用arena），选择多样化、独立且有明确观点的候选方案，并由不同模型家族的只读评审员进行评审。对于形态已明确的机械性工作，可以跳过此步骤。对已确定的设计再次运行arena属于过度设计（遵循laziness-protocol原则技能）。
  • 确定哪些部分可以并行处理。仅在真正的业务边界处进行并行，并且为每个执行者分配独立的工作树或分支（遵循separate-before-serializing-shared-state原则技能）。不要过度拆分。
  • 将设计好的阶段列表记录下来。该列表是供人员审核的内容。
然后启动设计方案。将其步骤作为具体项添加到待办事项列表中，放在阶段C条目之后、阶段D之前。每个步骤都要遵循阶段C的循环规则，并在每个步骤完成时记录阶段D的日志，而不是等到最后再整理完整轨迹。

Phase C: Run the loop

阶段C：运行循环

Each unit is an experiment: state the hypothesis, make the smallest change, measure against the predicate on the real artifact, keep it if it advanced, revert it if it didn't. Apply the sequence-verifiable-units principle skill, verifying each unit before starting the next instead of batching checks at the end.
  • Verify by inspecting the artifact, never a self-report. When something passes too easily, suspect the observation method before the system. A blank screenshot passes a lazy gate.
  • Pair delegated work with a judge and audit the delegates' artifacts yourself before trusting them. If a worker games the gate, reset and harden the contract. If the gate itself is wrong, fix the gate in its own change rather than routing around it.
  • A verdict is VERIFIED, NOT VERIFIED, or INCONCLUSIVE. Inconclusive is not a pass. Don't hide a negative.
每个单元都是一次实验：提出假设，做出最小变更，针对真实产出物验证假设，如果推进了目标则保留变更，否则回退。 遵循sequence-verifiable-units原则技能，在开始下一个单元前先验证当前单元，而非在最后批量检查。
  • 通过检查产出物进行验证，绝不依赖自我报告。如果某件事轻易通过验证，先怀疑观察方法而非系统本身。空白截图可以通过草率的关卡。
  • 将委托工作与评审员配对，在信任委托者的产出物前自行审核。如果执行者绕过关卡，重置并强化规则。如果关卡本身存在问题，单独修改关卡，而非绕过它。
  • 验证结果分为VERIFIED（已验证）、NOT VERIFIED（未验证）或INCONCLUSIVE（不确定）。不确定不等于通过。不要隐瞒负面结果。

Phase D: Keep the audit trail

阶段D：保留审计轨迹

Log the run via the show-me-your-work skill, one canonical TSV with a row per decision and per unit, evidence as links. figure-it-out's work is usually ambitious enough to commit the trail so the reviewer can read it in the PR; commit it when confidence has to be shown. Prefer evidence produced by committed scripts so a reviewer can re-run it. The trail plus the diff is what lets the human come back and trust the work.
通过show-me-your-work技能记录执行过程，使用一份标准TSV文件，每行记录一个决策或单元，证据以链接形式呈现。自行探索解决方案的工作通常足够重要，因此需要将轨迹提交到PR中供评审者查看；当需要展示信心时提交轨迹。优先使用已提交脚本生成的证据，以便评审者可以重新运行。轨迹加上代码差异，是让人员事后能信任工作成果的关键。

Phase E: Verify and hand back

阶段E：验证并交付

Check the whole against the Phase A predicate on the real product, not just the harness. Encode any recurring correction as a gate, a lint rule, a check, or a script, so the win can't silently regress (the encode-lessons-in-structure principle skill).
Reply: the playbook you designed, the rigor level and why, the decision-trail path, what's verified against the predicate, and what's still open.
对照阶段A的完成定义，在真实产品上检查整体成果，而不仅仅是验证工具。将任何反复出现的修正编码为关卡、lint规则、检查项或脚本，确保成果不会悄然退化（遵循encode-lessons-in-structure原则技能）。
回复内容： 你设计的工作手册、严谨程度及原因、决策轨迹路径、已对照完成定义验证的内容，以及仍未解决的问题。