tldr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

A task just finished, or the user asks what happened. Give the result, not the transcript.

Rules:

When the user asks what happened since their last message, report as catch-up.md says. Its reply order and its picture rules replace the rules below on the first line, the last line, and visuals. The other rules still apply. The
```
recall
```
skill rebuilds the work of earlier sessions, not this skill.
Write in ASD-STE100 Simplified Technical English: one meaning per word, active voice, short sentences, no idioms.
Fit the length to the task. A small task gets two or three lines. A large task, or one with much output, gets more. The reply is never longer than the result needs.
Choose the form that the user reads fastest for this result. Use prose for a few outcomes. Use bullets or a table when the user must scan several separate items.
Start with the result: what the task made or decided.
Give the outcomes that matter. Keep exact paths, commands, names, and error strings. Link commits, PRs, and files.
Redact secrets. Replace a token, key, password, or connection string in a command or an error with a placeholder. Never copy it.
End with what needs the user now, or "nothing" when the task is done.
Add one small visual when the result is a new structure that prose would only list. Examples are a tree of files or calls, a flow between parts, or a layout. One new or moved file is a path in prose, not a tree. Build the visual as visual.md says. Add one visual at most. A second visual is transcript again.
Leave out the story of the tool calls. Keep the outcomes. If the task made nothing, say so. Never invent progress.
Unless asked, never explain what you were about to do, how you reasoned, or why the approach is sound.
The user sees the diff and the output. Do not repeat them, except the evidence that
```
verify
```
requires: what ran, and what it showed.
This register applies to this reply only. It never becomes the standard register of the session. The reasoning that it leaves out still goes into ADRs and specs on the land path.
Write no introduction and no closing words. The summary is the whole reply. Stop.

任务刚刚完成，或者用户询问发生了什么。给出结果，而不是执行记录。

规则：

当用户询问自上一条消息以来发生了什么时，按照 catch-up.md 报告。其回复顺序和图片规则取代下文关于首行、末行和可视化的规则。其他规则仍然适用。
```
recall
```
skill 用于重建更早会话的工作，而不是替代此 skill。
使用 ASD-STE100 Simplified Technical English 写作：一个词只表达一个含义，使用主动语态，句子简短，不使用习语。
根据任务调整回复长度。小任务使用两到三行。大任务或输出较多的任务可以更长。回复长度不得超过结果所需的程度。
选择用户能最快阅读这种结果的形式。少量结果使用连续文字。当用户需要快速浏览多个独立项目时，使用项目符号或表格。
先写结果：任务创建了什么或决定了什么。
给出重要结果。保留准确的路径、命令、名称和错误字符串。为 commits、PRs 和文件提供链接。
隐藏敏感信息。将命令或错误中的 token、key、password 或 connection string 替换为占位符。绝不复制这些内容。
最后说明用户现在需要做什么；任务完成时写“无”。
如果结果包含一种新结构，而文字只会将其列成清单，则添加一个小型可视化。例如文件或调用的树状图、部件之间的流程图或布局图。如果只有一个新文件或移动后的文件，在文字中给出路径，不要使用树状图。按照 visual.md 构建可视化。最多添加一个可视化。第二个可视化又会变成执行记录。
省略工具调用的过程。保留结果。如果任务没有产生任何内容，就直接说明。绝不虚构进展。
除非用户要求，否则绝不解释你准备做什么、如何推理，或者为什么该方法合理。
用户可以看到 diff 和输出。不要重复这些内容，但
```
verify
```
要求的证据除外：运行了什么，以及它显示了什么。
这种表达方式仅适用于本次回复，不能成为整个会话的标准表达方式。被省略的推理过程仍应写入 land path 的 ADRs 和 specs 中。
不要写引言和结束语。摘要就是全部回复。然后停止。