antithesis-workload

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Antithesis Workload

Purpose and Goal

目的与目标

Implement or improve the Antithesis workload. Success means:

Properties from the
```
antithesis-research
```
skill are mapped to concrete assertions, using both the property catalog and per-property evidence files
Test commands exist under
```
antithesis/test/
```
and exercise the right behaviors
The first real test templates are created after setup, or existing ones are expanded
Triage findings turn into workload or property updates instead of staying implicit

Use the

antithesis-research

skill first to build the property catalog. Use the

antithesis-setup

skill to scaffold the infrastructure. Use the

antithesis-triage

skill to review runs, then return here to improve the workload.

实现或改进Antithesis工作负载。成功的标准包括：

将
```
antithesis-research
```
技能中的属性映射为具体的断言，同时使用属性目录和每个属性的证据文件
在
```
antithesis/test/
```
目录下存在测试命令，且能验证正确的行为
完成设置后创建首个真实测试模板，或扩展现有模板
分类审查的结果转化为工作负载或属性更新，而非仅停留在隐含状态

首先使用

antithesis-research

技能构建属性目录。使用

antithesis-setup

技能搭建基础设施。使用

antithesis-triage

技能审查运行结果，然后回到此处改进工作负载。

Prerequisites

前提条件

DO NOT PROCEED if the Antithesis scratchbook (usually at
```
antithesis/scratchbook/
```
) doesn't exist. Use the
```
antithesis-research
```
skill to create it.
DO NOT PROCEED if there is no
```
docker-compose.yaml
```
for Antithesis present. Use the
```
antithesis-setup
```
skill to create it.

DO NOT PROCEED if

snouty

is not installed. See

https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md

for installation options.

如果Antithesis临时手册（通常位于
```
antithesis/scratchbook/
```
）不存在，请不要继续。使用
```
antithesis-research
```
技能创建它。
如果没有用于Antithesis的
```
docker-compose.yaml
```
文件，请不要继续。使用
```
antithesis-setup
```
技能创建它。

如果未安装

snouty

，请不要继续。查看

https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md

获取安装选项。

Scoping

范围界定

Each invocation of the "Implement next property" workflow below focuses on one property to keep context manageable and quality high. (Post-triage iteration follows its own scoping based on triage findings.)

If the user asks for multiple properties, recommend doing one at a time — explain that implementation quality degrades as context accumulates, and each property's effort is unpredictable. Ask which one they'd like to start with. If they insist on multiple, proceed — but warn them first.

If the user specifies which property to work on, skip the full catalog scan — but still assess that property's status against its evidence file before proceeding. If it's already fully implemented, tell the user rather than redoing work.

If the user does not specify a property, run the full detection and recommendation flow below.

每次调用下面的“实现下一个属性”工作流时，仅聚焦一个属性，以保持上下文可控并确保高质量。（分类审查后的迭代将根据审查结果采用自身的范围界定方式。）

如果用户要求处理多个属性，建议逐个进行——解释随着上下文累积，实现质量会下降，且每个属性的工作量不可预测。询问用户想先从哪个开始。如果用户坚持要处理多个，可继续操作，但需先发出警告。

如果用户指定了要处理的属性，跳过完整的目录扫描——但仍需根据其证据文件评估该属性的状态。如果该属性已完全实现，告知用户而非重复工作。

如果用户未指定属性，运行以下完整的检测与推荐流程。

Detect implementation status

检测实现状态

The detection work below is context-heavy (reading every evidence file, scanning the codebase for assertions). If your agent supports sub-agents, delegate it to a sub-agent that returns a per-property summary (status + brief rationale). This keeps the main implementation agent's context clean.

The detection task: for each property in the catalog, search the existing test and SUT code for Antithesis SDK assertion calls and cross-reference them with the property's evidence file at

antithesis/scratchbook/properties/{slug}.md

. Assess whether the existing assertions cover the code paths, failure scenarios, and instrumentation points the evidence file describes. Classify each property as:

Implemented — assertions cover what the evidence file describes
Partially implemented — some assertions exist but coverage is incomplete
Not implemented — no related assertions found

以下检测工作涉及大量上下文（读取所有证据文件、扫描代码库查找断言）。如果你的Agent支持子Agent，可将此任务委托给子Agent，由其返回每个属性的摘要（状态+简要理由）。这样可保持主实现Agent的上下文简洁。

