tdd-cycle

用途：tdd-cycle 教 AI 按 red-green-domain-commit 五步节奏开发——写一个失败的测试、审查领域完整性、最小实现、审查实现、提交。核心价值是短反馈循环与可验证产出，让 AI 生成的代码保持诚实，避免原始类型偏执、过度工程和未测试复杂度累积。适用于任意语言与测试框架。\n\n主要能力：第一步检测测试运行器，依据项目文件识别语言与命令（如 Cargo.toml 用 cargo test，package.json 用 npx vitest / npx jest / npm test，pyproject.toml 用 pytest，go.mod 用 go test ./...，mix.exs 用 mix test），未知则提示手动配置。采用由外向内节奏：先写 BDD 风格验收测试（可用 ignore/skip 标记挂起），确认被识别并跳过；再细化出第一个单元行为并进入五步循环。垂直切片同时运行内外两层 TDD，外层验收测试在切片大部分时间保持 RED，内层单元测试逐个转 GREEN；外层通过才算切片完成。新项目或引入新架构层时先做 walking skeleton，打通端到端最薄路径。\n\n五个阶段：RED 只改测试文件，写一个含单一断言、引用尚不存在类型的失败测试，运行并粘贴失败输出；DOMAIN（red 后）审查测试是否存在原始类型偏执，创建带 stub 体的类型定义，不写实现逻辑，使测试编译通过但仍失败；GREEN 只改生产文件，写让测试通过的最小代码，运行并粘贴通过输出；DOMAIN（green 后）审查实现是否有贫血模型、泄漏校验等领域违规；COMMIT 是硬门禁，每次 green-domain 完成后必须提交，提交信息须引用当前 GWT 场景，重构须在提交之后单独进行。\n\n限制与边界：每个阶段只能编辑自己类型的文件，RED 不能碰生产代码，COMMIT 只能 git add/commit。一次一个测试、一个断言。不在测试引用之前创建类型。领域审查有否决权，两轮未共识则升级给人类。所有进度必须以实际运行测试并粘贴输出为证据。技能文件本身无法机械阻止违规，需要钩子或编排器门禁来强制执行。可配合 domain-modeling、debugging-protocol、architecture-decisions 等技能使用；缺少依赖时可用 npx skills add jwilger/agent-skills --skill domain-modeling 安装。