用途：当用户新增或更新单元、集成、端到端测试，报告 bug 需要回归测试，或在重构后需要验证行为未被破坏时使用。若仓库已有测试工具链，应先检测并沿用，不要另起炉灶。
主要能力：检测 package.json、devDependencies 与配置文件（jest.config.、vitest.config.、playwright.config.、cypress.config.）以识别现有框架；按仓库惯例选择测试文件位置与命名（tests、.test.ts、.spec.ts、Component.test.tsx）；编写 TS 友好的测试，尽量不用 any，异步代码使用 await；为已报 bug 先写失败测试再改实现，并用回归编号命名。
框架倾向：Node/后端/共享库优先 Vitest，其次 Jest；React/UI 用 Testing Library 搭配现有 runner，如 @testing-library/react 配 Vitest 或 Jest；端到端优先 Playwright，若仓库已用 Cypress 或用户明确要求则用 Cypress；Mocha、Ava、Node 内置 runner 等较少见栈也应尊重并适配。
原则：测试行为而非实现细节；UI 通过用户可见的 DOM、事件、ARIA 查询（getByRole、getByLabelText），避免依赖 test ID；服务测试公共 API；测试保持小而确定、运行快；减少 mock，仅对外部服务、网络、慢依赖使用；避免对自身业务逻辑过度 mock。使用快照谨慎，复杂对象或 DOM 改用针对性断言；不要直接测试私有方法；避免依赖真实时间、网络或全局状态的脆弱测试。
运行：沿用已有脚本，如 npm test、pnpm test、npx vitest、npx jest、npx playwright test；新增命令需按现有风格写入 package.json scripts。
限制：资料未提供具体安装命令、版本要求、收费或平台信息；未说明对特定 tsconfig 的强制要求，仅建议存在 tsconfig.test.json 时使用。生成测试时优先少量高价值用例，而非机械式大批量套件。