检测任务：针对目录中的每个属性，在现有测试和SUT代码中搜索Antithesis SDK断言调用，并与

antithesis/scratchbook/properties/{slug}.md

中的属性证据文件进行交叉引用。评估现有断言是否覆盖了证据文件中描述的代码路径、故障场景和插装点。将每个属性分类为：

已实现——断言覆盖了证据文件描述的内容
部分实现——存在一些断言但覆盖不完整
未实现——未找到相关断言

Present and recommend

展示与推荐

Note the catalog's provenance frontmatter (

commit

and

updated

fields) and include it when presenting status — e.g., "The property catalog is up-to-date as of

<commit short hash>

(

<date>

)." This lets the user judge whether the catalog reflects the current codebase or needs re-research.

Show the user the status of each property, then recommend one to implement next. Prefer partially-implemented properties that need completion, then unimplemented properties that cluster with recently implemented ones (see

antithesis/scratchbook/property-relationships.md

), then other high-priority unimplemented properties. Wait for the user to confirm or choose differently before proceeding.

For the chosen property, read both the catalog entry and its evidence file.

注意目录的来源前置信息（

commit

和

updated

字段），展示状态时需包含这些信息——例如：“属性目录截至

<commit短哈希>

（

<日期>

）是最新的。”这样用户可以判断目录是否反映了当前代码库状态，或是需要重新研究。

向用户展示每个属性的状态，然后推荐下一个要实现的属性。优先选择需要完成的部分实现属性，其次是与最近实现的属性相关联的未实现属性（查看

antithesis/scratchbook/property-relationships.md

），最后是其他高优先级未实现属性。等待用户确认或选择其他属性后再继续。

对于选定的属性，阅读其目录条目和证据文件。

其他范围界定问题

Ask the user only for blockers or scoping decisions you cannot infer safely, such as:

The property catalog location, if it is not the standard
```
antithesis/scratchbook/property-catalog.md
```
The project language or SDK choice, if the repo does not make it obvious
Triage findings or known gaps, if iterating on an existing workload

仅向用户询问你无法安全推断的障碍或范围界定决策，例如：

如果属性目录不在标准路径
```
antithesis/scratchbook/property-catalog.md
```
，询问其位置
如果代码库未明确显示，询问项目语言或SDK选择
如果是迭代现有工作负载，询问分类审查结果或已知的缺口

Definitions and Concepts

定义与概念

SUT: System under test.
Test template: A directory of test commands at
```
/opt/antithesis/test/v1/{name}/
```
. Each timeline runs commands from one test template. Files or subdirectories prefixed with
```
helper_
```
are ignored by Test Composer, so use that prefix for helper scripts kept alongside commands.

Test command: An executable in a test template with a valid prefix:

parallel_driver_

singleton_driver_

serial_driver_

first_

eventually_

finally_

anytime_

Timeline: One linear execution of the SUT and workload. Antithesis runs many timelines in parallel and branches them to search for interesting behaviors.
Always
/
AlwaysOrUnreachable
: Assertions for safety and correctness properties.
Sometimes(cond)
: Assertions for liveness or non-trivial semantic states that should occur at least once.
Reachable
/
Unreachable
: Assertions about whether meaningful outcomes or forbidden paths are exercised.

SUT： 被测系统（System under test）。
测试模板： 位于
```
/opt/antithesis/test/v1/{name}/
```
的测试命令目录。每个时间线都会运行一个测试模板中的命令。以
```
helper_
```
为前缀的文件或子目录会被Test Composer忽略，因此可将辅助脚本以此前缀命名并与命令放在一起。
测试命令： 测试模板中的可执行文件，需带有有效前缀：
```
parallel_driver_
```
、
```
singleton_driver_
```
、
```
serial_driver_
```
、
```
first_
```
、
```
eventually_
```
、
```
finally_
```
、
```
anytime_
```
。
时间线： SUT和工作负载的一次线性执行。Antithesis会并行运行多条时间线，并对其进行分支以查找有价值的行为。
Always
/
AlwaysOrUnreachable
：用于安全和正确性属性的断言。
Sometimes(cond)
：用于活性或非平凡语义状态的断言，这类状态至少应出现一次。
Reachable
/
Unreachable
：关于有意义的结果或被禁止的路径是否被执行的断言。

