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 行要注明本次运行未写入的前序行的 ts 范围，其证据则注明本次运行的身份，例如其 Agent ID。除此之外，不要将 start 用作其他阶段。

存放位置

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

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

规则

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

根据对话记录审计日志

运行结束、交接工作之前，检查日志是否如实记录。读取当前工作区 agent-transcripts/ 目录下本次运行的对话记录（系统提示中注明了路径）。不要对 ~/.cursor/projects/*/ 使用通配符查找，以免读取无关的私人聊天记录。逐条核对本次运行记录的行与实际发生的事情。每一段记录从本次运行的某条 start 行开始；如果本次运行创建了日志，则从第一行开始；到另一运行的下一条 start 行结束：

• 检查每一行是否对应真实的决策或操作。
• 检查每行的证据是否有效，并且能证明该行所述内容。
• 影响工作过程但未记录的分支选择、转向或放弃的方法，都属于遗漏。补上记录。

更正日志，不要改写经过。审计绝不编辑或删除任何行，即使该行是凭空捏造的也不例外。如果某行既未记录真实的决策，也未记录真实的操作，或其内容或证据有误，就新增一行取代它，说明实际发生的事情并提供可解析的指针。本次审计不检查本次运行所负责的记录段之外的行。如果本次运行的工作表明其中某行有误，也要像纠正其他错误决策一样新增一行取代它。

跨模型审查轨迹

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

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

凡是生成了轨迹的运行，其每条回复末尾都以一个“Attention”部分结尾。先单独一行写出审查者使用的模型（reviewed by <model>），然后列出每项标记，并指向具体行或环节。“No flags”是有效内容，但不能用作模型名称。

审查轨迹

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

编写此技能

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