show-me-your-work

展示你的工作过程

维护一份权威日志。

格式

使用单个 TSV 文件，每项决策占一行。每个单元格保持单行。证据只需提供指向相关内容的路径，不要写说明文字。表头如下：

ts	phase	decision	why	evidence	result

• ts. ISO8601 时间戳。
• phase. 阶段或工作流。
• decision. 选择或执行的操作，用一行写清。
• why. 用平实的语言说明原因。如果是原则驱动的，就直白地说出来，不要用术语标签。
• evidence. 能证明这一点的链接或路径：提交 SHA、PR 编号、file:line，或产物或截图路径。不要写段落。
• result. 结果或谓词状态：tests green、reverted、INCONCLUSIVE、open。

以下是一个示例，措辞直白，方便审阅者一眼看明白。

ts	phase	decision	why	evidence	result
2026-05-24T09:02:00Z	frame	counted the work first, 40 resources still on the old inventory exports	wanted to know the size before starting a long run	commit 3a9f1c2	found 3 resources that wrap the exports in their own bridge
2026-05-24T09:40:00Z	harness	wrote a script listing every call to the old exports before changing anything	so we can compare old against new and catch a missed call	scripts/find-old-exports.sh	baseline of 212 calls saved
2026-05-24T11:15:00Z	shops	moved the shop resource to the new exports	keep each resource's change small and checkable on its own	commit 7c21e0a	0 old calls left in shops, lua-language-server --check clean
2026-05-24T12:30:00Z	garages	threw out a helper's work because it skipped two files	checked the real diff instead of trusting its summary	worktree reset	reverted, tightened the instructions for next time

记录一行

每条记录都要像是在告诉队友你做了什么：用词直白，具体说明操作，不要用术语。

使用此技能目录中的辅助脚本 scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>。它会生成 ts、首次使用时写入表头、清除多余的制表符和换行符，并在任何以 =、+、- 或 @ 开头的单元格前添加一个单引号，防止电子表格将其作为公式执行。也可以直接用 printf 追加一行，但如果单元格内容来自自动生成的文本或用户提供的文本，请注意同样的字符。

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

一次运行指一段 Agent 对话，包括后续轮次及其摘要。接手任务、更换 Agent 或开始新聊天，都算一次新运行。如果某次运行向已有记录的日志追加内容，它的第一行应使用阶段 start；在另一运行的 start 行之后，该运行写下的第一行也应如此。因此，如果某次运行在后续轮次中再次写入日志，必须先查看日志末尾几行，确认另一运行是否在此期间写入。start 行应注明该运行未写入的前序日志行的 ts 范围，并在证据中标明本次运行，例如写入其会话 ID。除上述情况外，不要将阶段 start 用于其他用途。

存放位置

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

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

规则

• 只追加，不修改。判断有误时，新增一行说明哪项判断已被取代。绝不编辑或删除历史记录。
• 优先使用由已提交脚本生成的证据，而不是手动制作的一次性证据；详见 principles 技能中的「将经验编码进结构」（Encode Lessons in Structure）。

根据对话记录审计日志

运行结束后、交还结果之前，检查日志是否如实记录。阅读本次运行的对话记录：在 Claude Code 中，读取 ~/.claude/projects/ 下本次会话的 .jsonl 文件；在 Codex 中，读取 ~/.codex/sessions/ 下的文件；在 T3 Code 中，使用 t3_thread_read 并设置 view: "activity"，根据 nextPosition 继续读取，直到 hasMore 为 false。搜索本次运行的开场提示词，找到对应会话。只阅读本次运行的会话：其他会话包含无关的私人聊天。逐行核对本次运行的记录，确认与实际发生的情况一致。每段记录都从本次运行的一条 start 行开始；如果本次运行创建了日志，则从第一行开始；并在下一次其他运行的 start 行处结束：

• 检查每一行是否对应真实的决策或操作。
• 检查每一行的证据是否可解析，并能证明该行的说法。
• 如果某个影响了工作过程的分支、转向或放弃的方法未被记录，就存在缺漏。补上。

修正日志，而不是改写过程。审计绝不编辑或删除任何行，即使某行是虚构的也不例外。如果某行既未记录真实的决策，也未记录真实的操作，或者其说法或证据有误，就添加一行，用实际发生的情况取代该行，并附上可解析的指针。本次审计不会检查本次运行各段之外的行。如果本次运行的工作表明其中某行有误，也应像处理其他错误记录一样，用新行取代它。

对记录进行跨模型审查

交还结果之前，在 ~/.config/ox/models.md 的 review 行指定的模型上启动一个名为 Trail reviewer 的子 Agent。如果该行指定的模型与完成工作的模型相同，则改用不同模型系列的 panel 条目：自我审查不能替代跨模型审查。如果两者都未指定不同模型，就使用你自己的模型审查，并在 Attention 部分说明。给审查 Agent 的任务说明应提供日志的绝对路径和对话记录的位置，并写明“只读：仅检查，不得写入，不得使用 git 命令”和“不要委派”。它会阅读记录和对话记录，然后指出用户应留意的问题。不是重做工作，而是检查不够妥当或有风险之处：

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

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

审阅记录

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

编写此技能

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