Documentation Grounding

文档依据

Use the

antithesis-documentation

skill to access these pages. Prefer

snouty docs

Test templates reference:

https://antithesis.com/docs/test_templates/test_composer_reference.md

SDK reference:

https://antithesis.com/docs/using_antithesis/sdk.md

Properties and assertions:

https://antithesis.com/docs/properties_assertions/assertions.md

Fault injection:

https://antithesis.com/docs/environment/fault_injection.md

使用

antithesis-documentation

技能访问以下页面。优先使用

snouty docs

。

测试模板参考：

https://antithesis.com/docs/test_templates/test_composer_reference.md

SDK参考：

https://antithesis.com/docs/using_antithesis/sdk.md

属性与断言：

https://antithesis.com/docs/properties_assertions/assertions.md

故障注入：

https://antithesis.com/docs/environment/fault_injection.md

Reference Files

参考文件

Reference	When to read
`references/component-implementation.md`	Implementing workload-side components or wrappers
`references/assertions.md`	Turning properties into SDK assertions
`references/test-commands.md`	Writing commands and organizing test templates
`references/iteration.md`	Improving coverage and assertions after triage

参考文件	阅读时机
`references/component-implementation.md`	实现工作负载端组件或包装器时
`references/assertions.md`	将属性转换为SDK断言时
`references/test-commands.md`	编写命令和组织测试模板时
`references/iteration.md`	分类审查后优化覆盖范围和断言时

Recommended Workflows

General Guidance

通用指导

Keep Antithesis-only code out of production paths. If you must touch shared code, make the change surgical and easy to wall off.
Prefer simple workload code over highly configurable abstractions.
Assume
```
antithesis-setup
```
has already made the system runnable in a mostly idle state; this skill owns what the workload does once the system is up.
Assume
```
antithesis-setup
```
has already installed the relevant SDK and added one minimal bootstrap assertion in the SUT. This skill owns the broader property catalog beyond that initial integration check.
Write test commands in the project's language, not Bash, so they can reuse the project's clients, helpers, and libraries.

将仅用于Antithesis的代码排除在生产路径之外。如果必须修改共享代码，需确保修改精准且易于隔离。
优先选择简单的工作负载代码，而非高度可配置的抽象。
假设
```
antithesis-setup
```
已使系统能在基本空闲状态下运行；本技能负责系统启动后工作负载的行为。
假设
```
antithesis-setup
```
已安装相关SDK，并在SUT中添加了一个最小的引导断言。本技能负责初始集成检查之外的更广泛属性目录。
使用项目的语言编写测试命令，而非Bash，以便复用项目的客户端、辅助工具和库。

Output

输出

Assertions for every property in scope, in workload code or carefully chosen SUT locations
Test commands and supporting workload code under
```
antithesis/test/
```
Updates to
```
antithesis/scratchbook/property-catalog.md
```
when the implemented properties change

针对所有范围内属性的断言，位于工作负载代码或精心选择的SUT位置
位于
```
antithesis/test/
```
下的测试命令和支持工作负载代码
当已实现的属性发生变化时，更新
```
antithesis/scratchbook/property-catalog.md
```

Self-Review

自我审查

Before declaring this skill complete, review your work against the criteria below. If your agent supports spawning sub-agents, create a new agent with fresh context to perform this review — give it the path to this skill file and have it read all output artifacts. A fresh-context reviewer catches blind spots that in-context review misses. If your agent does not support sub-agents, perform the review yourself: re-read the success criteria at the top of this file, then systematically check each item below against your actual output.

Review criteria:

For every property in scope, the implementation covers the code paths, failure scenarios, and instrumentation points described in its evidence file — not just "an assertion exists" but "the assertions cover what the evidence says needs to be covered"
Each assertion uses the correct SDK assertion type for its property's semantics (
```
Always
```
/
```
AlwaysOrUnreachable
```
for safety,
```
Sometimes(cond)
```
for liveness or meaningful semantic state,
```
Reachable
```
/
```
Unreachable
```
for path and outcome checks)
```
Sometimes(true, ...)
```
assertions should be rewritten as
```
Reachable(...)
```
.
Assertion messages are unique across the touched code; no broad property is implemented by reusing one message at multiple unrelated callsites
Workload-only instrumentation was not used where surgical SUT-side assertions would provide materially better search guidance for rare, dangerous, or timing-sensitive internal states
```
Reachable(...)
```
markers are attached to distinct outcomes or branch results, not redundant early path-entry locations on the same straight-line flow

