figure-it-out 用于当任务没有更窄的现成 playbook 可套用时，自行设计一套可审计的工作流。适用场景包括大型迁移、雄心勃勃的多部分改动，或人类离开后回来审查的工作。
使用前需先阅读 T3 execution，它定义全局配置、容量选择与传输约束；其顶层对话要求适用于每次启动，否则应使用受支持的子隔离或报告运行时限制。
流程以 todolist 开始，第一项是阅读 poteto-mode 技能的 Principles 部分，然后加入以下阶段：
Phase A 框定：先接地再承诺。需能陈述可证伪的完成定义、量化范围与阻塞项、偏高的严谨级别。长时间运行前展示框定与权衡，可逆工作继续推进，但多小时运行应设一个检查点。
Phase B 设计工作流：拆分为原子、可独立落地的单元，风险最高的未知优先。先搭脚手架与验证，再写功能。在动手前构建验证工具并捕获改动前基线。单向门设计决策运行 architect 技能，机械性工作可跳过。决定哪些可并行，仅在接缝处并行，每个写入者通过 t3_thread_launch 配 workspaceStrategy 获得独立 worktree。每个 delegate_task 简报独立，只读工作者简报需注明只读、仅检查、不写入。模型从 pstack-models.md 的命名角色经 orchestrator_capabilities 解析，不要硬编码 slug。写下设计好的阶段列表供人审查，再执行。
Phase C 运行循环：每个单元是一个实验，陈述假设、做最小改动、对真实产物按谓词测量，推进则保留，否则回退。逐单元验证，不要批量检查。通过检查产物验证，而非自报。委派工作配 judge。用 task_status 排空后台工作，PR 在途可用 watch_pull_request，周期检查用 schedule_task。结论为 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE，不确定不算通过，不要隐藏负面结果。
Phase D 保留审计轨迹：通过 show-me-your-work 技能记录运行，通常将轨迹提交到 PR，轨迹加 diff 让人能回来信任工作。
Phase E 验证并交回：对真实产品按 Phase A 谓词检查整体，将重复纠正编码为门、lint 规则、检查或脚本。回复应包含设计的 playbook、严谨级别及原因、决策轨迹路径、已按谓词验证的内容和仍开放的事项。