用途：把预期产品行为先写成 Momentic 测试，再改产品代码，用测试定义产品契约。资料强调不得反过来让测试迁就实现。
主要能力与流程：必修顺序为阅读仓库指引、momentic.config.yaml 及附近测试与模块；报告预计受影响的 Momentic 测试；先增改测试，再审阅测试差异作为产品规格；之后才实现产品变更。新功能创建最小新测试描述用户旅程；变更功能更新已有测试而不是重复覆盖；共享模块需追踪真实行为影响，不能只凭文件名推断。若无测试受影响，需先说明原因。
使用方式：实现期间用单元测试、类型检查、Lint 等快速检查，不每次编辑或提交都跑 Momentic。在可持久运行的端到端检查点，准备测试所需数据与状态，启用应通过的测试，并询问是否运行最小受影响测试集；需用户明确确认后才运行。请求再次运行前需再次确认，除非已获迭代运行授权。
编写规范：新测试优先用 AI action V3 的 act: 步骤表达高层目标，配合与附近测试一致的断言风格。稳定流程保留缓存，缓存重跑更快更确定；目标本身动态时才设 cache: false，不要用它掩盖过期规格。v2 测试可直接编辑，v1 YAML 不可直接改，须用 Momentic MCP 工具持久化变化。
局限与注意：测试执行耗时并消耗额度，默认不执行；编辑与 Lint 无需确认。需负责检查点所需数据、账号、功能开关、权限与集成状态，优先复用已有测试装置，新增测试专用能力必须仅限测试环境、可重复调用且不得引入生产后门。未满足时应保持 disabled: true 并记录原因与启用条件，不得因此弱化断言或绕开真实产品缺陷。
其他细节：MCP 预览返回 CacheId 时需带入保存的步骤；具体兼容版本、费用与运行时长暂未提供。