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 加上时间戳，在首次使用时写入表头，清除多余的制表符和换行符，并在任何以 =、+、- 或 @ 开头的单元格前加上单引号。每一行都要使用此辅助脚本，包括委派任务的记录。

对于必须在清理检出目录后仍可保留的证据，请使用证据捕获辅助工具。将生成的清单路径填入现有的 evidence 单元格。移除源检出目录前，先验证该工件。交接时保留所选的绝对存储路径。

记录每个判定，包括审查未通过的轮次、对完成定义的每项变更，以及每项约束。在 decision 单元格中将每项约束标记为 user-given、self-imposed 或 unknown，并提供支持性指针。补记的行使用实际追加时间；若已知较早事件的时间，也要注明。还要记录其他决策点和检查点，而不是每项操作：例如选择了哪条分支、完成了哪个单元及其验证结果、转向或回退及其触发原因、发现的阻塞问题、修复的门槛。对于循环运行，每次迭代记录一行。跳过琐碎且不言自明的事项。

一次运行指一次 Agent 对话，包括后续轮次及其摘要。接手任务、更换 Agent 或开启新聊天都会开始一次新运行。当某次运行向已有记录的日志追加内容时，其第一行的 phase 必须为 start；若它紧接着另一运行的 start 行，第一行也必须如此。因此，某次运行在后续轮次重新打开日志时，应先查看日志的末尾几行，确认是否有其他运行写入了新内容。start 行应注明该运行未写入的、位于它之前的行的 ts 时间范围，并在 evidence 中标明此次运行，例如写入其 Agent ID。除上述情况外，不得将 start 用作其他阶段。

存放位置

默认情况下，日志是工作文件，不提交。将其保存在工作目录中的 decisions.tsv，或在多个任务同时进行时保存在 .audit/<task-slug>.tsv，并确保不将其纳入 git。

只有当工作规模足够大、审阅者需要查看过程记录才能信任结果时，才提交日志。准备提交的过程记录从第一行起就必须使用目标读者在合并后可访问的持久证据。已提交记录中的每个证据指针都必须在合并并清理检出目录后仍然有效。使用提交、PR、已检入的文件，或目标读者可以访问且保留期限符合要求的工件。仅有私有绝对路径并不符合要求。若记录中包含仅供临时使用的历史内容，则将其保留在本地，并保持只追加。读者需要查看持久审查记录时，应另行发布一份包含持久证据的摘要。本地日志可以引用本地工件，但应使用捕获辅助工具保留后续审查所需的证据。

规则

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

根据对话记录审计日志

运行结束、交接之前，检查日志是否如实记录。使用 pstack-harness 技能，从此工作区的会话存储中读取本次运行的对话记录。不要读取其他工作区的存储，其中包含无关的私人聊天。如果找不到或无法读取本次运行的对话记录，不要逐行检查。在 Attention 部分说明审计未运行，因此尚未根据对话记录核查日志。否则，逐行对照本次运行的实际情况进行检查。本次运行的每段记录都从本次运行的一条 start 记录开始；如果本次运行创建了日志，则从第一条记录开始；并在另一运行的下一条 start 记录处结束：

• 检查每条记录是否对应真实的决策或操作。
• 检查每条记录的证据是否可解析，且能证明该记录中的说法。
• 如果某个影响了工作进展的分支、转向或放弃的方案未记录下来，就是缺漏。请补上。

修正日志，而不是改写经过。审计绝不编辑或删除记录，即使记录是捏造的也不例外。如果某条记录既未记录真实的决策，也未记录真实的操作，或者其说法或证据有误，则新增一条记录予以取代，写明实际发生的情况，并附上可解析的指针。本次审计不检查本次运行所涉片段之外的记录。如果本次运行的工作表明其中某条记录有误，也应新增记录予以取代。

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

交接之前，使用 trail reviewer 角色启动审查子 Agent。使用 pstack-harness 技能中的 Spawn a role 部分解析该角色。启动调用和判定及回复中的执行身份披露都必须遵循该部分的要求。绝不要选择解析器输出中未列出的模型。自我审查不能代替这一步。子 Agent 会读取审计轨迹和本次运行的对话记录，然后标出用户应注意的事项。这不是要重做工作，而是检查是否有不够理想或存在风险的地方。

• 证据薄弱或缺失的已记录决策。
• 对话记录中没有证明、却被跳过或声称已完成的验证步骤。
• 事后看来有风险的选择（过早采取行动、范围蔓延、掩盖症状）。
• 用户快速浏览时可能会忽略的缺漏。

每次产生了记录轨迹的运行，回复末尾都必须包含一个 “Attention” 部分。先单独一行写出审查者的模型和工作量（reviewed by <model>@<effort>；如果角色不是 trail reviewer，还要注明角色来源），然后列出尚未解决的重要问题，并附上指向具体记录或时刻的指针。只要问题仍然存在，就应简洁保留此前报告的问题，并说明其身份、当前影响和证据。仅仅表示知悉并不能解决问题。省略已解决的问题，以及不会带来当前风险或行动的重复历史。“No flags”是有效内容，但不能省略模型名称。

审查记录轨迹

从上到下阅读，追踪证据指针，并抽样核查。GitHub 会将已提交的 TSV 渲染为表格。在终端中，column -s$'\t' -t decisions.tsv 可以将其排成表格。

编写此技能

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