show-me-your-work

展示你的工作过程

对于需要由人工事后审查的工作，决策记录可以让他们还原做了什么决定、为什么做，以及依据是什么，无需重新运行工作或通读整份记录。只保留一份权威日志，确保记录一致，方便未来的 Agent 查找。

格式

一个 TSV 文件，每个决定占一行。使用 TSV 是因为 GitHub 会将其渲染为可排序的表格，column -s$'\t' -t 和电子表格都能读取，而且可以用一条命令追加一行。单元格保持单行。证据只需提供指针，无需写成说明文字。

复制 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 追加一行，但如果单元格内容来自生成文本或用户提供的文本，要注意处理这些字符。

记录决策点和检查点，而不是每个操作：选择了一条分支、某个单元完成并验证、因触发条件而调整方向或回退、发现阻碍、修复关卡。对于循环运行，每次迭代记录一行。跳过琐碎且不言自明的内容。

存放位置

默认情况下，日志是工作产物，不提交。将其放在工作目录的 decisions.tsv，或在同时进行多项工作时放在 .audit/<task-slug>.tsv，并将其排除在 Git 之外。大多数工作无需提交决策记录；本地日志仍能让执行过程保持可信，之后可以丢弃。

只有当工作规模足够大、审查者需要查看记录才能信任结果时，才提交日志：例如大型跨语言移植、多周迁移，或任何必须展示而非默认假定可信度的工作。提交的日志会在 PR 中渲染为表格。

规则

• 一行对应一个决定或检查点。如果无法在一行内说清楚，说明决定还不够明确。
• 只追加，不修改。做错决定时，新增一行取代旧决定。绝不编辑或删除历史记录。
• 优先使用由已提交脚本生成的证据，而不是手工制作的一次性材料，以便审查者可以重新运行（encode-lessons-in-structure 原则技能）。

根据对话记录审计日志

运行结束后、交接之前，检查日志是否如实记录。读取当前工作区 agent-transcripts/ 目录下本次运行的对话记录（系统提示词中注明了路径）。不要跨 ~/.cursor/projects/*/ 使用 glob；那会读取无关的私人聊天记录。逐项对照日志与实际发生的事情：

• 每一行都必须对应一项真实操作。删掉虚构或仅计划执行的条目。
• 每一行的证据都必须可查证，并能证明该行所述内容。
• 如果某个分支、转向或放弃的方案影响了工作，却没有记录，就存在缺漏。请补上。
• 删除凑数内容。如果没有人会审查某一行，就不该保留。

修正日志，而不是改写经过。如果工作与某一行所述不符，那么这行就是错的。

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

交接之前，必须使用与执行工作时不同模型系列的模型启动一个子 Agent。自我审查不能替代这一步；目的是获得你无法自行提供的全新视角。子 Agent 阅读审计轨迹和本次运行的对话记录，然后指出用户应重点留意的内容。不是重做工作，而是检查有哪些地方不够理想或存在风险。

• 证据薄弱或缺失的已记录决策。
• 对话记录中缺少佐证的验证步骤，或声称已执行却没有证据的验证步骤。
• 事后看来有风险的选择（过早决策、扩大范围、掩盖症状）。
• 用户粗略浏览时可能忽略的缺漏。

凡是产生了记录轨迹的运行，每次回复都必须以「Attention」部分结尾。先单独一行写出审查者使用的模型（reviewed by <model>），再逐条列出需要标明具体行或环节的提醒。「No flags」是有效内容，但模型名称不可省略。自我审计检查日志是否如实记录；这一步则检查即使日志属实，用户仍应审视哪些内容。

审查记录轨迹

从头到尾阅读，跟进证据指针，并抽查。GitHub 会将已提交的 TSV 渲染为表格；在终端中，column -s$'\t' -t decisions.tsv 会将其排版为表格。如果某一行的证据无法查证，或结果未经验证，就说明审计发现了缺漏。

编写此技能

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