为 Agent 设计可审计的专属工作流pstack figure-it-out 技能完全指南【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/pluginspstack 的figure-it-out是一套「当现成 playbook 都不适用时为任务量身设计一份可审计工作流」的元技能。它以科学方法假设—实验—测量—保留或回滚为核心用五个阶段Frame / Design / Run / Audit / Hand back把一次大规模迁移或雄心勃勃的多部分改动组织成可验证、可追溯、人能中途离开也能回来审查的工程过程。读完本文你将掌握 figure-it-out 的完整阶段协议、它调用的原则技能与配套工具architect、show-me-your-work 等如何咬合以及如何在 pstack 的 poteto-mode 体系中触发和落地它。figure-it-out 在 pstack 生态中的定位pstack 的 poteto-mode 技能内置了二十三个 playbookbug fix、perf、feature、refactoring、hillclimb、visual parity 等覆盖绝大多数日常任务。但总有一些任务匹配不上任何更窄的 playbook一场横跨许多调用点的大迁移、一个多阶段的多部分改动、或者用户离开后需要回来信任其结果的工作。这正是 figure-it-out 的适用场景——它不执行某个具体任务而是先设计出执行该任务的工作流本身。figure-it-out 在自己的 frontmatter 中如此描述触发条件Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions via show-me-your-work.也就是说可审计auditable、按任务缩放严格程度scales rigor、运行假设循环hypothesis loop、通过 show-me-your-work 记录决策。与 Orchestrate 的分工在 poteto-mode 主技能 中写得很清楚figure-it-out为一次量身定制的运行设计工作流而 Orchestrate 负责长期、多 PR、多子代理的常驻项目程序。用户走开前说 migrate every caller from the synchronous store to the new async one, keeping behavior identical. I want to trust it was done right when Im back 这类请求就应路由到 figure-it-out。启动先读原则再排 todofigure-it-out 的 Start 阶段只有一条硬性指令Open a todolist whose first item is to read the Principles section of thepoteto-modeskill. Then add the phases below as todos.即打开 todolist第一项是通读 poteto-mode 技能 的 Principles 一节23 条原则的索引然后把 A–E 五个阶段作为后续 todo 加入。因为 figure-it-out 的每个阶段都会引用具体的原则技能先建立原则心智模型后面每一步才有据可依。Phase A: Frame —— 先落地再承诺在启动任何长耗时运行之前必须先能陈述三件事完成的定义是一句可证伪的谓词。这对应 prove-it-works 原则验证必须针对真实产物运行功能、读取实际值、检查 diff而不是代理自述或它能编译。可证伪意味着存在一个明确的不通过状态而不是模糊的尽量做好。范围要量化。粗略的单元数和工时估计加上已浮出水面的阻塞因素。量化不是精确预测而是让这条运行到底有多大成为可讨论的事实。严格程度偏向更高。一次性门one-way doors和高爆炸半径high blast radius的工作获得更多门禁与产物可逆、低风险的步骤获得更少。严格rigor是门禁和产物gates and artifacts不是更努力。框架和权衡要在投入长运行之前呈现给人类。可逆的工作直接推进依据 never-block-on-the-human 原则可逆动作不阻塞、事后由人纠偏但一个数小时的运行应当争取一次人类检查点。Phase B: Design the workflow —— 设计工作流本身这是 figure-it-out 与普通 playbook 最大的不同交付物在写任何代码之前就是工作流本身——一系列按任务缩放严格程度的阶段序列。分解与排序把工作分解为原子、可独立落地的单元风险未知者优先riskiest-unknown-first。脚手架和验证要先于功能建设依据 foundational-thinking 原则数据结构先行、为后续所有阶段服务的东西CI、lint、测试基础设施、共享类型先做小步提交、单一目的。先建验证脚手架在动手之前就搭好验证脚手架verification harness并从改动前的状态抓取基线baseline这样检查读起来就是旧值 vs 新值。这与 sequence-verifiable-units 原则 的 before/after 括号一脉相承已知良好状态 → 一次改动 → 运行检查 → 再前进每个单元结束后都处于可验证状态绝不把检查拖到最后的批量。一次性门设计交给 architect对于一次性门的设计决策运行 architect 技能它会再运行 arena 做多模型并行设计竞争。但机械性、形态已经具体的工作可以直接跳过——对已定稿的设计再做一次 arena 竞争就是过度工程依据 laziness-protocol 原则偏向删除与最小的解决改动。决定什么可以并行并行只跨接缝seams进行且每个 worker 要有自己的 worktree 或分支依据 separate-before-serializing-shared-state 原则并发 actor 共享可变状态时先消除共享只在共享写入者是真实不变量时才结构化串行化。不要过度 fan-out。写下来把设计好的阶段列表写下来——这份列表就是人类要审查的对象。然后执行设计把它的步骤作为具体条目加入 todolist放在 Phase C 条目之后、Phase D 之前每一步都在 Phase C 的循环纪律下运行并让 Phase D 的日志贯穿其中每落地一步写一行而不是把整条轨迹留到最后一次性补写。Phase C: Run the loop —— 每个单元都是一次实验Phase 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 didnt.每个单元陈述假设 → 做最小改动 → 在真实产物上对照谓词测量 → 推进了就保留没推进就回滚。配合 sequence-verifiable-units 原则在开始下一个单元前验证当前单元而不是在最后批量检查。循环纪律有三条关键规则验证靠检查产物绝不靠自述。当某件事通过得太容易时先怀疑观察方法再怀疑系统本身这也是 prove-it-works 的明确告诫验证失败时先怀疑观察方法而非系统。委托的工作要配对裁判。自己先审计委托方的产物再信任它们。如果某个 worker 钻了门禁的空子就重置并加固契约如果门禁本身是错的就用一次独立的改动修门禁而不是绕过去。判决只有三种VERIFIED、NOT VERIFIED、INCONCLUSIVE。INCONCLUSIVE 不等于通过。不要藏起负面结果。Phase D: Keep the audit trail —— 用 TSV 留住决策轨迹运行过程通过 show-me-your-work 技能 记录一份规范的 TSV每个决策/单元一行证据以链接形式存在。figure-it-out 的工作通常野心够大值得把轨迹提交进仓库让审查者在 PR 里直接阅读当必须展示可信度时就提交它。优先使用由已提交脚本产生的证据。TSV 的列结构在 show-me-your-work 技能 中有精确定义模板头部见其references/decision-log-template.tsv列含义tsISO8601 时间戳phase阶段或工作流decision做了什么选择一行why用大白话写的理由如果是原则驱动的说人话而不是贴标签evidence证明它的链接或路径commit SHA、PR 号、file:line、产物/轨迹/截图路径永远不是一段话result结果或谓词状态tests green、reverted、pixel-diff 0、INCONCLUSIVE、open日志是追加式的append-only判断错了就新增一行覆盖它绝不编辑或删除历史。写入时可用辅助脚本scripts/log.sh logfile phase decision why evidence result它会打时间戳、首次使用写表头、剥离制表符与换行并对以、、-、开头的单元格加单引号前缀。记录的是决策点和检查点选择的分叉、完成的单元及其验证结果、带触发的转向/回滚、浮出水面的阻塞、修好的门禁而不是每一个动作。审查时column -s$\t -t decisions.tsv可在终端渲染。轨迹加 diff就是人类回来时愿意信任这份工作的依据。Phase E: Verify and hand back —— 整体验证并交还收尾时在真实产品上整体核对 Phase A 的谓词而不是只核对测试脚手架。把任何反复出现的纠正编码进结构门禁、lint 规则、检查或脚本依据 encode-lessons-in-structure 原则——结构性机制lint 规则、元数据标志、运行时检查、自动化脚本不依赖读者的自觉就能强制规则文本指令会被忽略。最后回复必须包含你设计的 playbook、严格级别及理由、决策轨迹路径、对照谓词已验证了什么、还有什么悬而未决。原则体系figure-it-out 的地基figure-it-out 不是孤立的技能它是一张原则调用网。下表汇总了它显式引用的原则技能及其在方法中的角色原则技能在 figure-it-out 中的角色prove-it-worksPhase A 可证伪完成定义Phase C 针对真实产物验证never-block-on-the-humanPhase A 可逆工作不阻塞数小时运行争取一个检查点foundational-thinkingPhase B 脚手架与验证先于功能laziness-protocolPhase B 对已定稿设计不做第二次 arena避免过度工程separate-before-serializing-shared-statePhase B 跨接缝并行每人一个 worktree/分支sequence-verifiable-unitsPhase C 逐单元验证不批量检查encode-lessons-in-structurePhase E 反复纠正编码为门禁/lint/脚本如何触发与落地figure-it-out 在 pstack/README.md 的技能表中被标注为没有捆绑 playbook 适用时为任务设计一份严格、可审计的 playbook。在 poteto-mode 主技能 的路由规则中大而跨切面的工作跨许多调用点的迁移、雄心勃勃的多部分改动、或用户离开后要回来信任的工作即使有 Feature 这类更窄的 playbook 可匹配也会路由到 figure-it-out。pstack/README.md 给出的一句话示例figure it out: /poteto-mode im stepping away. migrate every caller from the synchronous store to the new async one, keeping behavior identical. i want to trust it was done right when im back.在实践中落地 figure-it-out需要先通过/setup-pstack完成 pstack 安装与模型配置见 README然后以/poteto-mode进入粘性模式把上述这类任务交给它。figure-it-out 会自行完成先读原则、打开带阶段 todo 的清单、把 Phase A 的框架呈现出来争取检查点、写出阶段列表供人审查、逐单元执行假设循环、用 show-me-your-work 的 TSV 贯穿全程记录最后以轨迹 diff交还给人审查。整个过程的设计目标始终如一把相信我变成看着它从红变绿让人可以放心走开再带着完整证据回来。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 4:13:23 · 阅读 1.2k 为 Agent 设计可审计的专属工作流：pstack figure-it-out 技能完全指南
为 Agent 设计可审计的专属工作流pstack figure-it-out 技能完全指南【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/pluginspstack 的figure-it-out是一套「当现成 playbook 都不适用时为任务量身设计一份可审计工作流」的元技能。它以科学方法假设—实验—测量—保留或回滚为核心用五个阶段Frame / Design / Run / Audit / Hand back把一次大规模迁移或雄心勃勃的多部分改动组织成可验证、可追溯、人能中途离开也能回来审查的工程过程。读完本文你将掌握 figure-it-out 的完整阶段协议、它调用的原则技能与配套工具architect、show-me-your-work 等如何咬合以及如何在 pstack 的 poteto-mode 体系中触发和落地它。figure-it-out 在 pstack 生态中的定位pstack 的 poteto-mode 技能内置了二十三个 playbookbug fix、perf、feature、refactoring、hillclimb、visual parity 等覆盖绝大多数日常任务。但总有一些任务匹配不上任何更窄的 playbook一场横跨许多调用点的大迁移、一个多阶段的多部分改动、或者用户离开后需要回来信任其结果的工作。这正是 figure-it-out 的适用场景——它不执行某个具体任务而是先设计出执行该任务的工作流本身。figure-it-out 在自己的 frontmatter 中如此描述触发条件Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions via show-me-your-work.也就是说可审计auditable、按任务缩放严格程度scales rigor、运行假设循环hypothesis loop、通过 show-me-your-work 记录决策。与 Orchestrate 的分工在 poteto-mode 主技能 中写得很清楚figure-it-out为一次量身定制的运行设计工作流而 Orchestrate 负责长期、多 PR、多子代理的常驻项目程序。用户走开前说 migrate every caller from the synchronous store to the new async one, keeping behavior identical. I want to trust it was done right when Im back 这类请求就应路由到 figure-it-out。启动先读原则再排 todofigure-it-out 的 Start 阶段只有一条硬性指令Open a todolist whose first item is to read the Principles section of thepoteto-modeskill. Then add the phases below as todos.即打开 todolist第一项是通读 poteto-mode 技能 的 Principles 一节23 条原则的索引然后把 A–E 五个阶段作为后续 todo 加入。因为 figure-it-out 的每个阶段都会引用具体的原则技能先建立原则心智模型后面每一步才有据可依。Phase A: Frame —— 先落地再承诺在启动任何长耗时运行之前必须先能陈述三件事完成的定义是一句可证伪的谓词。这对应 prove-it-works 原则验证必须针对真实产物运行功能、读取实际值、检查 diff而不是代理自述或它能编译。可证伪意味着存在一个明确的不通过状态而不是模糊的尽量做好。范围要量化。粗略的单元数和工时估计加上已浮出水面的阻塞因素。量化不是精确预测而是让这条运行到底有多大成为可讨论的事实。严格程度偏向更高。一次性门one-way doors和高爆炸半径high blast radius的工作获得更多门禁与产物可逆、低风险的步骤获得更少。严格rigor是门禁和产物gates and artifacts不是更努力。框架和权衡要在投入长运行之前呈现给人类。可逆的工作直接推进依据 never-block-on-the-human 原则可逆动作不阻塞、事后由人纠偏但一个数小时的运行应当争取一次人类检查点。Phase B: Design the workflow —— 设计工作流本身这是 figure-it-out 与普通 playbook 最大的不同交付物在写任何代码之前就是工作流本身——一系列按任务缩放严格程度的阶段序列。分解与排序把工作分解为原子、可独立落地的单元风险未知者优先riskiest-unknown-first。脚手架和验证要先于功能建设依据 foundational-thinking 原则数据结构先行、为后续所有阶段服务的东西CI、lint、测试基础设施、共享类型先做小步提交、单一目的。先建验证脚手架在动手之前就搭好验证脚手架verification harness并从改动前的状态抓取基线baseline这样检查读起来就是旧值 vs 新值。这与 sequence-verifiable-units 原则 的 before/after 括号一脉相承已知良好状态 → 一次改动 → 运行检查 → 再前进每个单元结束后都处于可验证状态绝不把检查拖到最后的批量。一次性门设计交给 architect对于一次性门的设计决策运行 architect 技能它会再运行 arena 做多模型并行设计竞争。但机械性、形态已经具体的工作可以直接跳过——对已定稿的设计再做一次 arena 竞争就是过度工程依据 laziness-protocol 原则偏向删除与最小的解决改动。决定什么可以并行并行只跨接缝seams进行且每个 worker 要有自己的 worktree 或分支依据 separate-before-serializing-shared-state 原则并发 actor 共享可变状态时先消除共享只在共享写入者是真实不变量时才结构化串行化。不要过度 fan-out。写下来把设计好的阶段列表写下来——这份列表就是人类要审查的对象。然后执行设计把它的步骤作为具体条目加入 todolist放在 Phase C 条目之后、Phase D 之前每一步都在 Phase C 的循环纪律下运行并让 Phase D 的日志贯穿其中每落地一步写一行而不是把整条轨迹留到最后一次性补写。Phase C: Run the loop —— 每个单元都是一次实验Phase 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 didnt.每个单元陈述假设 → 做最小改动 → 在真实产物上对照谓词测量 → 推进了就保留没推进就回滚。配合 sequence-verifiable-units 原则在开始下一个单元前验证当前单元而不是在最后批量检查。循环纪律有三条关键规则验证靠检查产物绝不靠自述。当某件事通过得太容易时先怀疑观察方法再怀疑系统本身这也是 prove-it-works 的明确告诫验证失败时先怀疑观察方法而非系统。委托的工作要配对裁判。自己先审计委托方的产物再信任它们。如果某个 worker 钻了门禁的空子就重置并加固契约如果门禁本身是错的就用一次独立的改动修门禁而不是绕过去。判决只有三种VERIFIED、NOT VERIFIED、INCONCLUSIVE。INCONCLUSIVE 不等于通过。不要藏起负面结果。Phase D: Keep the audit trail —— 用 TSV 留住决策轨迹运行过程通过 show-me-your-work 技能 记录一份规范的 TSV每个决策/单元一行证据以链接形式存在。figure-it-out 的工作通常野心够大值得把轨迹提交进仓库让审查者在 PR 里直接阅读当必须展示可信度时就提交它。优先使用由已提交脚本产生的证据。TSV 的列结构在 show-me-your-work 技能 中有精确定义模板头部见其references/decision-log-template.tsv列含义tsISO8601 时间戳phase阶段或工作流decision做了什么选择一行why用大白话写的理由如果是原则驱动的说人话而不是贴标签evidence证明它的链接或路径commit SHA、PR 号、file:line、产物/轨迹/截图路径永远不是一段话result结果或谓词状态tests green、reverted、pixel-diff 0、INCONCLUSIVE、open日志是追加式的append-only判断错了就新增一行覆盖它绝不编辑或删除历史。写入时可用辅助脚本scripts/log.sh logfile phase decision why evidence result它会打时间戳、首次使用写表头、剥离制表符与换行并对以、、-、开头的单元格加单引号前缀。记录的是决策点和检查点选择的分叉、完成的单元及其验证结果、带触发的转向/回滚、浮出水面的阻塞、修好的门禁而不是每一个动作。审查时column -s$\t -t decisions.tsv可在终端渲染。轨迹加 diff就是人类回来时愿意信任这份工作的依据。Phase E: Verify and hand back —— 整体验证并交还收尾时在真实产品上整体核对 Phase A 的谓词而不是只核对测试脚手架。把任何反复出现的纠正编码进结构门禁、lint 规则、检查或脚本依据 encode-lessons-in-structure 原则——结构性机制lint 规则、元数据标志、运行时检查、自动化脚本不依赖读者的自觉就能强制规则文本指令会被忽略。最后回复必须包含你设计的 playbook、严格级别及理由、决策轨迹路径、对照谓词已验证了什么、还有什么悬而未决。原则体系figure-it-out 的地基figure-it-out 不是孤立的技能它是一张原则调用网。下表汇总了它显式引用的原则技能及其在方法中的角色原则技能在 figure-it-out 中的角色prove-it-worksPhase A 可证伪完成定义Phase C 针对真实产物验证never-block-on-the-humanPhase A 可逆工作不阻塞数小时运行争取一个检查点foundational-thinkingPhase B 脚手架与验证先于功能laziness-protocolPhase B 对已定稿设计不做第二次 arena避免过度工程separate-before-serializing-shared-statePhase B 跨接缝并行每人一个 worktree/分支sequence-verifiable-unitsPhase C 逐单元验证不批量检查encode-lessons-in-structurePhase E 反复纠正编码为门禁/lint/脚本如何触发与落地figure-it-out 在 pstack/README.md 的技能表中被标注为没有捆绑 playbook 适用时为任务设计一份严格、可审计的 playbook。在 poteto-mode 主技能 的路由规则中大而跨切面的工作跨许多调用点的迁移、雄心勃勃的多部分改动、或用户离开后要回来信任的工作即使有 Feature 这类更窄的 playbook 可匹配也会路由到 figure-it-out。pstack/README.md 给出的一句话示例figure it out: /poteto-mode im stepping away. migrate every caller from the synchronous store to the new async one, keeping behavior identical. i want to trust it was done right when im back.在实践中落地 figure-it-out需要先通过/setup-pstack完成 pstack 安装与模型配置见 README然后以/poteto-mode进入粘性模式把上述这类任务交给它。figure-it-out 会自行完成先读原则、打开带阶段 todo 的清单、把 Phase A 的框架呈现出来争取检查点、写出阶段列表供人审查、逐单元执行假设循环、用 show-me-your-work 的 TSV 贯穿全程记录最后以轨迹 diff交还给人审查。整个过程的设计目标始终如一把相信我变成看着它从红变绿让人可以放心走开再带着完整证据回来。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考