show-me-your-work

展示你的工作记录

保留一份规范日志。

格式

一个 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 或开启新聊天都算作新运行。当一次运行向已有记录的日志追加内容时，该运行的第一行应使用 start 阶段；如果前面另一运行的第一行也是 start，则本次运行的第一行也应如此。因此，某次运行稍后再次写入日志时，应先读取日志末尾几行，确认自上次以来是否有其他运行写入。start 行应注明本次运行未写入的前序行的 ts 时间范围，证据栏则应注明本次运行，例如其 Agent ID。除此之外，不要将阶段 start 用于其他情况。

存放位置

默认情况下，日志是工作过程中的构件，不提交。将其保存在工作目录中的 decisions.tsv；若同时进行多个工作，则保存在 .audit/<task-slug>.tsv，并将其排除在 Git 之外。

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

规则

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

根据转录记录审计日志

运行结束后，在交还之前，检查日志是否如实记录。读取本次运行在当前工作区会话目录中的转录记录：在 Cursor 中，读取系统提示词所指的 agent-transcripts/ 目录。在 Claude Code 中，读取 ~/.claude/projects/<slug>/（将工作区路径中所有非字母或数字字符替换为 "-"）。在 Pi 中，读取 ~/.pi/agent/sessions/--<slug>--/。在 Codex 中，读取 ~/.codex/sessions/ 下首行的 payload.cwd 等于工作区路径的文件。不要对所有项目的目录使用 glob。这会读取无关的私人聊天记录。逐条核对本次运行的日志行与实际发生的事情。每一段日志行都从本次运行的一条 start 行开始，或者在本次运行创建了日志时从第一行开始，并在另一运行的下一条 start 行处结束：

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

修正日志，不要篡改事实。审计绝不编辑或删除任何日志行，包括虚构的行。当某一行既未记录真实决策，也未记录真实操作，或者其主张或证据有误时，添加一行，用实际发生的情况及可解析的指针来取代它。本次审计不会检查本次运行日志段落之外的行。如果本次运行的工作表明其中某行有误，也要用新行取代该错误记录。

对日志轨迹进行跨模型评审

交还之前，启用一个与执行本次工作的模型系列不同的子 Agent。自我评审不能替代此步骤。子 Agent 应阅读审计轨迹和本次运行的转录记录，然后指出用户需要留意的事项。这不是重做工作，而是检查哪些方面不够理想或存在风险。根据 poteto-mode 技能的 Subagents 部分，为这项工作选择子 Agent 的推理级别和快速或标准速度。

• 证据薄弱或缺失的决策记录。
• 转录记录未证明却被声称已执行或跳过的验证步骤。
• 回看时显得有风险的选择（过早、超出范围、掩盖症状）。
• 用户随手浏览时可能忽略的遗漏。

每次产生了日志轨迹的运行，其回复都必须以一个“Attention”部分结尾。第一行单独写评审者使用的模型（reviewed by <model>），然后逐项列出各项提示，并指向具体行或时间点。“No flags”是有效内容。模型名称不能省略。

审阅日志轨迹

从头到尾阅读，跟随证据指针，并抽查内容。GitHub 会将已提交的 TSV 渲染为表格。column -s$'\t' -t decisions.tsv 可在终端中渲染表格。

编写此技能

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