chore: 添加官方 antd/ant-design agent skills 与 AGENTS.md 技能引用

This commit is contained in:
2026-09-23 15:45:30 +08:00
parent ca919c3307
commit fdfc2fb544
5 changed files with 473 additions and 0 deletions
+22
View File
@@ -0,0 +1,22 @@
MIT LICENSE
Copyright (c) 2015-present Ant UED, https://xtech.antfin.com/
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+74
View File
@@ -0,0 +1,74 @@
---
name: ant-design
description: Decision guide for antd 6.x, Ant Design Pro 5/ProComponents, Ant Design X v2, and the offline `@ant-design/cli`. Use for component selection, theming/tokens, SSR, a11y, performance, routing/access/CRUD, AI/chat UI patterns, local API lookup, debugging, migration, and usage analysis.
---
# Ant Design
## S - Scope
- Target: `antd@^6` + React 18-19, with `ant-design-pro@^5` / `@ant-design/pro-components` and `@ant-design/x@^2` when needed.
- Tooling: `@ant-design/cli` for offline component metadata, demos, changelogs, migrations, linting, doctor checks, and usage analysis.
- Focus: decision guidance only; no end-user tutorials.
- Source policy: official docs only; no undocumented APIs or internal `.ant-*` coupling.
### Default assumptions
- Language: TypeScript.
- Styling: tokens first, then `classNames`/`styles`; avoid global overrides.
- Provider: one root `ConfigProvider` unless strict isolation is required.
### Mandatory rules
- Before writing or changing antd component code, query the component API first with `antd info <Component> --format json`. Do not rely on memory when the CLI can answer it offline.
- Always use `--format json` with `antd` CLI commands.
- If the project version matters, match it with `--version <x.y.z>` or let the CLI auto-detect from local `node_modules`.
- After changing antd code, run `antd lint <changed-path> --format json`.
- If an `antd` CLI command crashes, returns wrong data, or violates its documented behavior, prepare an `antd bug-cli` preview for user confirmation instead of silently working around it.
- For component questions, first map the component name to the official route slug `{components}` (lowercase kebab-case, e.g. `TreeSelect -> tree-select`, `Button -> button`), then request docs in this order (CN first, EN fallback):
1. `https://ant.design/components/{components}-cn`
2. `https://ant.design/components/{components}`
- Examples: `tree-select-cn -> tree-select`, `button-cn -> button`.
- Use only documented antd/Pro/X APIs.
- Do not invent props/events/component names.
- Do not rely on internal DOM or `.ant-*` selectors.
- Theme priority: global tokens -> component tokens -> alias tokens.
## P - Process
### 1) Classify
- Identify layer: core antd, Pro, or X.
- Confirm version, rendering mode (CSR/SSR/streaming), data scale, and whether `@ant-design/cli` should be the primary lookup path.
### 2) Query authoritative sources
- Prefer local `@ant-design/cli` first for structured lookup:
- `antd info` for props/API
- `antd demo` for a working baseline
- `antd doc` for full docs
- `antd token` / `antd semantic` for theming and styling hooks
- `antd doctor`, `antd lint`, `antd usage`, `antd migrate`, `antd changelog` when debugging or upgrading
- Then request the official component docs (`-cn` first, EN fallback) when narrative docs or cross-checking are needed.
### 3) Decide
- Provider baseline: CSR -> `ConfigProvider`; SSR -> `ConfigProvider` + `StyleProvider`.
- Theming baseline: global tokens -> component tokens -> `classNames`/`styles`.
- Output recommendation + risk + verification points (SSR/a11y/perf), citing CLI findings when used.
## O - Output
- Provide short decision rationale (1-3 sentences).
- Include minimal provider/theming strategy.
- Include concrete SSR/a11y/perf checks.
- For Pro: include route/menu/access and CRUD schema direction.
- For X: include message/tool schema and streaming state direction.
## References
| File | Use when |
| --- | --- |
| `references/antd-cli.md` | You need the exact offline CLI workflow for API lookup, demos, linting, doctor checks, migration, changelog review, usage analysis, or bug reporting. |
## Regression checklist
- [ ] One root `ConfigProvider`; SSR style order/hydration verified.
- [ ] Tokens first; no broad global `.ant-*` overrides.
- [ ] Table has stable `rowKey`; sort/filter/pagination entry is unified.
- [ ] Select remote mode disables local filter when using remote search.
- [ ] Upload controlled/uncontrolled mode is explicit with failure/retry path.
- [ ] Pro route/menu/access remain consistent with backend enforcement.
- [ ] X streaming supports stop/retry and deterministic tool rendering.
- [ ] If `antd` CLI was used, commands ran with `--format json` and any CLI defect was escalated via `antd bug-cli` preview.
@@ -0,0 +1,115 @@
# Ant Design CLI
Use this reference when the task involves Ant Design component APIs, demos, docs, migration, project analysis, or debugging and the local `@ant-design/cli` can answer it offline.
## Rules
- Check install first: `which antd || npm install -g @ant-design/cli`
- If any command prints an update notice, run `npm install -g @ant-design/cli` before continuing.
- Always use `--format json`.
- Match the project version with `--version <x.y.z>` when needed.
- Query before writing antd code. Do not guess props from memory.
- After changing antd code, run `antd lint` on the changed path.
## Core workflows
### Writing component code
1. `antd info Button --format json`
2. `antd demo Button basic --format json`
3. Optionally inspect styling hooks:
- `antd semantic Button --format json`
- `antd token Button --format json`
### Full docs
- `antd doc Table --format json`
- `antd doc Table --lang zh --format json`
### Debugging
1. `antd doctor --format json`
2. `antd info Select --version 5.12.0 --format json`
3. `antd lint ./src/components/MyForm.tsx --format json`
### Migration
1. `antd migrate 4 5 --format json`
2. `antd migrate 4 5 --component Select --format json`
3. `antd changelog 4.24.0 5.0.0 --format json`
4. `antd changelog 4.24.0 5.0.0 Select --format json`
### Project analysis
- `antd usage ./src --format json`
- `antd usage ./src --filter Form --format json`
- `antd lint ./src --format json`
- `antd lint ./src --only deprecated --format json`
- `antd lint ./src --only a11y --format json`
- `antd lint ./src --only performance --format json`
### Changelog and versions
- `antd changelog 5.22.0 --format json`
- `antd changelog 5.21.0..5.24.0 --format json`
### Component discovery
- `antd list --format json`
- `antd list --version 5.0.0 --format json`
## Bug reporting
### antd component bugs
Preview first, then ask the user before submitting.
```bash
antd bug --title "DatePicker crashes when selecting date" \
--reproduction "https://codesandbox.io/s/xxx" \
--steps "1. Open DatePicker 2. Click a date" \
--expected "Date is selected" \
--actual "Component crashes with error" \
--format json
```
Submit only after confirmation:
```bash
antd bug --title "DatePicker crashes when selecting date" \
--reproduction "https://codesandbox.io/s/xxx" \
--steps "1. Open DatePicker 2. Click a date" \
--expected "Date is selected" \
--actual "Component crashes with error" \
--submit
```
### CLI bugs
Prepare a report whenever an `antd` command crashes, returns incorrect data, ignores flags, or is inconsistent with other commands.
```bash
antd bug-cli --title "antd info Button returns wrong props for v5.12.0" \
--description "When querying Button props for version 5.12.0, the output includes props that don't exist in that version" \
--steps "1. Run: antd info Button --version 5.12.0 --format json" \
--expected "Props matching antd 5.12.0 Button API" \
--actual "Props include 'classNames' which was added in 5.16.0" \
--format json
```
Submit only after user confirmation:
```bash
antd bug-cli --title "antd info Button returns wrong props for v5.12.0" \
--description "When querying Button props for version 5.12.0, the output includes props that don't exist in that version" \
--steps "1. Run: antd info Button --version 5.12.0 --format json" \
--expected "Props matching antd 5.12.0 Button API" \
--actual "Props include 'classNames' which was added in 5.16.0" \
--submit
```
## MCP mode
If the environment supports MCP, the CLI can run as:
```json
{
"mcpServers": {
"antd": {
"command": "antd",
"args": ["mcp", "--version", "5.20.0"]
}
}
}
```
This exposes structured Ant Design knowledge tools through MCP without network access.
+21
View File
@@ -0,0 +1,21 @@
MIT License
Copyright (c) 2025
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
+241
View File
@@ -0,0 +1,241 @@
---
name: antd
description: >
Use when the user's task involves Ant Design (antd) — writing antd components,
debugging antd issues, querying antd APIs/props/tokens/demos, migrating between
antd versions, or analyzing antd usage in a project. Triggers on antd-related
code, imports from 'antd', or explicit antd questions.
allowed-tools:
- Bash(antd *)
- Bash(antd bug*)
- Bash(antd bug-cli*)
- Bash(npm install -g @ant-design/cli*)
- Bash(which antd)
---
# Ant Design CLI
You have access to `@ant-design/cli` — a local CLI tool with bundled antd metadata for v4/v5/v6. Use it to query component knowledge, analyze projects, and guide migrations. All data is offline, no network needed.
## Setup
Before first use, check if the CLI is installed. If not, install it automatically:
```bash
which antd || npm install -g @ant-design/cli
```
After running any command, if the output contains an "Update available" notice, run `npm install -g @ant-design/cli` to update before continuing.
**Always use `--format json` for structured output you can parse programmatically.**
## Scenarios
### 1. Writing antd component code
Before writing any antd component code, look up its API first — don't rely on memory.
```bash
# Check what props are available
antd info Button --format json
# Get a working demo as starting point
antd demo Button basic --format json
# Check semantic classNames/styles for custom styling
antd semantic Button --format json
# Check component-level design tokens for theming
antd token Button --format json
```
**Workflow:** `antd info` → understand props → `antd demo` → grab a working example → write code.
### 2. Looking up full documentation
When you need comprehensive component docs (not just props):
```bash
antd doc Table --format json # full markdown docs for Table
antd doc Table --lang zh # Chinese docs
```
### 3. Debugging antd issues
When code isn't working as expected or the user reports an antd bug:
```bash
# Check if the prop exists for the user's antd version
antd info Select --version 5.12.0 --format json
# Check if the prop is deprecated
antd lint ./src/components/MyForm.tsx --format json
# Diagnose project-level configuration issues
antd doctor --format json
```
**Workflow:** `antd doctor` → check environment → `antd info --version X` → verify API against the user's exact version → `antd lint` → find deprecated or incorrect usage.
### 4. Migrating between versions
When the user wants to upgrade antd (e.g., v4 → v5):
```bash
# Get full migration checklist
antd migrate 4 5 --format json
# Check migration for a specific component
antd migrate 4 5 --component Select --format json
# See what changed between two versions
antd changelog 4.24.0 5.0.0 --format json
# See changes for a specific component
antd changelog 4.24.0 5.0.0 Select --format json
```
**Workflow:** `antd migrate` → get full checklist → `antd changelog <v1> <v2>` → understand breaking changes → apply fixes → `antd lint` → verify no deprecated usage remains.
### 5. Analyzing project antd usage
When the user wants to understand how antd is used in their project:
```bash
# Scan component usage statistics
antd usage ./src --format json
# Filter to a specific component
antd usage ./src --filter Form --format json
# Lint for best practice violations
antd lint ./src --format json
# Check only specific rule categories
antd lint ./src --only deprecated --format json
antd lint ./src --only a11y --format json
antd lint ./src --only performance --format json
```
### 6. Checking changelogs and version history
When the user asks about what changed in a version:
```bash
# Specific version changelog
antd changelog 5.22.0 --format json
# Version range (both ends inclusive)
antd changelog 5.21.0..5.24.0 --format json
```
### 7. Exploring available components
When the user is choosing which component to use:
```bash
# List all components with categories
antd list --format json
# List components for a specific antd version
antd list --version 5.0.0 --format json
```
### 8. Reporting antd bugs
When you encounter a confirmed antd component bug that can't be resolved locally:
```bash
# Step 1: Preview for user review
antd bug --title "DatePicker crashes when selecting date" \
--reproduction "https://codesandbox.io/s/xxx" \
--steps "1. Open DatePicker 2. Click a date" \
--expected "Date is selected" \
--actual "Component crashes with error" \
--format json
# Step 2: Show to user, ask for confirmation
# Step 3: Submit after user confirms
antd bug --title "DatePicker crashes when selecting date" \
--reproduction "https://codesandbox.io/s/xxx" \
--steps "1. Open DatePicker 2. Click a date" \
--expected "Date is selected" \
--actual "Component crashes with error" \
--submit
```
### 9. Auto-reporting CLI issues
**IMPORTANT: Whenever you use any `antd` CLI command and notice something wrong, you should proactively initiate a bug report using `antd bug-cli`.**
Trigger conditions — report a CLI bug when you observe any of these:
- A command **crashes or exits with an unexpected error**
- A command **returns clearly incorrect data** (e.g. `antd info Button` shows wrong props, missing props, or props from the wrong version)
- A command's **output doesn't match its documented behavior** (e.g. `--format json` returns non-JSON, `--version X` is ignored)
- A command **returns empty or missing data** when it shouldn't (e.g. `antd demo Button` returns no demos, `antd token Button` returns no tokens for v5+)
- **Inconsistencies between commands** (e.g. `antd list` shows a component but `antd info` says it doesn't exist)
**Workflow:**
1. You notice something wrong while using the CLI
2. Gather evidence: the exact command you ran, what was returned, and what you expected
3. Preview the bug report for the user:
```bash
antd bug-cli --title "antd info Button returns wrong props for v5.12.0" \
--description "When querying Button props for version 5.12.0, the output includes props that don't exist in that version" \
--steps "1. Run: antd info Button --version 5.12.0 --format json" \
--expected "Props matching antd 5.12.0 Button API" \
--actual "Props include 'classNames' which was added in 5.16.0" \
--format json
```
4. Show the report to the user: "I noticed an issue with the CLI while working. Here's a bug report — shall I submit it?"
5. Submit after user confirms:
```bash
antd bug-cli --title "antd info Button returns wrong props for v5.12.0" \
--description "..." \
--steps "..." \
--expected "..." \
--actual "..." \
--submit
```
**Key principle:** You are a quality feedback loop for the CLI. Don't silently work around CLI issues — report them so they get fixed. Always confirm with the user before submitting.
### 10. Using as MCP server
If working in an IDE that supports MCP (Claude Desktop, Cursor, etc.), the CLI can also run as an MCP server, exposing all knowledge-query tools directly:
```json
{
"mcpServers": {
"antd": {
"command": "antd",
"args": ["mcp", "--version", "5.20.0"]
}
}
}
```
This provides 7 tools (`antd_list`, `antd_info`, `antd_doc`, `antd_demo`, `antd_token`, `antd_semantic`, `antd_changelog`) and 2 prompts (`antd-expert`, `antd-page-generator`) via MCP protocol.
## Global Flags
| Flag | Purpose |
|---|---|
| `--format json` | Structured output — always use this |
| `--version <v>` | Target a specific antd version (e.g. `5.20.0`) |
| `--lang zh` | Chinese output (default: `en`) |
| `--detail` | Include extra fields (description, since, deprecated, FAQ) |
## Key Rules
1. **Always query before writing** — Don't guess antd APIs from memory. Run `antd info` first.
2. **Match the user's version** — If the project uses antd 4.x, pass `--version 4.24.0`. The CLI auto-detects from `node_modules` if no flag is given.
3. **Use `--format json`** — Every command supports it. Parse the JSON output rather than regex-matching text output.
4. **Check before suggesting migration** — Run `antd changelog <v1> <v2>` and `antd migrate` before advising on version upgrades.
5. **Lint after changes** — After writing or modifying antd code, run `antd lint` on the changed files to catch deprecated or problematic usage.
6. **Report antd bugs** — When you encounter an antd component bug, use `antd bug` to report it. Always preview first, get user confirmation, then submit.
7. **Auto-report CLI issues** — If any `antd` command crashes, returns wrong data, or behaves inconsistently, proactively use `antd bug-cli` to report it. You are the quality feedback loop for the CLI — don't silently work around issues.