show-me-your-work

展示你的工作

在 GitHub Copilot 上，遵循此技能前，请阅读平台映射，包括其中针对各项技能的说明。

在 Muse 上，遵循此技能前，请阅读平台映射，包括其中针对各项技能的说明。

保留一份规范日志。

格式

一个 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 原则技能）。

根据对话记录审计日志

在运行结束、交接之前，检查日志是否如实记录。阅读本次运行在 Claude Code 项目级对话记录目录中的记录，路径为 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/<encoded-cwd>/，运行 node <plugin>/skills/reflect/scripts/claude-project-dir.mjs 即可打印该路径。不要对 ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/ 使用通配符搜索，以免读取无关的私人对话。逐条核对本次运行的记录与实际发生的情况。每段记录都从本次运行的一条 start 记录开始，或者在本次运行创建日志时从第一条记录开始；到另一次运行的下一条 start 记录为止：

• 检查每条记录是否对应真实的决策或操作。
• 检查每条记录的证据是否可访问，且能证明该记录中的说法。
• 如果影响了工作进程的分支、转向或放弃的方案未被记录，这就是遗漏。请补上。

修正日志，而非故事。审计绝不编辑或删除任何记录，即使该记录是捏造的也不例外。如果某条记录既未记录真实决策，也未记录真实操作，或者其说法或证据有误，请添加一条记录，说明实际发生的情况，并提供可访问的指针，以此取代原记录。本次审计不检查本次运行各段之外的记录。如果本次运行的工作表明其中某条记录有误，也应添加记录予以取代。

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

交接之前，启用一个与执行工作的模型家族不同的子 Agent。自我审查不能替代这一步。子 Agent 应阅读审计轨迹和本次运行的对话记录，然后标出用户应重点关注之处。这不是要重做工作，而是要检查其中不够完善或存在风险的地方。请根据任务，按照 poteto-mode 技能的 Subagents 部分，为子 Agent 选择推理级别。

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

凡是产生了记录轨迹的运行，回复末尾都必须包含一个“Attention”部分。先单独一行写审查者使用的模型（reviewed by <model>），然后列出各项标记，并指向具体记录或相关时刻。“No flags”是有效内容，模型名称则不能省略。

审阅记录轨迹

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

编写此技能

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