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.

Ant Design CLI You have access to @ant design/cli — a local CLI tool with bundled antd metadata for v4/v5/v6 (plus migration guides for v3 → v4, v4 → v5, 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: After running any command, if the output contains an "Update available" notice, run antd upgrade 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. 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): 3. Debugging antd issues When code isn't working as expected or the user reports an antd bug: Workflow: antd env → capture full environment → antd doctor → check configuration → 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., v3 → v4 or v4 → v5): 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: 6. Checking changelogs and version history When the user asks about what changed in a version: 7. Exploring available components When the user is choosing which component to use: 8. Collecting environment info When you need to understand the project's antd setup, or prepare info for a bug report: Collects: OS, Node, package managers (npm/pnpm/yarn/bun/utoo), npm registry, browsers, core deps (antd/react/dayjs), all @ant design/ and rc packages, and build tools (umi/vite/webpack/typescript/etc.). 9. Reporting antd bugs When the user asks you to report an antd bug: 10. Reporting CLI issues When the user asks you to report a CLI bug, or explicitly requests help filing one: Show the report to the user and confirm before submitting: Opt out: If the environment variable ANTD NO AUTO REPORT=1 is set, skip all bug reporting suggestions entirely — do not suggest antd bug or antd bug cli unless the user directly asks. 11. Upgrading the CLI When the user wants to update @ant design/cli to the latest version, or when an "Update available" notice appears: The command detects which package manager installed the CLI (npm, yarn, pnpm, bun, cnpm, utoo) and runs the appropriate upgrade command. If detection fails, it suggests the manual command. 12. 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: This provides 8 tools ( antd list , antd info , antd doc , antd demo , antd token , antd design md , antd semantic , antd changelog ) and 2 prompts ( antd expert , antd page generator ) via MCP protocol. Global Flags Flag Purpose format <format Output format: json , text , or markdown (agents should prefer json ) 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) V, cli version Print CLI version and exit Key Rules 1. Always query before writing — Don't guess antd APIs from memory. Run antd info first. 2. Match the user's version — Knowledge queries ( list/info/doc/demo/token/semantic/changelog ) support antd v4+. If the project uses antd 4.x/5.x/6.x, pass version 4.24.0 / 5.24.0 / 6.x . For antd v3 projects, use antd migrate 3 4 first. 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 the user asks to report an antd bug, use antd bug . Always preview first, get user confirmation, then submit. 7. Report CLI issues — When the user asks about a CLI problem, use antd bug cli to help them file a report. Always preview first, get user confirmation, then submit.