用途
test-fixing 用于系统性地识别并修复所有失败测试，借助智能分组策略避免盲目逐个调试。适用时机包括：用户明确要求修复测试（如“fix these tests”“make tests pass”）、报告测试失败（如“tests are failing”“test suite is broken”）、完成实现后希望测试通过，或提到由测试引起的 CI/CD 失败。
主要能力
- 初始测试运行：执行 make test 识别全部失败测试，并分析失败总数、错误类型与模式、受影响的模块和文件。
- 智能错误分组：按错误类型（ImportError、AttributeError、AssertionError 等）、模块/文件（同一文件导致多个测试失败）、根因（缺失依赖、API 变更、重构影响）对失败进行归类。分组优先级依据受影响测试数量（影响大的优先）和依赖顺序（先修基础设施，再修功能）。
- 系统性修复：对每个分组（从影响最大的开始）定位根因、阅读相关代码、用 git diff 检查近期改动、理解错误模式，再用 Edit 工具实施修复，遵循项目约定（参见 CLAUDE.md），保持改动最小且聚焦。
- 验证修复：运行该分组相关测试子集，可使用 pytest 标记或文件模式，例如
uv run pytest tests/path/to/test_file.py -v或uv run pytest -k "pattern" -v，确认该组通过后再进入下一组。 - 最终验证：所有分组修复完成后运行完整测试套件
make test，确认没有回归，并检查测试覆盖率保持完整。
使用方式与修复顺序
修复顺序建议为：先处理基础设施问题（导入错误、缺失依赖、配置问题），再处理 API 变更（函数签名变化、模块重组、变量或函数重命名），最后处理逻辑问题（断言失败、业务逻辑缺陷、边界情况处理）。
示例工作流：用户反馈“重构后测试失败”，运行 make test 发现 15 个失败，分组为 8 个 ImportError（模块重命名）、5 个 AttributeError（函数签名变化）、2 个 AssertionError（逻辑缺陷）；先修 ImportError 并运行子集验证，再修 AttributeError 并验证，然后修 AssertionError 并验证，最后运行完整套件，全部通过。
最佳实践
一次只修一组；每次修复后运行聚焦测试；用 git diff 理解近期变更；从失败中寻找模式；当前组未通过前不要进入下一组；保持改动最小且聚焦。
限制
资料中未提供该技能的收费、价格、支持平台等具体信息，暂未提供。