Test commands exist under

antithesis/test/

and use valid prefixes (

parallel_driver_

singleton_driver_

serial_driver_

first_

eventually_

finally_

anytime_

)

Test commands are written in the project's language, not Bash, and reuse the project's clients and libraries where possible
No test command is responsible for Antithesis lifecycle signaling;
```
setup_complete
```
is emitted before test commands begin
Test templates are structured correctly at the path that will map to
```
/opt/antithesis/test/v1/{name}/
```
in the container
Helper files or directories are prefixed with
```
helper_
```
so Test Composer ignores them
```
antithesis/scratchbook/property-catalog.md
```
is updated to reflect the implementation status of every property in scope, with provenance frontmatter (
```
commit
```
and
```
updated
```
) reflecting the current codebase state
Assertions are in workload code or surgical SUT locations — not scattered across production paths
Use
```
snouty validate
```
on
```
antithesis/config
```
to ensure that the compose setup can reach setup complete and any configured test-templates work. Make sure to build the latest images before running validate.

在宣布本技能完成之前，根据以下标准审查你的工作。如果你的Agent支持生成子Agent，可创建一个具有全新上下文的新Agent来执行此审查——为其提供本技能文件的路径，并让它读取所有输出工件。具有全新上下文的审查者能发现上下文内审查遗漏的盲点。如果你的Agent不支持子Agent，请自行执行审查：重新阅读文件顶部的成功标准，然后系统地对照实际输出检查以下每一项。

审查标准：

对于所有范围内的属性，实现覆盖了其证据文件中描述的代码路径、故障场景和插装点——不仅是“存在断言”，而是“断言覆盖了证据中说明需要覆盖的内容”
每个断言都使用了与其属性语义匹配的正确SDK断言类型（
```
Always
```
/
```
AlwaysOrUnreachable
```
用于安全属性，
```
Sometimes(cond)
```
用于活性或有意义的语义状态，
```
Reachable
```
/
```
Unreachable
```
用于路径和结果检查）
```
Sometimes(true, ...)
```
断言应重写为
```
Reachable(...)
```
被修改代码中的断言消息是唯一的；不会在多个不相关的调用点复用同一个消息来实现宽泛的属性
对于罕见、危险或对时间敏感的内部状态，若精准的SUT端断言能提供更好的搜索指导，则不应使用仅工作负载端的插装
```
Reachable(...)
```
标记应附加到不同的结果或分支结果上，而非同一线性流程中冗余的早期路径入口位置

antithesis/test/

下存在测试命令，且使用了有效前缀（

parallel_driver_

、

singleton_driver_

、

serial_driver_

、

first_

、

eventually_

、

finally_

、

anytime_

）

测试命令使用项目的语言编写，而非Bash，并尽可能复用项目的客户端和库
没有测试命令负责Antithesis生命周期信号；测试命令开始前会发出
```
setup_complete
```
信号
测试模板的结构正确，其路径在容器中会映射到
```
/opt/antithesis/test/v1/{name}/
```
辅助文件或目录以
```
helper_
```
为前缀，以便Test Composer忽略它们
```
antithesis/scratchbook/property-catalog.md
```
已更新，以反映所有范围内属性的实现状态，且来源前置信息（
```
commit
```
和
```
updated
```
）反映了当前代码库状态
断言位于工作负载代码或精准的SUT位置——而非分散在生产路径中
在
```
antithesis/config
```
上运行
```
snouty validate
```
，确保compose设置能完成初始化，且所有配置的测试模板都能正常工作。运行验证前请确保构建了最新的镜像。

antithesis-workload

Original

Translation

Antithesis Workload

Antithesis Workload

Purpose and Goal

目的与目标

Prerequisites

前提条件

Scoping

范围界定

Detect implementation status

检测实现状态

Present and recommend

展示与推荐

Other scoping questions

其他范围界定问题

Definitions and Concepts

定义与概念

Documentation Grounding

文档依据

Reference Files

参考文件

Recommended Workflows

推荐工作流

Implement next property

实现下一个属性

Post-triage iteration

分类审查后迭代

General Guidance

通用指导

Output

输出

Self-Review

自我审查