在 Antithesis…

已具备 Antithesis scratchbook、docker-compose 和 snouty 时，逐个 property 实现断言、测试命令与支撑代码，并用 triage 结果改进覆盖。

适用场景

解决思路

1. 先与相关 skill 协作：用 `antithesis-research` 建立 property catalog，用 `antithesis-setup` 搭建基础设施，用 `antithesis-triage` 审查运行后回到本 skill 改进 workload；若要提交或启动运行，用 `antithesis-launch`，不要直接运行 `snouty launch`。
2. 以成功标准为目标：把 property catalog 映射为具体断言，确保 `antithesis/test/` 下有测试命令并锻炼正确行为，创建首批真实测试模板或扩展现有模板，并把 triage 发现转成 workload 或 property 更新。
3. 每次调用 `Implement next property` 工作流只聚焦一个 property；若用户要求多个，先建议一次一个，说明上下文累积会降低实现质量且每个 property 工作量不可预测，询问先做哪个；若用户坚持，先警告再继续。
4. 若用户指定 property，跳过全量 catalog 扫描，但仍根据该 property 的 evidence file 评估状态；若已完全实现，告知用户，不要重复实现。
5. 若用户未指定 property，执行完整的实现状态检测与推荐流程。
6. 检测实现状态时，对 catalog 中每个 property，在现有测试和 SUT 代码中搜索 Antithesis SDK 断言调用，并与 `antithesis/scratchbook/properties/{slug}.md` 交叉引用，评估现有断言是否覆盖 evidence file 描述的代码路径、失败场景和埋点；分类为 Implemented、Partially implemented、Not implemented。
7. 若 agent 支持 sub-agents，将检测工作委派给 sub-agent，要求返回每个 property 的摘要（状态 + 简要理由），以保持主实现 agent 的上下文干净。
8. 展示状态时读取 catalog 中存在的 provenance frontmatter 并包含它；使用实际找到的字段，不因 schema 演进或旧 frontmatter 不完整而视为损坏；用平实语言描述，如完整 schema、部分 schema 或缺失 provenance 的情况。
9. 用户界面的 commit 显示使用短 hash（前 12 字符），frontmatter 仍存完整 SHA。
10. 不要每次要求用户重新确认 provenance；将其作为上下文显示后继续，若与实际系统不匹配由用户指出。
11. 一次只推荐一个 property，不要倾倒完整 catalog；默认选一个，解释原因，并等待确认。
12. 仅当用户明确要求讨论做什么而不是接受单个推荐时，给高层摘要（按状态计数、显著聚类、异常情况），并按对话需要展示具体 property。
13. 推荐策略：刚起步、已实现 property 很少或没有时，推荐简单的 property（测试没有很多活动部件）；最高优先级的 property 通常需要最多 setup 和协调，不适合起步；简单 property 能建立势头，端到端锻炼 SDK 和测试 harness，让用户和 agent 熟悉工作流；告知用户正在使用此策略及原因。
14. 已顺利推进、多个 property 已实现且 harness 端到端验证后，切换到基于优先级的排序：先完成 partially implemented 的 property，再选与最近已实现 property 聚类的未实现 property（见 `antithesis/scratchbook/property-relationships.md`），最后是其他高优先级未实现 property；告知用户已切换。
15. 解释为什么选该 property，等待用户确认或另选后再继续。
16. 对选中的 property，读取 catalog 条目及其 evidence file。
17. 只向用户询问无法安全推断的阻塞项或范围决策，例如非标准 catalog 位置、repo 不明显的项目语言或 SDK 选择、迭代现有 workload 时的 triage 发现或已知缺口。
18. 理解并应用定义：SUT 是被测系统；test template 是 `/opt/antithesis/test/v1/{name}/` 下的测试命令目录，每个 timeline 运行一个 test template 的命令，`helper_` 前缀的文件或子目录会被 Antithesis 忽略；test command 是 test template 中带有效前缀的可执行文件（`parallel_driver_`、`singleton_driver_`、`serial_driver_`、`first_`、`eventually_`、`finally_`、`anytime_`）；timeline 是 SUT 和 workload 的一次线性执行，Antithesis 并行运行并分支以搜索有趣行为；安全或正确性用 `Always`/`AlwaysOrUnreachable`，活性或非平凡语义状态用 `Sometimes(cond)`，有意义结果或禁止路径是否被走到用 `Reachable`/`Unreachable`。
19. 使用 `antithesis-documentation` skill 访问文档，优先 `snouty docs`；需要时查阅 test commands reference（`https://antithesis.com/docs/product/test_templates/test_composer_reference.md`）、SDK reference（`https://antithesis.com/docs/reference/sdk.md`）、properties/assertions（`https://antithesis.com/docs/concepts/properties_assertions/assertions.md`）、fault injection（`https://antithesis.com/docs/product/fault_injection.md`）。
20. 实现 workload 侧组件或 wrapper 时读 `references/component-implementation.md`。
21. 把 property 转成 SDK 断言时读 `references/assertions.md`。
22. 编写命令和整理测试模板时读 `references/test-commands.md`。
23. 为被测 property 选择 value menu 时读 `references/interesting-values.md`。
24. triage 后改进覆盖率和断言时读 `references/iteration.md`。
25. Implement next property 步骤：检测实现状态，然后推荐一个 property 并解释原因。
26. 获取用户对实现哪个 property 的确认。
27. 读 `references/component-implementation.md`。
28. 读 `references/assertions.md`。
29. 读 `references/test-commands.md`。
30. 读 `references/interesting-values.md`。
31. 识别 property 的 value menu —— 边界值加配置限制族；发现过程和示例见 `interesting-values.md`。
32. 实现所选 property：断言、测试命令和支持代码。
33. 将 Sometimes 断言写成为 workload 旨在驱动的行为提出的 reach claims（见 `references/assertions.md` 的 `Sometimes Assertions as Workload Reach Claims`）；断言前置条件，而不是违规。
34. 用 `antithesis-launch` 运行测试，然后用 `antithesis-triage` 检查哪些断言触发；未触发的 reach claims 是 workload 没到达目标的证据，也是迭代起点。
35. Post-triage iteration 步骤：读 `references/iteration.md`。
36. 若断言需要改变，读 `references/assertions.md`。
37. 若命令覆盖需要改变，读 `references/test-commands.md`。
38. 同时更新 workload 和相关的 Antithesis scratchbook artifacts。
39. 将 Antithesis-only 代码排除在生产路径之外；若必须修改共享代码，保持改动外科手术式且易于隔离。
40. 优先简单 workload 代码，而不是高度可配置的抽象。
41. 将 workload 设计为容错的：不同于 happy-path 测试中错误意味着 bug，workload 在故障注入和并发活动下运行，瞬时错误是预期而非异常；应朝目标推进，而不是第一次失败就退出。
42. 假设 `antithesis-setup` 已让系统在基本空闲状态下可运行；此 skill 负责系统启动后 workload 做什么。
43. 假设 `antithesis-setup` 已安装相关 SDK 并在 SUT 中添加一个最小 bootstrap 断言；此 skill 负责该初始集成检查之外的更广泛 property catalog。
44. 用项目语言编写测试命令，不用 Bash，以便复用项目的 client、helper 和 library。
45. 输出：为范围内每个 property 提供断言，放在 workload 代码或精心选择的 SUT 位置。
46. 输出：在 `antithesis/test/` 下提供测试命令和支持 workload 代码。
47. 输出：当已实现 property 变化时，更新 `antithesis/scratchbook/property-catalog.md`。
48. Self-review before declaring complete：若 agent 支持 sub-agents，创建一个 fresh-context reviewer，给它本 skill 文件路径并让它读取所有输出 artifacts；若不支持，重新阅读本文件顶部的成功标准，然后逐项核对下方标准与真实输出。
49. Self-review：对范围内每个 property，实现覆盖其 evidence file 描述的代码路径、失败场景和埋点，而不只是“存在断言”。
50. Self-review：每个断言使用与 property 语义匹配的正确 SDK 断言类型：安全用 `Always`/`AlwaysOrUnreachable`，活性或有意义语义状态用 `Sometimes(cond)`，路径和结果检查用 `Reachable`/`Unreachable`。
51. Self-review：`Sometimes(true, ...)` 断言应改写为 `Reachable(...)`。
52. Self-review：断言 property 名称是内联常量字符串字面量，在整个项目中唯一，绝不在运行时构建或通过变量传递（静态分析必须能预先编目；见 `references/assertions.md` 的 `Naming`）；不要通过在多个无关调用点复用同一 message 来实现宽泛 property。
53. Self-review：当外科手术式 SUT 侧断言能为罕见、危险或时序敏感的内部状态提供实质性更好的搜索指导时，不要使用 workload-only instrumentation。
54. Self-review：workload 代码在瞬时错误下朝既定目标推进，而不是第一次失败就退出。
55. Self-review：workload 同时记录 attempted 和 acknowledged 操作，以便后续断言检查边界（例如“计数器变化值在 `[acknowledged, attempted]` 中”）。
56. Self-review：使用重试时，重试与 SUT 的幂等性契约一致。
57. Self-review：`Reachable(...)` 标记附在 distinct outcomes 或 branch results 上，而不是同一直线流程上冗余的早期路径进入位置。
58. Self-review：对测试命令中的有界输入，抽取来自 property-specific value menus（输入类型的边界值加 property 代码路径中的配置限制族），而不是任意范围；或者测试命令记录该 menu 轴不适用。见 `interesting-values.md`。
59. Self-review：测试命令存在于 `antithesis/test/` 下，并使用有效前缀（`parallel_driver_`、`singleton_driver_`、`serial_driver_`、`first_`、`eventually_`、`finally_`、`anytime_`）。
60. Self-review：测试命令用项目语言编写，不用 Bash，并尽可能复用项目 client 和 library。
61. Self-review：没有测试命令负责 Antithesis 生命周期信号；`setup_complete` 在测试命令开始前发出。
62. Self-review：测试模板结构正确，位于将映射到容器内 `/opt/antithesis/test/v1/{name}/` 的路径。
63. Self-review：helper 文件或目录以 `helper_` 为前缀，以便 Antithesis 忽略。
64. Self-review：展示状态时显示了 catalog 中存在的 provenance frontmatter，让用户能发现与正在工作的系统不匹配。
65. Self-review：`antithesis/scratchbook/property-catalog.md` 已更新以反映范围内每个 property 的实现状态，provenance frontmatter 反映当前代码库状态（刷新 `commit` 和 `updated`；保留现有 catalog 的 `sut_path` 和 `external_references`）。frontmatter 格式定义在 `antithesis-research` skill 的 `references/scratchbook-setup.md`。
66. Self-review：Sometimes 断言作为 workload 旨在驱动行为的 reach claims 存在，且一次测试运行中未触发的 reach claims 已被用作迭代信号（见 `references/assertions.md` 的 `Sometimes Assertions as Workload Reach Claims`）。
67. Self-review：没有 reach claim 是同一位置 `Always` 或 `AlwaysOrUnreachable` 的否定，且每个 reach claim 在系统正确时仍触发（见 `references/assertions.md` 的 `A Reach Claim Asserts The Precondition, Never The Violation`）。
68. Self-review：断言在 workload 代码或外科手术式 SUT 位置，而不是散布在生产路径。
69. Self-review：对 `antithesis/config` 使用 `snouty validate`，确保 compose setup 能达到 setup complete 且任何配置的 test-templates 可用；运行 validate 前确保构建最新镜像。

适用边界 · 注意事项

• 未创建 `antithesis/scratchbook/`、缺少 Antithesis 的 `docker-compose.yaml`、或未安装 `snouty` 时不要开始；先用 `antithesis-research`、`antithesis-setup` 和 snouty 安装说明补齐。
• 用户要求提交或启动运行时应使用 `antithesis-launch`，不要直接运行 `snouty launch`。
• 用户要求一次实现多个 property 时先建议一次一个；若其坚持，先警告上下文累积会降低实现质量，再继续。