用途
该技能用于在代码变更过程中强制执行测试驱动开发（TDD）工作流，即红（Red）→ 绿（Green）→ 重构（Refactor）。适用于任何应当被测试覆盖的代码修改。
主要能力
- 强制遵循 TDD 三步循环：先写失败测试，再写最小实现使其通过，最后在测试保持通过的前提下重构。
- 若项目中没有测试，要求先添加最小测试框架和一个失败测试。
- 支持识别最小可观察行为，并围绕该行为编写或更新测试。
- 提供测试命令建议，包括通过 Turborepo 运行全部测试、按包过滤、直接使用 Vitest 进行细粒度控制。
- 规定测试范围优先选择最窄粒度：单文件、包级别，仅在必要时才使用仓库级别。
- 规定类型检查策略：类型必须始终通过，不得归咎于已有错误，需修复或回退。
- 明确要求使用 Vitest，禁止使用 bun:test 的导入或 API。
使用方式
工作流如下：
- 识别最小的可观察行为。
- 添加或更新一个在当前代码上会失败的测试。
- 运行最小相关测试命令（尽可能针对性运行）。
- 实现最小代码使其通过。
- 在测试仍然通过的情况下进行重构。
- 报告：运行的测试命令及结果。
如果测试无法运行，需说明原因（缺少依赖、环境、凭证等），仍然先编写失败测试并注明预期结果，并提供建议的测试命令供用户运行。
测试命令示例：
# 通过 Turborepo 运行所有测试
bun run test
# 按包过滤
bun run test --filter=@skillrecordings/core
bun run test --filter=web
# 直接使用 Vitest（需要细粒度控制时）
bun run test:all
bun run test:all -- -t "name of test"
bun run test:all -- packages/core/src/tools/process-refund.test.ts
常见 Vitest 模式：
// Mocking
const mockFn = vi.fn()
vi.mocked(someModule).someMethod.mockResolvedValue(result)
// Hoisting mocks (required for factory functions)
const mockClient = vi.hoisted(() => ({ method: vi.fn() }))
vi.mock('./client', () => ({ client: mockClient }))
// Spying
vi.spyOn(object, 'method').mockImplementation(...)
正确与错误的导入示例：
// ✅ CORRECT - Vitest
import { describe, it, expect, vi, beforeEach } from 'vitest'
// ❌ WRONG - bun:test (DO NOT USE)
import { describe, it, expect, mock } from 'bun:test'
响应中需包含的说明：首先编写了哪个测试、用于达到红和绿的命令、任何改变结构但不改变行为的重构。
适用场景
适用于任何可测试的代码变更，尤其是需要确保代码质量、行为正确性和可维护性的开发任务。特别适合已有测试基础设施或需要建立测试基础设施的项目。
限制
- 强制使用 Vitest，禁止使用 bun:test。
- 类型检查必须通过，不得以已有错误为由忽略。
- 测试范围应尽可能窄，避免不必要的全仓库测试。
- 若测试无法运行，需明确说明原因并提供建议命令，但仍需先编写失败测试。