.agents/skills/test-review/SKILL.md
一、只判断测试用例是否合理，不负责创建或补充测试。
二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。
三、验证场景默认只做静态审查，不默认运行测试。
四、输出先给结论，再给最关键原因。
当用户提到以下意图时使用此 skill：
npm test、npm run test:update如果用户明确要求“顺手给改写建议”，可以在结论后补一句改写方向；但主任务仍然是审查，不是落地实现。
先用一句话描述这条测试声称在保护什么：
当 <前置条件> 时，<组件/方法> 应该 <可观察结果>。
如果这句话只能从当前实现反推出来，这条测试大概率不值得保留。
高质量来源包括：
低质量来源包括：
优先级：
如果断言锁定的是具体 CSS 属性、临时 class、内部状态或中间过程，默认先判低价值。
以下写法默认按“无实际作用”或“需要改写”处理，除非能证明它对应公开契约：
toHaveStyle(...)toHaveClass(...)典型反例：
expect(node).toHaveStyle({ whiteSpace: 'nowrap' })如果它只是验证“实现里加了 nowrap”，而不是验证独立可感知行为，就属于“用 A 证明 A”。
以下情况优先判为重复或冗余：
mountTest、rtlTest 或其他聚焦行为测试覆盖相同契约默认只输出最终结论，不写调研过程。
格式：
结论：此用例无实际作用 / 此用例可保留 / 此用例需要改写
原因：
- ...
- ...
规则：
当用户是在验证测试是否合理时：
只有用户明确要求“跑一下”“验证 red/green”时，才执行测试命令。
先回答：
如果回答不稳，优先判为：
结论：此用例无实际作用。
从以下位置找证据：
如果找不到独立依据，而 expected 又来自实现本身，直接判低价值。
需要时搜索现有覆盖：
rg -n "<关键字>|<issue号>|<行为描述>" components/<component> tests
如果同一契约已经被保护，新 case 通常应判为冗余。
分类标准：
此用例可保留 条件：契约独立、断言面向外部行为、不是重复覆盖此用例需要改写 条件：测试意图可能对，但断言方式锁定实现或证据不足此用例无实际作用 条件：expected 同源、实现自证、重复覆盖、只测存在性、只测内部细节__tests__ 中引用仓库内代码时使用相对路径以下情况默认直接质疑：
a，expected 也从同一路径算出 aclassName、whiteSpace、display、zIndex 等具体实现mountTest、rtlTest 旁边再补同类 casetoBeTruthy() / toBeDefined() 这类存在性断言