show-me-your-work

展示你的工作

保留一份规范日志。

格式

使用单个 TSV 文件，每项决策占一行。单元格保持单行。证据是指针，而非描述文字。

复制 references/decision-log-template.tsv（表头行），开始一份空白日志。列如下：

• ts. ISO8601 时间戳。
• phase. 阶段或工作流。
• decision. 选择或完成的事项，写成一行。
• why. 用直白的话说明原因。如果是某项原则驱动了决定，请直接说明，不要把它写成行话标签。
• evidence. 能证明该事项的链接或路径：commit 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。因此，某次运行在后续轮次中再次打开日志时，应先读取日志最后几行，确认自上次以来是否有其他运行写入内容。start 行要注明本次运行未写入的前序行的 ts 范围，并在证据中注明本次运行的标识，例如会话 ID。除此之外，不得将阶段 start 用于其他用途。

日志存放位置

默认情况下，日志是工作产物，不提交。将其保存在工作目录下的 decisions.tsv，或者在多个工作同时进行时保存在 .audit/<task-slug>.tsv，并将其排除在 git 之外。

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

规则

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

对照对话记录审计日志

本次运行结束、交接之前，检查日志是否如实记录了情况。读取本次运行在 Claude Code 项目专属对话记录目录中的记录：~/.claude/projects/<encoded-cwd>/。不要对 ~/.claude/projects/ 使用 glob，以免读取无关的私人聊天记录。逐一核对本次运行的各行与实际发生的情况。每段记录从本次运行的某个 start 行开始；如果日志由本次运行创建，则从第一行开始；到另一次运行的下一个 start 行结束：

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

修正日志，而不是改写经过。审计绝不编辑或删除任何一行，即使该行是捏造的也不例外。如果某行既未记录真实决策，也未记录真实操作，或者其陈述或证据有误，就新增一行取代它，写明实际发生的情况，并附上可访问的指针。本次审计不检查本次运行所负责记录范围之外的行。如果本次运行的工作表明其他行有误，也应像处理任何错误记录一样，用新行取代。

跨模型审查记录

交付前，启动一个与执行任务所用模型系列不同的子 Agent。自我审查不能替代这一步。子 Agent 会阅读审计记录和本次运行的对话记录，然后指出用户应该留意的事项。这不是重做任务，而是检查有哪些地方不够理想或存在风险。根据 Subagents 部分的 poteto-mode 技能，为每个子 Agent 选择合适的投入程度。

• 证据薄弱或缺失的决策。
• 在对话记录中跳过或声称已完成、但没有证据的验证步骤。
• 事后看来似乎有风险的选择（过早行动、扩大范围、掩盖症状）。
• 用户随意浏览时可能会忽略的疏漏。

凡是生成了审计记录的运行，其每条回复都必须以“Attention”部分结尾。先单独一行写出审查者的模型（reviewed by <model>），然后逐项列出标记，并指出具体行或时刻。“No flags”是有效内容，但模型名称不能省略。

审查记录

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

编写此技能

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