antd-test-review
- Repo stars 98,249
- Author updated Live
- Author repo ant-design
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @ant-design · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- Node.js
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: antd-test-review
description: 一、只判断测试用例是否合理，不负责创建或补充测试。 二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。 三、验证场景默认只做静态审查，不默认运行测试。 四、输出先给结论…
category: design
runtime: Node.js
---
# antd-test-review output preview
## PART A: Task fit
- Use case: 一、只判断测试用例是否合理，不负责创建或补充测试。 二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。 三、验证场景默认只做静态审查，不默认运行测试。 四、输出先给结论，再给最关键原因。 当用户提到以下意图时使用此 skill： runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “目标 / 何时使用 / 不做的事” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “一、只判断测试用例是否合理，不负责创建或补充测试。 二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。 三、验证场景默认只做静态审查，不默认运行测试。 四、输出先给结论，再给最关键原因。 当用户提到以下意图时使用此 skill： runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “目标 / 何时使用 / 不做的事” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “目标 / 何时使用 / 不做的事”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: antd-test-review
description: 一、只判断测试用例是否合理，不负责创建或补充测试。 二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。 三、验证场景默认只做静态审查，不默认运行测试。 四、输出先给结论…
category: design
source: ant-design/ant-design
---
# antd-test-review
## When to use
- Ant Design 测试用例审查 一、只判断测试用例是否合理，不负责创建或补充测试。 二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。 三、验证场景默认只做静态审查，不默认运行测试。 四、输出先给结论，再给最关…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “目标 / 何时使用 / 不做的事” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "antd-test-review" {
input -> user goal + target files + boundaries + acceptance criteria
context -> 目标 / 何时使用 / 不做的事
rules -> SKILL.md triggers / order / output contract
runtime -> Node.js | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Ant Design 测试用例审查
目标
一、只判断测试用例是否合理，不负责创建或补充测试。
二、优先识别“用 a 证明 a”、实现细节自证、重复覆盖这类低价值测试。
三、验证场景默认只做静态审查，不默认运行测试。
四、输出先给结论，再给最关键原因。
何时使用
当用户提到以下意图时使用此 skill：
- 验证测试 case
- review 测试是否合理
- 判断测试是否无意义
- 判断测试是否重复
- 判断测试是不是“用 a 证明 a”
- 决定测试应保留、改写还是删除
不做的事
- 不主动新增测试
- 不主动补回归测试
- 不主动修改生产代码
- 不默认执行
npm test、npm run test:update
如果用户明确要求“顺手给改写建议”，可以在结论后补一句改写方向；但主任务仍然是审查，不是落地实现。
核心判断
一、先看契约是否独立
先用一句话描述这条测试声称在保护什么：
当 <前置条件> 时，<组件/方法> 应该 <可观察结果>。
如果这句话只能从当前实现反推出来，这条测试大概率不值得保留。
二、expected 必须来自独立来源
高质量来源包括：
- issue / PR 里明确描述的回归现象
- 组件文档、API、demo、FAQ
- DOM / React / WAI-ARIA / 浏览器语义
- 用户可感知的文本、属性、交互、布局结果
低质量来源包括：
- 生产代码里的同一个 helper、token、常量、分支逻辑
- 在测试里复制一遍实现
- “因为实现可能要这样写，所以我断言它这样写了”
三、优先审查外部行为，不审查实现细节
优先级：
- DOM / 文本 / 属性 / role / aria
- callback 的触发与参数
- 用户或使用方能观察到的行为结果
- 只有存在独立契约时，class / style 才能作为代理信号
如果断言锁定的是具体 CSS 属性、临时 class、内部状态或中间过程，默认先判低价值。
四、默认拦截样式实现自证
以下写法默认按“无实际作用”或“需要改写”处理，除非能证明它对应公开契约：
toHaveStyle(...)toHaveClass(...)- 断言具体 CSS 属性、CSS 变量、临时 class 存在
典型反例：
expect(node).toHaveStyle({ whiteSpace: 'nowrap' })
如果它只是验证“实现里加了 nowrap”，而不是验证独立可感知行为，就属于“用 A 证明 A”。
五、重复覆盖也应判低价值
以下情况优先判为重复或冗余：
- 已有
mountTest、rtlTest或其他聚焦行为测试覆盖相同契约 - 同一组件已有相同 props 组合和同类断言
- 新 case 只是换文案、换变量名、换写法，没有新增行为分支
输出要求
默认只输出最终结论，不写调研过程。
格式：
结论：此用例无实际作用 / 此用例可保留 / 此用例需要改写
原因：
- ...
- ...规则：
- 先下结论，再给原因
- 原因保留 2 到 4 条即可
- 不要先讲命令、搜索过程、推理链
- 除非用户追问，否则不要展开长篇建议
执行流程
1. 静态审查优先
当用户是在验证测试是否合理时：
- 默认只读代码、diff、文档、demo、已有测试
- 默认不运行测试
- 不把“能不能跑过”当成主要判断依据
只有用户明确要求“跑一下”“验证 red/green”时，才执行测试命令。
2. 提炼被保护的契约
先回答：
- 这条测试到底想保护什么公开行为？
如果回答不稳，优先判为：
结论：此用例无实际作用。
3. 查独立依据
从以下位置找证据：
- 当前 PR / issue 描述
- 组件文档与 demo
- 现有测试
- 外部语义规范
如果找不到独立依据，而 expected 又来自实现本身，直接判低价值。
4. 查是否重复
需要时搜索现有覆盖：
rg -n "<关键字>|<issue号>|<行为描述>" components/<component> tests如果同一契约已经被保护，新 case 通常应判为冗余。
5. 给出分类结论
分类标准：
此用例可保留条件：契约独立、断言面向外部行为、不是重复覆盖此用例需要改写条件：测试意图可能对，但断言方式锁定实现或证据不足此用例无实际作用条件：expected 同源、实现自证、重复覆盖、只测存在性、只测内部细节
Ant Design 约束
__tests__中引用仓库内代码时使用相对路径- 优先沿用目标组件现有测试结构与 helper
- 对样式问题，先问“能否用更外层行为表达”，再接受 style/class 断言
快速拦截
以下情况默认直接质疑：
- 输入
a，expected 也从同一路径算出a - 断言私有 helper / hook / 中间 state
- 断言
className、whiteSpace、display、zIndex等具体实现 - 在已有
mountTest、rtlTest旁边再补同类 case - 只做
toBeTruthy()/toBeDefined()这类存在性断言
Decide Fit First
Design Intent
How To Use It
Boundaries And Review