用途：write-testing 用于把“编写测试”本身当作交付任务，而不是附带产物。它适用于需要补齐覆盖缺口、为验收标准（AC）建立验证、或为高风险需求与不变量提供更强检查的场景。若测试是某个功能或修复的一部分，应遵循对应指南；若测试已存在非确定性失败，则属于 fix-flaky-test 的范畴。
主要能力与规则：先以行为而非行数描述覆盖缺口，例如“重试路径在第三次失败时没有退避”，而不是“该文件覆盖率 40%”。测试只针对调用者可观察的公共接口，不断言私有方法或模块私有状态。每个测试只保留一个失败原因，拆分捆绑断言，并让测试名与断言消息说明破坏了什么行为。每个测试都要翻转断言或注释掉被测生产路径，确认其会失败，恢复后确认通过，并粘贴一次代表性的失败到通过过程。对绑定 AC 的测试，要证明它在对应需求被违反时失败，而非相邻条件；若无法构造这样的测试，应作为阻塞问题交回规格作者。高风险需求或不变量应使用基于属性、蜕变或变异测试等更强检查，并记录其覆盖内容。测试必须保持确定性，避免顺序依赖、时间假设、共享可变状态、未沙箱网络或未播种随机性。不得为了让测试更易写而修改生产代码，除非任务范围明确允许；难以测试的代码和测试暴露的缺陷应记录为发现候选，而非就地修复。覆盖率应作为地图而非分数，测试按项目既有约定放置，运行整套测试并粘贴真实输出，命令从 AGENTS.md 解析，未定义时询问。不得对自己的工作出具评审结果。
使用方式：开始前打开 references/task-template.md 并复制到任务文件，按其中结构填写覆盖缺口、按行为组织的测试用例表、放置表、翻转证据与自审。完成前需逐项通过自审门：每个新测试都经过翻转、整套测试在最终编辑后运行并粘贴输出、每个测试只针对公共接口且只有一个失败原因、AC 绑定测试在需求被违反时失败、高风险需求有强化检查、任务范围外无生产代码改动、无可能导致 CI 不稳定的依赖、且未对自己的工作出具评审结果。
限制：这些是评审包检查的约定，编辑时没有强制机制。资料未提供具体安装命令、平台支持、收费或价格信息。