show-me-your-work

展示你的工作

以粗体或反引号标出的技能名称，或以 /<name> 形式运行的技能，指的是此技能目录旁边的 ../<name>/SKILL.md 文件；未带前缀的原则名称指的是 ../principle-<name>/SKILL.md。读取该文件并遵循其中的要求。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次调用 delegate_task 都遵循 ../poteto-mode/SKILL.md 中 Subagents 部分的默认设置。

保留一份规范日志。

格式

使用一个 TSV 文件，每个决策占一行。单元格内容必须为单行。证据应是指向证据的路径，而不是说明文字。

复制 references/decision-log-template.tsv（标题行），以此创建空白日志。列如下：

• ts. ISO8601 时间戳。
• phase. 阶段或工作流。
• decision. 选择或执行的事项，写成一行。
• why. 用通俗语言说明原因。如果是原则促成了这个决定，请直接说明，而不要使用术语标签。
• evidence. 能证明该事项的链接或路径：提交 SHA、PR 编号、file:line，或制品、追踪记录或截图的路径。不要写一段说明。
• result. 结果或谓词状态：tests green、reverted、pixel-diff 0、INCONCLUSIVE、open。

以下示例写得直白易懂，方便审阅者一目了然。

ts	phase	decision	why	evidence	result
2026-05-24T09:02:00Z	frame	counted the work first, about 100 components and roughly 75 hours	wanted to know the size before starting a long run	commit 3a9f1c2	found 5 things to sort out before starting
2026-05-24T09:40:00Z	harness	took screenshots of the old version before changing anything	so we can compare old against new and catch any visual change	scripts/snapshot.sh, baseline/	saved 120 reference screenshots
2026-05-24T11:15:00Z	widget	moved the widget styles over without changing how it looks	keep the change small and the result identical	commit 7c21e0a, pixel-diff 0	looks identical, tests pass
2026-05-24T12:30:00Z	widget	threw out a helper's work because its screenshots were blank	checked the real files instead of trusting its summary	worktree reset	reverted, tightened the instructions for next time

记录一行

每条记录都要像是在向队友说明自己做了什么。使用平实的语言，描述具体行动，不要使用 AI 腔或抽象术语（日志文本也适用 unslop 技能）。

使用辅助脚本 scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>。它会添加 ts，首次使用时写入标题行，去除多余的制表符和换行符，并在任何以 =、+、- 或 @ 开头的单元格前加上单引号。也可以直接用 printf 追加一行，但如果单元格内容来自生成文本或用户提供的文本，请注意这些相同的字节。

记录决策点和检查点，而不是每个操作：选择了某个分支、某项工作及其验证结果、因触发条件而转向或回退、发现阻碍、修复门槛。对于循环运行，每次迭代记录一行。跳过琐碎和不言自明的事项。

一次运行指一次 Agent 对话，包括后续轮次及其摘要。接手任务、更换 Agent 或开启新聊天，都算一次新运行。如果一次运行向已有行的日志追加内容，那么它的第一行必须将 phase 设为 start；另一运行的 start 行之后，该运行的第一行也必须如此。因此，某次运行在后续轮次重新使用日志时，应先读取日志的末尾几行，查看期间是否有其他运行写入内容。start 行要注明本次运行未写入的先前行所涵盖的 ts 范围，并在 evidence 中注明本次运行的标识，例如其线程 ID。除上述情况外，不得将 phase 设为 start。

存放位置

默认情况下，日志是工作产物，不提交到版本库。将其保存在工作目录的 decisions.tsv 中；如果同时进行多个工作，则保存在 .audit/<task-slug>.tsv 中，并确保不将其纳入 git。

只有当工作规模大到需要审阅者查看过程记录才能信任结果时，才提交日志。

规则

• 只追加。错误的决定应以新行取代旧决定。绝不编辑或删除历史记录。
• 优先使用由已提交脚本生成的证据，而不是手工制作的一次性证据（encode-lessons-in-structure 原则技能）。

根据对话记录审计日志

运行结束后、交还结果前，检查日志是否如实记录。使用 t3_thread_read 阅读本次运行的对话线程（view: "activity"，持续跟进 nextPosition，直到 hasMore 为 false；并使用 itemId 和 textOffset 补全被截断的条目）。使用本次运行开头的用户提示词，通过 t3_thread_search 查找其 ID。不要传入其他项目的 projectId，那会读取无关的私人聊天记录。逐行核对本次运行的记录与实际发生的情况。每段记录都从本次运行的一条 start 行开始，或者在本次运行创建了日志时从第一行开始，并在下一条属于其他运行的 start 行之前结束：

• 检查每一行是否对应真实的决定或操作。
• 检查每一行的证据是否可访问，且能证明该行所述内容。
• 如果影响了工作走向的分支、转向或放弃的方案没有记录，就是遗漏。请补上。

更正日志，而不是改写经过。审计绝不编辑或删除任何行，即使某行是杜撰的。如果某行既没有记录真实决定，也没有记录真实操作，或者其说法或证据有误，就添加一行，说明实际发生的情况，并提供可访问的指针以取代该行。本次审计不检查本次运行记录区段之外的行。如果本次运行的工作表明其中某行有误，也要像处理其他错误记录一样添加替代行。

对记录轨迹进行跨模型审查

交还结果前，使用与完成工作所用模型系列不同的模型，挑选自 orchestrator_capabilities，启动一个名为 Trail reviewer 的 delegate_task 子任务。不要用自我审查代替。任务说明中应包含日志的绝对路径和本次运行的线程 ID，并注明“只读：仅检查，不写入，不运行 git 命令”和“不要再委派任务”。子 Agent 应阅读审计轨迹和本次运行的对话记录（使用 t3_thread_read，view: "activity"，持续跟进 nextPosition，直到 hasMore 为 false；并使用 itemId 和 textOffset 补全被截断的条目），然后标出用户需要注意的问题。这不是让其重做工作，而是检查不够妥当或存在风险的地方。根据 Subagents 部分的 poteto-mode 技能，为每个子 Agent 选择合适的推理级别以及快速或标准速度。

• 记录中证据薄弱或缺失的决定。
• 未执行验证步骤，或声称执行了验证但对话记录中没有证明的情况。
• 事后看来有风险的选择（过早行动、扩大范围、掩盖症状）。
• 用户快速浏览时可能忽略的遗漏。

凡是本次运行产生了轨迹的回复，都必须以“Attention”部分结尾。先单独一行写上审查模型（reviewed by <model>），然后列出每条标记，并指出具体行或时间点。“No flags”是有效内容。模型名称则不行。

审阅记录轨迹

从头到尾阅读，沿证据指针核查，并抽查。GitHub 会将已提交的 TSV 渲染为表格。在终端中，column -s$'\t' -t decisions.tsv 可将其格式化显示。

编写此技能

其他技能应将其审计轨迹交由此处处理，而不是另行设计格式。按名称引用此技能，并让它负责格式。不要重复说明列的内容。