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. 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 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. 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 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): 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. Reporting antd bugs When you encounter a confirmed antd component bug that can't be resolved locally: 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: 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: 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: 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.