{"owner":"ant-design","repo":"ant-design-pro","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":5159,"categories":["anthropic-skill","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".claude/skills/antd/SKILL.md",".claude/skills/pro-upgrade/SKILL.md","CLAUDE.md"],"skills":{".claude/skills/antd/SKILL.md":"---\nname: antd\ndescription: >\n  Use when the user's task involves Ant Design (antd) — writing antd components,\n  debugging antd issues, querying antd APIs/props/tokens/demos, migrating between\n  antd versions, or analyzing antd usage in a project. Triggers on antd-related\n  code, imports from 'antd', or explicit antd questions.\nallowed-tools:\n  - Bash(antd *)\n  - Bash(antd bug*)\n  - Bash(antd bug-cli*)\n  - Bash(npx antd *)\n  - Bash(npx antd bug*)\n  - Bash(npx antd bug-cli*)\n---\n\n# Ant Design CLI\n\nYou have access to `@ant-design/cli` — a local CLI tool with bundled antd metadata for v3/v4/v5/v6. Use it to query component knowledge, analyze projects, and guide migrations. All data is offline, no network needed.\n\n## Setup\n\nThe CLI is installed as a dev dependency. Use `npx antd` to run it.\n\n**Always use `--format json` for structured output you can parse programmatically.**\n\n## Scenarios\n\n### 1. Writing antd component code\n\nBefore writing any antd component code, look up its API first — don't rely on memory.\n\n```bash\n# Check what props are available\nnpx antd info Button --format json\n\n# Get a working demo as starting point\nnpx antd demo Button basic --format json\n\n# Check semantic classNames/styles for custom styling\nnpx antd semantic Button --format json\n\n# Check component-level design tokens for theming\nnpx antd token Button --format json\n```\n\n**Workflow:** `antd info` → understand props → `antd demo` → grab a working example → write code.\n\n### 2. Looking up full documentation\n\nWhen you need comprehensive component docs (not just props):\n\n```bash\nnpx antd doc Table --format json        # full markdown docs for Table\nnpx antd doc Table --lang zh            # Chinese docs\n```\n\n### 3. Debugging antd issues\n\nWhen code isn't working as expected or the user reports an antd bug:\n\n```bash\n# Collect full environment snapshot (system, deps, browsers, build tools)\nnpx antd env --format json\n\n# Check if the prop exists for the user's antd version\nnpx antd info Select --version 5.12.0 --format json\n\n# Check if the prop is deprecated\nnpx antd lint ./src/components/MyForm.tsx --format json\n\n# Diagnose project-level configuration issues\nnpx antd doctor --format json\n```\n\n**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.\n\n### 4. Migrating between versions\n\nWhen the user wants to upgrade antd (e.g., v3 → v4 or v4 → v5):\n\n```bash\n# Get full migration checklist\nnpx antd migrate 3 4 --format json    # v3 → v4\nnpx antd migrate 4 5 --format json    # v4 → v5\n\n# Check migration for a specific component\nnpx antd migrate 4 5 --component Select --format json\n\n# See what changed between two versions\nnpx antd changelog 4.24.0 5.0.0 --format json\n\n# See changes for a specific component\nnpx antd changelog 4.24.0 5.0.0 Select --format json\n```\n\n**Workflow:** `antd migrate` → get full checklist → `antd changelog <v1> <v2>` → understand breaking changes → apply fixes → `antd lint` → verify no deprecated usage remains.\n\n### 5. Analyzing project antd usage\n\nWhen the user wants to understand how antd is used in their project:\n\n```bash\n# Scan component usage statistics\nnpx antd usage ./src --format json\n\n# Filter to a specific component\nnpx antd usage ./src --filter Form --format json\n\n# Lint for best practice violations\nnpx antd lint ./src --format json\n\n# Check only specific rule categories\nnpx antd lint ./src --only deprecated --format json\nnpx antd lint ./src --only a11y --format json\nnpx antd lint ./src --only performance --format json\n```\n\n### 6. Checking changelogs and version history\n\nWhen the user asks about what changed in a version:\n\n```bash\n# Specific version changelog\nnpx antd changelog 5.22.0 --format json\n\n# Version range (both ends inclusive)\nnpx antd changelog 5.21.0..5.24.0 --format json\n```\n\n### 7. Exploring available components\n\nWhen the user is choosing which component to use:\n\n```bash\n# List all components with categories\nnpx antd list --format json\n\n# List components for a specific antd version\nnpx antd list --version 5.0.0 --format json\n```\n\n### 8. Collecting environment info\n\nWhen you need to understand the project's antd setup, or prepare info for a bug report:\n\n```bash\n# Full environment snapshot (text — paste into GitHub Issues)\nnpx antd env\n\n# Structured JSON for programmatic use\nnpx antd env --format json\n\n# Scan a specific project directory\nnpx antd env ./my-project --format json\n```\n\n### 9. Reporting antd bugs\n\nWhen the user asks you to report an antd bug:\n\n```bash\n# Step 0: Collect environment info for reference (optional)\nnpx antd env --format json\n\n# Step 1: Preview for user review\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --format json\n\n# Step 2: Show to user, ask for confirmation\n\n# Step 3: Submit after user confirms\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --submit\n```\n\n### 10. Reporting CLI issues\n\nWhen the user asks to report a CLI bug:\n\n```bash\nnpx antd bug-cli --title \"antd info Button returns wrong props\" \\\n  --description \"When querying Button props for version 5.12.0, the output includes props that don't exist\" \\\n  --steps \"1. Run: npx antd info Button --version 5.12.0 --format json\" \\\n  --expected \"Props matching antd 5.12.0 Button API\" \\\n  --actual \"Props include 'classNames' which was added in 5.16.0\" \\\n  --format json\n```\n\nShow the report to the user and confirm before submitting with `--submit`.\n\n**Opt-out:** If the environment variable `ANTD_NO_AUTO_REPORT=1` is set, skip all bug-reporting suggestions entirely.\n\n### 11. Using as MCP server\n\nIf working in an IDE that supports MCP (Claude Desktop, Cursor, etc.), the CLI can also run as an MCP server:\n\n```json\n{\n  \"mcpServers\": {\n    \"antd\": {\n      \"command\": \"npx\",\n      \"args\": [\"antd\", \"mcp\"]\n    }\n  }\n}\n```\n\nThis 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.\n\n## Global Flags\n\n| Flag | Purpose |\n|---|---|\n| `--format json` | Structured output — always use this |\n| `--version <v>` | Target a specific antd version (e.g. `5.20.0`) |\n| `--lang zh` | Chinese output (default: `en`) |\n| `--detail` | Include extra fields (description, since, deprecated, FAQ) |\n\n## Key Rules\n\n1. **Always query before writing** — Don't guess antd APIs from memory. Run `antd info` first.\n2. **Match the user's version** — This project uses antd v6. The CLI auto-detects from `node_modules` if no flag is given.\n3. **Use `--format json`** — Every command supports it. Parse the JSON output rather than regex-matching text output.\n4. **Check before suggesting migration** — Run `antd changelog <v1> <v2>` and `antd migrate` before advising on version upgrades.\n5. **Lint after changes** — After writing or modifying antd code, run `antd lint` on the changed files to catch deprecated or problematic usage.\n6. **Report antd bugs** — When the user asks to report an antd bug, use `antd bug`. Always preview first, get user confirmation, then submit.\n7. **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.",".claude/skills/pro-upgrade/SKILL.md":"---\nname: pro-upgrade\ndescription: >\n  Use when the user wants to upgrade their Ant Design Pro project to the latest version.\n  Triggers on: upgrade pro, pro upgrade, migrate pro, update pro, 升级, 迁移项目,\n  \"how to upgrade\", \"update to latest\", \"keep project up to date\".\nallowed-tools:\n  - Bash(git clone *)\n  - Bash(diff *)\n  - Bash(npm install)\n  - Bash(npm run lint*)\n  - Bash(npm run build*)\n  - Bash(npm run tsc*)\n  - Bash(npx antd *)\n  - Bash(rm -rf /tmp/ant-design-pro-upgrade*)\n  - Read\n  - Edit\n  - Write\n  - Glob\n  - Grep\n---\n\n# Ant Design Pro Upgrade Skill\n\nYou are an Ant Design Pro upgrade assistant. Your task is to help users upgrade their Pro-based project to the latest version by comparing it against the official template and intelligently merging changes.\n\n## Preflight\n\nBefore starting, confirm:\n\n1. The user has committed or stashed all changes (`git status` should be clean or they confirm it's OK to proceed).\n2. If not clean, remind them to commit or stash their changes first (e.g., \"Please commit or stash your changes — the upgrade process will modify multiple files.\") and wait for them to confirm.\n\n## Upgrade Flow\n\n### Step 1 — Fetch the latest template\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\ngit clone --depth=1 https://github.com/ant-design/ant-design-pro.git /tmp/ant-design-pro-upgrade\n```\n\nRead the template's `package.json` to confirm its version.\n\n### Step 2 — Classify files\n\nSeparate the user's project files into **framework files** (Pro-owned, rarely customized) and **business files** (user-written, must be preserved).\n\n**Framework files** — diff these against the template:\n\n| Path | Notes |\n|---|---|\n| `package.json` | dependencies, scripts, devDependencies only |\n| `config/config.ts` | framework config |\n| `config/routes.ts` | structure only — preserve user-added routes |\n| `config/defaultSettings.ts` | layout/theme defaults |\n| `config/proxy.ts` | structure only — preserve user targets |\n| `src/app.tsx` | runtime config |\n| `src/access.ts` | permission definitions |\n| `src/global.tsx` | global side effects |\n| `src/loading.tsx` | loading component |\n| `src/requestErrorConfig.ts` | request interceptor |\n| `src/typings.d.ts` | global type declarations |\n| `tsconfig.json` | TypeScript config |\n| `biome.json` or `biome.jsonc` | linter config |\n| `.husky/` | git hooks |\n| `commitlint.config.*` | commit lint config |\n| `src/services/ant-design-pro/` | auto-generated — do NOT manually edit; regenerate with `npm run openapi` |\n\n**Business files** — preserve these, only adjust imports/APIs if needed:\n\n- `src/pages/**` — user pages\n- `src/components/**` — user components\n- `src/models/**` — user models\n- `src/services/**/*.ts` — custom service files (NOT the `ant-design-pro/` subdirectory)\n- `src/locales/**` — user translations (framework keys may need updating)\n- `src/utils/**` — user utilities\n- `mock/**` — user mocks\n- Any other files not listed above\n\n### Step 3 — Diff framework files\n\nFor each framework file, read both the user's version and the template version. Identify:\n\n- **New dependencies** or version bumps in `package.json`\n- **New/changed config options** in `config/` files\n- **Import path changes** (e.g., `from 'umi'` → `from '@umijs/max'`)\n- **API changes** in `src/app.tsx`, `src/access.ts`, etc.\n- **New files** that exist in template but not in user's project\n\n### Step 4 — Merge intelligently\n\nApply changes with these rules:\n\n**Framework files — adopt template structure, preserve user customizations:**\n- `package.json`: update dependency versions to match template. Keep any extra deps the user added. If a dependency exists in the user's project but not in the template, assume it is a user customization and preserve it.\n- `config/routes.ts`: adopt the template's route structure for framework pages, but keep all user-added routes intact.\n- `config/proxy.ts`: adopt structure, preserve user's proxy targets.\n- Other framework files: adopt the template version, preserving any user customizations that are clearly intentional (comments, extra exports, business logic mixed in).\n\n**Business files — minimal changes only:**\n- Update import paths if framework modules moved (e.g., `'umi'` → `'@umijs/max'`).\n- Update deprecated API calls if the template shows a new pattern.\n- Never rewrite business logic, restructure components, or change styling approaches unless the old approach is broken.\n\n**Auto-generated files:**\n- `src/services/ant-design-pro/`: do NOT edit. Tell the user to run `npm run openapi` after upgrade.\n\n### Step 5 — Antd-specific migration checks\n\nRun these commands to catch antd API changes:\n\n```bash\nnpx antd env --format json\nnpx antd lint ./src --format json --only deprecated\n```\n\nIf the user is upgrading across major antd versions, also run:\n\n```bash\nnpx antd migrate <current_major> <target_major> --format json\n```\n\nDetect the current major version from the user's `package.json` and the target from the template's.\n\nAddress any findings by updating the flagged code.\n\n### Step 6 — Install and verify\n\n```bash\nnpm install\nnpm run lint\nnpm run build\n```\n\nFix any errors. Common post-upgrade issues:\n- Type errors from changed APIs → check `npx antd info <Component>` for current APIs\n- New lint rules from Biome config changes → run `npm run biome` to auto-fix\n- Missing peer dependencies → check `npm install` warnings\n\n### Step 7 — Cleanup and summarize\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\n```\n\nOutput a summary of all changes made, grouped by category:\n\n1. **Dependencies updated** — list version changes\n2. **Config changes** — what changed in config files\n3. **Code patterns migrated** — import path changes, API updates\n4. **New files added** — any files from the template that didn't exist before\n5. **Manual review needed** — anything you're unsure about or that requires user action\n\nRemind the user to:\n- Run `npm run openapi` if they use the auto-generated API services\n- Test their application thoroughly\n- Commit the changes\n\n## Key Principles\n\n- **No hardcoded versions** — this skill works regardless of the version gap between the user's project and the latest template.\n- **Preserve business code** — only modify what's necessary for framework compatibility.\n- **Conservative merging** — when uncertain whether a change is a user customization or an outdated pattern, ask the user instead of guessing.\n- **Leverage `@ant-design/cli`** — use `antd migrate`, `antd lint`, `antd info` for antd-specific checks; don't guess APIs from memory.\n- **Clean up** — always remove the temporary clone directory.","CLAUDE.md":"# CLAUDE.md\n\n## Project\n\nAnt Design Pro — React enterprise boilerplate on Umi Max v4, antd v6, ProComponents v3.\n\n## Commands\n\n`npm start` (dev+mock), `npm run dev` (no mock), `npm run build` (utoopack), `npm run lint` (Biome+tsc), `npm run test` (Jest), `npx antd lint ./src` (antd-specific checks).\n\nOther: `npm run openapi` (regenerate `src/services/`), `npm run simple` (**irreversible** — commit first), `npm run biome` (auto-fix), `npm run tsc` (type-check only).\n\n## Critical Rules\n\n- **Never edit `src/services/ant-design-pro/`** — auto-generated, regenerate with `npm run openapi`\n- **Biome only** — no ESLint, no Prettier. Both `npm run lint` and `npx antd lint ./src` must pass before commit\n- **Always `npx antd info <Component>` before writing antd code** — don't guess APIs from memory\n- **`npm run simple` is irreversible** — always commit/branch first\n- **Conventional commits** required (commitlint enforced)\n- **TypeScript strict** · **Node ≥ 22** · **`package-lock.json`** (not yarn/pnpm)\n- **`.umi` dir is auto-generated** — delete `src/.umi` and restart if dev server acts up\n\n## Architecture Essentials\n\n**Config**: `config/config.ts` (defineConfig), `config/routes.ts` (declarative routes). Route `name` → `menu.xxx` i18n key; `access` field gates visibility.\n\n**Convention files** (`src/`): `app.tsx` (runtime config + `getInitialState`), `access.ts` (permissions), `global.tsx` (side effects), `loading.tsx`, `typings.d.ts`.\n\n**Auth**: `getInitialState()` → `GET /api/currentUser`; 401 → redirect login. `access.ts`: `canAdmin = currentUser.access === 'admin'`. Mock creds: `admin`/`ant.design` or `user`/`ant.design`.\n\n**State**: `useModel('filename')` for global hooks (`src/models/`). `useModel('@@initialState')` for currentUser/settings. ProTable `request` prop for most data loading. `@tanstack/react-query` for complex server state.\n\n**Styling priority**: Tailwind CSS v4 (layout) → antd-style v4 / `createStyles` (theme tokens) → CSS Modules → Less (legacy only).\n\n**Request**: built-in `request` from `@umijs/max`, configured in `src/requestErrorConfig.ts`. Per-page `service.ts` for non-generated APIs.\n\n**i18n**: 8 locales in `src/locales/`. `useIntl().formatMessage({ id, defaultMessage })`.\n\n**Mock**: `mock/` (global) + `src/pages/**/_mock.ts` (co-located). Express-style handlers.\n\n**Cloudflare Worker**: `cloudflare-worker/` — separate Hono app, own `package.json`, not an npm workspace.\n\n## AI Skills\n\nThis project ships with two built-in Claude Code Skills (`.claude/skills/`). If you already have these skills in your project, no installation is needed — just run them directly. To update to the latest skill definitions, run `npx skills add ant-design/ant-design-pro`.\n\n### `/pro-upgrade` — Project Upgrade\n\nRun `/pro-upgrade` in Claude Code to auto-upgrade the project to the latest Ant Design Pro version. It diffs the latest template against this project and merges framework changes while preserving business code. Works for any version gap (v5→v6, v6.x→latest, etc.).\n\n### `/antd` — Ant Design CLI\n\nRun `/antd` in Claude Code for any antd-related work. It provides access to `@ant-design/cli` with offline metadata for antd v3/v4/v5/v6. Key commands:\n\n- `npx antd info <Component>` — look up props/API before writing code (mandatory)\n- `npx antd lint ./src` — check for deprecated or problematic usage (must pass before commit)\n- `npx antd demo <Component> <demo>` — get working code examples\n- `npx antd migrate <from> <to>` — migration checklist between major versions\n\n## Page Co-location\n\nEach page dir: `index.tsx`, optional `service.ts`, `_mock.ts`, `data.d.ts`, style files. Keep page-specific code with the page.\n\n# CLAUDE.md\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n\n---"},"files":{".claude/skills/antd/SKILL.md":"---\nname: antd\ndescription: >\n  Use when the user's task involves Ant Design (antd) — writing antd components,\n  debugging antd issues, querying antd APIs/props/tokens/demos, migrating between\n  antd versions, or analyzing antd usage in a project. Triggers on antd-related\n  code, imports from 'antd', or explicit antd questions.\nallowed-tools:\n  - Bash(antd *)\n  - Bash(antd bug*)\n  - Bash(antd bug-cli*)\n  - Bash(npx antd *)\n  - Bash(npx antd bug*)\n  - Bash(npx antd bug-cli*)\n---\n\n# Ant Design CLI\n\nYou have access to `@ant-design/cli` — a local CLI tool with bundled antd metadata for v3/v4/v5/v6. Use it to query component knowledge, analyze projects, and guide migrations. All data is offline, no network needed.\n\n## Setup\n\nThe CLI is installed as a dev dependency. Use `npx antd` to run it.\n\n**Always use `--format json` for structured output you can parse programmatically.**\n\n## Scenarios\n\n### 1. Writing antd component code\n\nBefore writing any antd component code, look up its API first — don't rely on memory.\n\n```bash\n# Check what props are available\nnpx antd info Button --format json\n\n# Get a working demo as starting point\nnpx antd demo Button basic --format json\n\n# Check semantic classNames/styles for custom styling\nnpx antd semantic Button --format json\n\n# Check component-level design tokens for theming\nnpx antd token Button --format json\n```\n\n**Workflow:** `antd info` → understand props → `antd demo` → grab a working example → write code.\n\n### 2. Looking up full documentation\n\nWhen you need comprehensive component docs (not just props):\n\n```bash\nnpx antd doc Table --format json        # full markdown docs for Table\nnpx antd doc Table --lang zh            # Chinese docs\n```\n\n### 3. Debugging antd issues\n\nWhen code isn't working as expected or the user reports an antd bug:\n\n```bash\n# Collect full environment snapshot (system, deps, browsers, build tools)\nnpx antd env --format json\n\n# Check if the prop exists for the user's antd version\nnpx antd info Select --version 5.12.0 --format json\n\n# Check if the prop is deprecated\nnpx antd lint ./src/components/MyForm.tsx --format json\n\n# Diagnose project-level configuration issues\nnpx antd doctor --format json\n```\n\n**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.\n\n### 4. Migrating between versions\n\nWhen the user wants to upgrade antd (e.g., v3 → v4 or v4 → v5):\n\n```bash\n# Get full migration checklist\nnpx antd migrate 3 4 --format json    # v3 → v4\nnpx antd migrate 4 5 --format json    # v4 → v5\n\n# Check migration for a specific component\nnpx antd migrate 4 5 --component Select --format json\n\n# See what changed between two versions\nnpx antd changelog 4.24.0 5.0.0 --format json\n\n# See changes for a specific component\nnpx antd changelog 4.24.0 5.0.0 Select --format json\n```\n\n**Workflow:** `antd migrate` → get full checklist → `antd changelog <v1> <v2>` → understand breaking changes → apply fixes → `antd lint` → verify no deprecated usage remains.\n\n### 5. Analyzing project antd usage\n\nWhen the user wants to understand how antd is used in their project:\n\n```bash\n# Scan component usage statistics\nnpx antd usage ./src --format json\n\n# Filter to a specific component\nnpx antd usage ./src --filter Form --format json\n\n# Lint for best practice violations\nnpx antd lint ./src --format json\n\n# Check only specific rule categories\nnpx antd lint ./src --only deprecated --format json\nnpx antd lint ./src --only a11y --format json\nnpx antd lint ./src --only performance --format json\n```\n\n### 6. Checking changelogs and version history\n\nWhen the user asks about what changed in a version:\n\n```bash\n# Specific version changelog\nnpx antd changelog 5.22.0 --format json\n\n# Version range (both ends inclusive)\nnpx antd changelog 5.21.0..5.24.0 --format json\n```\n\n### 7. Exploring available components\n\nWhen the user is choosing which component to use:\n\n```bash\n# List all components with categories\nnpx antd list --format json\n\n# List components for a specific antd version\nnpx antd list --version 5.0.0 --format json\n```\n\n### 8. Collecting environment info\n\nWhen you need to understand the project's antd setup, or prepare info for a bug report:\n\n```bash\n# Full environment snapshot (text — paste into GitHub Issues)\nnpx antd env\n\n# Structured JSON for programmatic use\nnpx antd env --format json\n\n# Scan a specific project directory\nnpx antd env ./my-project --format json\n```\n\n### 9. Reporting antd bugs\n\nWhen the user asks you to report an antd bug:\n\n```bash\n# Step 0: Collect environment info for reference (optional)\nnpx antd env --format json\n\n# Step 1: Preview for user review\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --format json\n\n# Step 2: Show to user, ask for confirmation\n\n# Step 3: Submit after user confirms\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --submit\n```\n\n### 10. Reporting CLI issues\n\nWhen the user asks to report a CLI bug:\n\n```bash\nnpx antd bug-cli --title \"antd info Button returns wrong props\" \\\n  --description \"When querying Button props for version 5.12.0, the output includes props that don't exist\" \\\n  --steps \"1. Run: npx antd info Button --version 5.12.0 --format json\" \\\n  --expected \"Props matching antd 5.12.0 Button API\" \\\n  --actual \"Props include 'classNames' which was added in 5.16.0\" \\\n  --format json\n```\n\nShow the report to the user and confirm before submitting with `--submit`.\n\n**Opt-out:** If the environment variable `ANTD_NO_AUTO_REPORT=1` is set, skip all bug-reporting suggestions entirely.\n\n### 11. Using as MCP server\n\nIf working in an IDE that supports MCP (Claude Desktop, Cursor, etc.), the CLI can also run as an MCP server:\n\n```json\n{\n  \"mcpServers\": {\n    \"antd\": {\n      \"command\": \"npx\",\n      \"args\": [\"antd\", \"mcp\"]\n    }\n  }\n}\n```\n\nThis 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.\n\n## Global Flags\n\n| Flag | Purpose |\n|---|---|\n| `--format json` | Structured output — always use this |\n| `--version <v>` | Target a specific antd version (e.g. `5.20.0`) |\n| `--lang zh` | Chinese output (default: `en`) |\n| `--detail` | Include extra fields (description, since, deprecated, FAQ) |\n\n## Key Rules\n\n1. **Always query before writing** — Don't guess antd APIs from memory. Run `antd info` first.\n2. **Match the user's version** — This project uses antd v6. The CLI auto-detects from `node_modules` if no flag is given.\n3. **Use `--format json`** — Every command supports it. Parse the JSON output rather than regex-matching text output.\n4. **Check before suggesting migration** — Run `antd changelog <v1> <v2>` and `antd migrate` before advising on version upgrades.\n5. **Lint after changes** — After writing or modifying antd code, run `antd lint` on the changed files to catch deprecated or problematic usage.\n6. **Report antd bugs** — When the user asks to report an antd bug, use `antd bug`. Always preview first, get user confirmation, then submit.\n7. **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.",".claude/skills/pro-upgrade/SKILL.md":"---\nname: pro-upgrade\ndescription: >\n  Use when the user wants to upgrade their Ant Design Pro project to the latest version.\n  Triggers on: upgrade pro, pro upgrade, migrate pro, update pro, 升级, 迁移项目,\n  \"how to upgrade\", \"update to latest\", \"keep project up to date\".\nallowed-tools:\n  - Bash(git clone *)\n  - Bash(diff *)\n  - Bash(npm install)\n  - Bash(npm run lint*)\n  - Bash(npm run build*)\n  - Bash(npm run tsc*)\n  - Bash(npx antd *)\n  - Bash(rm -rf /tmp/ant-design-pro-upgrade*)\n  - Read\n  - Edit\n  - Write\n  - Glob\n  - Grep\n---\n\n# Ant Design Pro Upgrade Skill\n\nYou are an Ant Design Pro upgrade assistant. Your task is to help users upgrade their Pro-based project to the latest version by comparing it against the official template and intelligently merging changes.\n\n## Preflight\n\nBefore starting, confirm:\n\n1. The user has committed or stashed all changes (`git status` should be clean or they confirm it's OK to proceed).\n2. If not clean, remind them to commit or stash their changes first (e.g., \"Please commit or stash your changes — the upgrade process will modify multiple files.\") and wait for them to confirm.\n\n## Upgrade Flow\n\n### Step 1 — Fetch the latest template\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\ngit clone --depth=1 https://github.com/ant-design/ant-design-pro.git /tmp/ant-design-pro-upgrade\n```\n\nRead the template's `package.json` to confirm its version.\n\n### Step 2 — Classify files\n\nSeparate the user's project files into **framework files** (Pro-owned, rarely customized) and **business files** (user-written, must be preserved).\n\n**Framework files** — diff these against the template:\n\n| Path | Notes |\n|---|---|\n| `package.json` | dependencies, scripts, devDependencies only |\n| `config/config.ts` | framework config |\n| `config/routes.ts` | structure only — preserve user-added routes |\n| `config/defaultSettings.ts` | layout/theme defaults |\n| `config/proxy.ts` | structure only — preserve user targets |\n| `src/app.tsx` | runtime config |\n| `src/access.ts` | permission definitions |\n| `src/global.tsx` | global side effects |\n| `src/loading.tsx` | loading component |\n| `src/requestErrorConfig.ts` | request interceptor |\n| `src/typings.d.ts` | global type declarations |\n| `tsconfig.json` | TypeScript config |\n| `biome.json` or `biome.jsonc` | linter config |\n| `.husky/` | git hooks |\n| `commitlint.config.*` | commit lint config |\n| `src/services/ant-design-pro/` | auto-generated — do NOT manually edit; regenerate with `npm run openapi` |\n\n**Business files** — preserve these, only adjust imports/APIs if needed:\n\n- `src/pages/**` — user pages\n- `src/components/**` — user components\n- `src/models/**` — user models\n- `src/services/**/*.ts` — custom service files (NOT the `ant-design-pro/` subdirectory)\n- `src/locales/**` — user translations (framework keys may need updating)\n- `src/utils/**` — user utilities\n- `mock/**` — user mocks\n- Any other files not listed above\n\n### Step 3 — Diff framework files\n\nFor each framework file, read both the user's version and the template version. Identify:\n\n- **New dependencies** or version bumps in `package.json`\n- **New/changed config options** in `config/` files\n- **Import path changes** (e.g., `from 'umi'` → `from '@umijs/max'`)\n- **API changes** in `src/app.tsx`, `src/access.ts`, etc.\n- **New files** that exist in template but not in user's project\n\n### Step 4 — Merge intelligently\n\nApply changes with these rules:\n\n**Framework files — adopt template structure, preserve user customizations:**\n- `package.json`: update dependency versions to match template. Keep any extra deps the user added. If a dependency exists in the user's project but not in the template, assume it is a user customization and preserve it.\n- `config/routes.ts`: adopt the template's route structure for framework pages, but keep all user-added routes intact.\n- `config/proxy.ts`: adopt structure, preserve user's proxy targets.\n- Other framework files: adopt the template version, preserving any user customizations that are clearly intentional (comments, extra exports, business logic mixed in).\n\n**Business files — minimal changes only:**\n- Update import paths if framework modules moved (e.g., `'umi'` → `'@umijs/max'`).\n- Update deprecated API calls if the template shows a new pattern.\n- Never rewrite business logic, restructure components, or change styling approaches unless the old approach is broken.\n\n**Auto-generated files:**\n- `src/services/ant-design-pro/`: do NOT edit. Tell the user to run `npm run openapi` after upgrade.\n\n### Step 5 — Antd-specific migration checks\n\nRun these commands to catch antd API changes:\n\n```bash\nnpx antd env --format json\nnpx antd lint ./src --format json --only deprecated\n```\n\nIf the user is upgrading across major antd versions, also run:\n\n```bash\nnpx antd migrate <current_major> <target_major> --format json\n```\n\nDetect the current major version from the user's `package.json` and the target from the template's.\n\nAddress any findings by updating the flagged code.\n\n### Step 6 — Install and verify\n\n```bash\nnpm install\nnpm run lint\nnpm run build\n```\n\nFix any errors. Common post-upgrade issues:\n- Type errors from changed APIs → check `npx antd info <Component>` for current APIs\n- New lint rules from Biome config changes → run `npm run biome` to auto-fix\n- Missing peer dependencies → check `npm install` warnings\n\n### Step 7 — Cleanup and summarize\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\n```\n\nOutput a summary of all changes made, grouped by category:\n\n1. **Dependencies updated** — list version changes\n2. **Config changes** — what changed in config files\n3. **Code patterns migrated** — import path changes, API updates\n4. **New files added** — any files from the template that didn't exist before\n5. **Manual review needed** — anything you're unsure about or that requires user action\n\nRemind the user to:\n- Run `npm run openapi` if they use the auto-generated API services\n- Test their application thoroughly\n- Commit the changes\n\n## Key Principles\n\n- **No hardcoded versions** — this skill works regardless of the version gap between the user's project and the latest template.\n- **Preserve business code** — only modify what's necessary for framework compatibility.\n- **Conservative merging** — when uncertain whether a change is a user customization or an outdated pattern, ask the user instead of guessing.\n- **Leverage `@ant-design/cli`** — use `antd migrate`, `antd lint`, `antd info` for antd-specific checks; don't guess APIs from memory.\n- **Clean up** — always remove the temporary clone directory.","CLAUDE.md":"# CLAUDE.md\n\n## Project\n\nAnt Design Pro — React enterprise boilerplate on Umi Max v4, antd v6, ProComponents v3.\n\n## Commands\n\n`npm start` (dev+mock), `npm run dev` (no mock), `npm run build` (utoopack), `npm run lint` (Biome+tsc), `npm run test` (Jest), `npx antd lint ./src` (antd-specific checks).\n\nOther: `npm run openapi` (regenerate `src/services/`), `npm run simple` (**irreversible** — commit first), `npm run biome` (auto-fix), `npm run tsc` (type-check only).\n\n## Critical Rules\n\n- **Never edit `src/services/ant-design-pro/`** — auto-generated, regenerate with `npm run openapi`\n- **Biome only** — no ESLint, no Prettier. Both `npm run lint` and `npx antd lint ./src` must pass before commit\n- **Always `npx antd info <Component>` before writing antd code** — don't guess APIs from memory\n- **`npm run simple` is irreversible** — always commit/branch first\n- **Conventional commits** required (commitlint enforced)\n- **TypeScript strict** · **Node ≥ 22** · **`package-lock.json`** (not yarn/pnpm)\n- **`.umi` dir is auto-generated** — delete `src/.umi` and restart if dev server acts up\n\n## Architecture Essentials\n\n**Config**: `config/config.ts` (defineConfig), `config/routes.ts` (declarative routes). Route `name` → `menu.xxx` i18n key; `access` field gates visibility.\n\n**Convention files** (`src/`): `app.tsx` (runtime config + `getInitialState`), `access.ts` (permissions), `global.tsx` (side effects), `loading.tsx`, `typings.d.ts`.\n\n**Auth**: `getInitialState()` → `GET /api/currentUser`; 401 → redirect login. `access.ts`: `canAdmin = currentUser.access === 'admin'`. Mock creds: `admin`/`ant.design` or `user`/`ant.design`.\n\n**State**: `useModel('filename')` for global hooks (`src/models/`). `useModel('@@initialState')` for currentUser/settings. ProTable `request` prop for most data loading. `@tanstack/react-query` for complex server state.\n\n**Styling priority**: Tailwind CSS v4 (layout) → antd-style v4 / `createStyles` (theme tokens) → CSS Modules → Less (legacy only).\n\n**Request**: built-in `request` from `@umijs/max`, configured in `src/requestErrorConfig.ts`. Per-page `service.ts` for non-generated APIs.\n\n**i18n**: 8 locales in `src/locales/`. `useIntl().formatMessage({ id, defaultMessage })`.\n\n**Mock**: `mock/` (global) + `src/pages/**/_mock.ts` (co-located). Express-style handlers.\n\n**Cloudflare Worker**: `cloudflare-worker/` — separate Hono app, own `package.json`, not an npm workspace.\n\n## AI Skills\n\nThis project ships with two built-in Claude Code Skills (`.claude/skills/`). If you already have these skills in your project, no installation is needed — just run them directly. To update to the latest skill definitions, run `npx skills add ant-design/ant-design-pro`.\n\n### `/pro-upgrade` — Project Upgrade\n\nRun `/pro-upgrade` in Claude Code to auto-upgrade the project to the latest Ant Design Pro version. It diffs the latest template against this project and merges framework changes while preserving business code. Works for any version gap (v5→v6, v6.x→latest, etc.).\n\n### `/antd` — Ant Design CLI\n\nRun `/antd` in Claude Code for any antd-related work. It provides access to `@ant-design/cli` with offline metadata for antd v3/v4/v5/v6. Key commands:\n\n- `npx antd info <Component>` — look up props/API before writing code (mandatory)\n- `npx antd lint ./src` — check for deprecated or problematic usage (must pass before commit)\n- `npx antd demo <Component> <demo>` — get working code examples\n- `npx antd migrate <from> <to>` — migration checklist between major versions\n\n## Page Co-location\n\nEach page dir: `index.tsx`, optional `service.ts`, `_mock.ts`, `data.d.ts`, style files. Keep page-specific code with the page.\n\n# CLAUDE.md\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n\n---"},"items":[{"name":"SKILL.md","path":".claude/skills/antd/SKILL.md","rawUrl":"https://raw.githubusercontent.com/ant-design/ant-design-pro/HEAD/.claude/skills/antd/SKILL.md","title":"antd","category":"anthropic-skill","format":"markdown","content":"---\nname: antd\ndescription: >\n  Use when the user's task involves Ant Design (antd) — writing antd components,\n  debugging antd issues, querying antd APIs/props/tokens/demos, migrating between\n  antd versions, or analyzing antd usage in a project. Triggers on antd-related\n  code, imports from 'antd', or explicit antd questions.\nallowed-tools:\n  - Bash(antd *)\n  - Bash(antd bug*)\n  - Bash(antd bug-cli*)\n  - Bash(npx antd *)\n  - Bash(npx antd bug*)\n  - Bash(npx antd bug-cli*)\n---\n\n# Ant Design CLI\n\nYou have access to `@ant-design/cli` — a local CLI tool with bundled antd metadata for v3/v4/v5/v6. Use it to query component knowledge, analyze projects, and guide migrations. All data is offline, no network needed.\n\n## Setup\n\nThe CLI is installed as a dev dependency. Use `npx antd` to run it.\n\n**Always use `--format json` for structured output you can parse programmatically.**\n\n## Scenarios\n\n### 1. Writing antd component code\n\nBefore writing any antd component code, look up its API first — don't rely on memory.\n\n```bash\n# Check what props are available\nnpx antd info Button --format json\n\n# Get a working demo as starting point\nnpx antd demo Button basic --format json\n\n# Check semantic classNames/styles for custom styling\nnpx antd semantic Button --format json\n\n# Check component-level design tokens for theming\nnpx antd token Button --format json\n```\n\n**Workflow:** `antd info` → understand props → `antd demo` → grab a working example → write code.\n\n### 2. Looking up full documentation\n\nWhen you need comprehensive component docs (not just props):\n\n```bash\nnpx antd doc Table --format json        # full markdown docs for Table\nnpx antd doc Table --lang zh            # Chinese docs\n```\n\n### 3. Debugging antd issues\n\nWhen code isn't working as expected or the user reports an antd bug:\n\n```bash\n# Collect full environment snapshot (system, deps, browsers, build tools)\nnpx antd env --format json\n\n# Check if the prop exists for the user's antd version\nnpx antd info Select --version 5.12.0 --format json\n\n# Check if the prop is deprecated\nnpx antd lint ./src/components/MyForm.tsx --format json\n\n# Diagnose project-level configuration issues\nnpx antd doctor --format json\n```\n\n**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.\n\n### 4. Migrating between versions\n\nWhen the user wants to upgrade antd (e.g., v3 → v4 or v4 → v5):\n\n```bash\n# Get full migration checklist\nnpx antd migrate 3 4 --format json    # v3 → v4\nnpx antd migrate 4 5 --format json    # v4 → v5\n\n# Check migration for a specific component\nnpx antd migrate 4 5 --component Select --format json\n\n# See what changed between two versions\nnpx antd changelog 4.24.0 5.0.0 --format json\n\n# See changes for a specific component\nnpx antd changelog 4.24.0 5.0.0 Select --format json\n```\n\n**Workflow:** `antd migrate` → get full checklist → `antd changelog <v1> <v2>` → understand breaking changes → apply fixes → `antd lint` → verify no deprecated usage remains.\n\n### 5. Analyzing project antd usage\n\nWhen the user wants to understand how antd is used in their project:\n\n```bash\n# Scan component usage statistics\nnpx antd usage ./src --format json\n\n# Filter to a specific component\nnpx antd usage ./src --filter Form --format json\n\n# Lint for best practice violations\nnpx antd lint ./src --format json\n\n# Check only specific rule categories\nnpx antd lint ./src --only deprecated --format json\nnpx antd lint ./src --only a11y --format json\nnpx antd lint ./src --only performance --format json\n```\n\n### 6. Checking changelogs and version history\n\nWhen the user asks about what changed in a version:\n\n```bash\n# Specific version changelog\nnpx antd changelog 5.22.0 --format json\n\n# Version range (both ends inclusive)\nnpx antd changelog 5.21.0..5.24.0 --format json\n```\n\n### 7. Exploring available components\n\nWhen the user is choosing which component to use:\n\n```bash\n# List all components with categories\nnpx antd list --format json\n\n# List components for a specific antd version\nnpx antd list --version 5.0.0 --format json\n```\n\n### 8. Collecting environment info\n\nWhen you need to understand the project's antd setup, or prepare info for a bug report:\n\n```bash\n# Full environment snapshot (text — paste into GitHub Issues)\nnpx antd env\n\n# Structured JSON for programmatic use\nnpx antd env --format json\n\n# Scan a specific project directory\nnpx antd env ./my-project --format json\n```\n\n### 9. Reporting antd bugs\n\nWhen the user asks you to report an antd bug:\n\n```bash\n# Step 0: Collect environment info for reference (optional)\nnpx antd env --format json\n\n# Step 1: Preview for user review\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --format json\n\n# Step 2: Show to user, ask for confirmation\n\n# Step 3: Submit after user confirms\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --submit\n```\n\n### 10. Reporting CLI issues\n\nWhen the user asks to report a CLI bug:\n\n```bash\nnpx antd bug-cli --title \"antd info Button returns wrong props\" \\\n  --description \"When querying Button props for version 5.12.0, the output includes props that don't exist\" \\\n  --steps \"1. Run: npx antd info Button --version 5.12.0 --format json\" \\\n  --expected \"Props matching antd 5.12.0 Button API\" \\\n  --actual \"Props include 'classNames' which was added in 5.16.0\" \\\n  --format json\n```\n\nShow the report to the user and confirm before submitting with `--submit`.\n\n**Opt-out:** If the environment variable `ANTD_NO_AUTO_REPORT=1` is set, skip all bug-reporting suggestions entirely.\n\n### 11. Using as MCP server\n\nIf working in an IDE that supports MCP (Claude Desktop, Cursor, etc.), the CLI can also run as an MCP server:\n\n```json\n{\n  \"mcpServers\": {\n    \"antd\": {\n      \"command\": \"npx\",\n      \"args\": [\"antd\", \"mcp\"]\n    }\n  }\n}\n```\n\nThis 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.\n\n## Global Flags\n\n| Flag | Purpose |\n|---|---|\n| `--format json` | Structured output — always use this |\n| `--version <v>` | Target a specific antd version (e.g. `5.20.0`) |\n| `--lang zh` | Chinese output (default: `en`) |\n| `--detail` | Include extra fields (description, since, deprecated, FAQ) |\n\n## Key Rules\n\n1. **Always query before writing** — Don't guess antd APIs from memory. Run `antd info` first.\n2. **Match the user's version** — This project uses antd v6. The CLI auto-detects from `node_modules` if no flag is given.\n3. **Use `--format json`** — Every command supports it. Parse the JSON output rather than regex-matching text output.\n4. **Check before suggesting migration** — Run `antd changelog <v1> <v2>` and `antd migrate` before advising on version upgrades.\n5. **Lint after changes** — After writing or modifying antd code, run `antd lint` on the changed files to catch deprecated or problematic usage.\n6. **Report antd bugs** — When the user asks to report an antd bug, use `antd bug`. Always preview first, get user confirmation, then submit.\n7. **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.","frontmatter":{"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.\n","allowed-tools":["Bash(antd *)","Bash(antd bug*)","Bash(antd bug-cli*)","Bash(npx antd *)","Bash(npx antd bug*)","Bash(npx antd bug-cli*)"],"allowedTools":["Bash(antd *)","Bash(antd bug*)","Bash(antd bug-cli*)","Bash(npx antd *)","Bash(npx antd bug*)","Bash(npx antd bug-cli*)"]},"allowedTools":["Bash(antd *)","Bash(antd bug*)","Bash(antd bug-cli*)","Bash(npx antd *)","Bash(npx antd bug*)","Bash(npx antd bug-cli*)"],"isInternal":false,"tokens":2051,"sizeBytes":7744},{"name":"SKILL.md","path":".claude/skills/pro-upgrade/SKILL.md","rawUrl":"https://raw.githubusercontent.com/ant-design/ant-design-pro/HEAD/.claude/skills/pro-upgrade/SKILL.md","title":"pro-upgrade","category":"anthropic-skill","format":"markdown","content":"---\nname: pro-upgrade\ndescription: >\n  Use when the user wants to upgrade their Ant Design Pro project to the latest version.\n  Triggers on: upgrade pro, pro upgrade, migrate pro, update pro, 升级, 迁移项目,\n  \"how to upgrade\", \"update to latest\", \"keep project up to date\".\nallowed-tools:\n  - Bash(git clone *)\n  - Bash(diff *)\n  - Bash(npm install)\n  - Bash(npm run lint*)\n  - Bash(npm run build*)\n  - Bash(npm run tsc*)\n  - Bash(npx antd *)\n  - Bash(rm -rf /tmp/ant-design-pro-upgrade*)\n  - Read\n  - Edit\n  - Write\n  - Glob\n  - Grep\n---\n\n# Ant Design Pro Upgrade Skill\n\nYou are an Ant Design Pro upgrade assistant. Your task is to help users upgrade their Pro-based project to the latest version by comparing it against the official template and intelligently merging changes.\n\n## Preflight\n\nBefore starting, confirm:\n\n1. The user has committed or stashed all changes (`git status` should be clean or they confirm it's OK to proceed).\n2. If not clean, remind them to commit or stash their changes first (e.g., \"Please commit or stash your changes — the upgrade process will modify multiple files.\") and wait for them to confirm.\n\n## Upgrade Flow\n\n### Step 1 — Fetch the latest template\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\ngit clone --depth=1 https://github.com/ant-design/ant-design-pro.git /tmp/ant-design-pro-upgrade\n```\n\nRead the template's `package.json` to confirm its version.\n\n### Step 2 — Classify files\n\nSeparate the user's project files into **framework files** (Pro-owned, rarely customized) and **business files** (user-written, must be preserved).\n\n**Framework files** — diff these against the template:\n\n| Path | Notes |\n|---|---|\n| `package.json` | dependencies, scripts, devDependencies only |\n| `config/config.ts` | framework config |\n| `config/routes.ts` | structure only — preserve user-added routes |\n| `config/defaultSettings.ts` | layout/theme defaults |\n| `config/proxy.ts` | structure only — preserve user targets |\n| `src/app.tsx` | runtime config |\n| `src/access.ts` | permission definitions |\n| `src/global.tsx` | global side effects |\n| `src/loading.tsx` | loading component |\n| `src/requestErrorConfig.ts` | request interceptor |\n| `src/typings.d.ts` | global type declarations |\n| `tsconfig.json` | TypeScript config |\n| `biome.json` or `biome.jsonc` | linter config |\n| `.husky/` | git hooks |\n| `commitlint.config.*` | commit lint config |\n| `src/services/ant-design-pro/` | auto-generated — do NOT manually edit; regenerate with `npm run openapi` |\n\n**Business files** — preserve these, only adjust imports/APIs if needed:\n\n- `src/pages/**` — user pages\n- `src/components/**` — user components\n- `src/models/**` — user models\n- `src/services/**/*.ts` — custom service files (NOT the `ant-design-pro/` subdirectory)\n- `src/locales/**` — user translations (framework keys may need updating)\n- `src/utils/**` — user utilities\n- `mock/**` — user mocks\n- Any other files not listed above\n\n### Step 3 — Diff framework files\n\nFor each framework file, read both the user's version and the template version. Identify:\n\n- **New dependencies** or version bumps in `package.json`\n- **New/changed config options** in `config/` files\n- **Import path changes** (e.g., `from 'umi'` → `from '@umijs/max'`)\n- **API changes** in `src/app.tsx`, `src/access.ts`, etc.\n- **New files** that exist in template but not in user's project\n\n### Step 4 — Merge intelligently\n\nApply changes with these rules:\n\n**Framework files — adopt template structure, preserve user customizations:**\n- `package.json`: update dependency versions to match template. Keep any extra deps the user added. If a dependency exists in the user's project but not in the template, assume it is a user customization and preserve it.\n- `config/routes.ts`: adopt the template's route structure for framework pages, but keep all user-added routes intact.\n- `config/proxy.ts`: adopt structure, preserve user's proxy targets.\n- Other framework files: adopt the template version, preserving any user customizations that are clearly intentional (comments, extra exports, business logic mixed in).\n\n**Business files — minimal changes only:**\n- Update import paths if framework modules moved (e.g., `'umi'` → `'@umijs/max'`).\n- Update deprecated API calls if the template shows a new pattern.\n- Never rewrite business logic, restructure components, or change styling approaches unless the old approach is broken.\n\n**Auto-generated files:**\n- `src/services/ant-design-pro/`: do NOT edit. Tell the user to run `npm run openapi` after upgrade.\n\n### Step 5 — Antd-specific migration checks\n\nRun these commands to catch antd API changes:\n\n```bash\nnpx antd env --format json\nnpx antd lint ./src --format json --only deprecated\n```\n\nIf the user is upgrading across major antd versions, also run:\n\n```bash\nnpx antd migrate <current_major> <target_major> --format json\n```\n\nDetect the current major version from the user's `package.json` and the target from the template's.\n\nAddress any findings by updating the flagged code.\n\n### Step 6 — Install and verify\n\n```bash\nnpm install\nnpm run lint\nnpm run build\n```\n\nFix any errors. Common post-upgrade issues:\n- Type errors from changed APIs → check `npx antd info <Component>` for current APIs\n- New lint rules from Biome config changes → run `npm run biome` to auto-fix\n- Missing peer dependencies → check `npm install` warnings\n\n### Step 7 — Cleanup and summarize\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\n```\n\nOutput a summary of all changes made, grouped by category:\n\n1. **Dependencies updated** — list version changes\n2. **Config changes** — what changed in config files\n3. **Code patterns migrated** — import path changes, API updates\n4. **New files added** — any files from the template that didn't exist before\n5. **Manual review needed** — anything you're unsure about or that requires user action\n\nRemind the user to:\n- Run `npm run openapi` if they use the auto-generated API services\n- Test their application thoroughly\n- Commit the changes\n\n## Key Principles\n\n- **No hardcoded versions** — this skill works regardless of the version gap between the user's project and the latest template.\n- **Preserve business code** — only modify what's necessary for framework compatibility.\n- **Conservative merging** — when uncertain whether a change is a user customization or an outdated pattern, ask the user instead of guessing.\n- **Leverage `@ant-design/cli`** — use `antd migrate`, `antd lint`, `antd info` for antd-specific checks; don't guess APIs from memory.\n- **Clean up** — always remove the temporary clone directory.","frontmatter":{"name":"pro-upgrade","description":"Use when the user wants to upgrade their Ant Design Pro project to the latest version. Triggers on: upgrade pro, pro upgrade, migrate pro, update pro, 升级, 迁移项目, \"how to upgrade\", \"update to latest\", \"keep project up to date\".\n","allowed-tools":["Bash(git clone *)","Bash(diff *)","Bash(npm install)","Bash(npm run lint*)","Bash(npm run build*)","Bash(npm run tsc*)","Bash(npx antd *)","Bash(rm -rf /tmp/ant-design-pro-upgrade*)","Read","Edit","Write","Glob","Grep"],"allowedTools":["Bash(git clone *)","Bash(diff *)","Bash(npm install)","Bash(npm run lint*)","Bash(npm run build*)","Bash(npm run tsc*)","Bash(npx antd *)","Bash(rm -rf /tmp/ant-design-pro-upgrade*)","Read","Edit","Write","Glob","Grep"]},"allowedTools":["Bash(git clone *)","Bash(diff *)","Bash(npm install)","Bash(npm run lint*)","Bash(npm run build*)","Bash(npm run tsc*)","Bash(npx antd *)","Bash(rm -rf /tmp/ant-design-pro-upgrade*)","Read","Edit","Write","Glob","Grep"],"isInternal":false,"tokens":1585,"sizeBytes":6633},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/ant-design/ant-design-pro/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n\n## Project\n\nAnt Design Pro — React enterprise boilerplate on Umi Max v4, antd v6, ProComponents v3.\n\n## Commands\n\n`npm start` (dev+mock), `npm run dev` (no mock), `npm run build` (utoopack), `npm run lint` (Biome+tsc), `npm run test` (Jest), `npx antd lint ./src` (antd-specific checks).\n\nOther: `npm run openapi` (regenerate `src/services/`), `npm run simple` (**irreversible** — commit first), `npm run biome` (auto-fix), `npm run tsc` (type-check only).\n\n## Critical Rules\n\n- **Never edit `src/services/ant-design-pro/`** — auto-generated, regenerate with `npm run openapi`\n- **Biome only** — no ESLint, no Prettier. Both `npm run lint` and `npx antd lint ./src` must pass before commit\n- **Always `npx antd info <Component>` before writing antd code** — don't guess APIs from memory\n- **`npm run simple` is irreversible** — always commit/branch first\n- **Conventional commits** required (commitlint enforced)\n- **TypeScript strict** · **Node ≥ 22** · **`package-lock.json`** (not yarn/pnpm)\n- **`.umi` dir is auto-generated** — delete `src/.umi` and restart if dev server acts up\n\n## Architecture Essentials\n\n**Config**: `config/config.ts` (defineConfig), `config/routes.ts` (declarative routes). Route `name` → `menu.xxx` i18n key; `access` field gates visibility.\n\n**Convention files** (`src/`): `app.tsx` (runtime config + `getInitialState`), `access.ts` (permissions), `global.tsx` (side effects), `loading.tsx`, `typings.d.ts`.\n\n**Auth**: `getInitialState()` → `GET /api/currentUser`; 401 → redirect login. `access.ts`: `canAdmin = currentUser.access === 'admin'`. Mock creds: `admin`/`ant.design` or `user`/`ant.design`.\n\n**State**: `useModel('filename')` for global hooks (`src/models/`). `useModel('@@initialState')` for currentUser/settings. ProTable `request` prop for most data loading. `@tanstack/react-query` for complex server state.\n\n**Styling priority**: Tailwind CSS v4 (layout) → antd-style v4 / `createStyles` (theme tokens) → CSS Modules → Less (legacy only).\n\n**Request**: built-in `request` from `@umijs/max`, configured in `src/requestErrorConfig.ts`. Per-page `service.ts` for non-generated APIs.\n\n**i18n**: 8 locales in `src/locales/`. `useIntl().formatMessage({ id, defaultMessage })`.\n\n**Mock**: `mock/` (global) + `src/pages/**/_mock.ts` (co-located). Express-style handlers.\n\n**Cloudflare Worker**: `cloudflare-worker/` — separate Hono app, own `package.json`, not an npm workspace.\n\n## AI Skills\n\nThis project ships with two built-in Claude Code Skills (`.claude/skills/`). If you already have these skills in your project, no installation is needed — just run them directly. To update to the latest skill definitions, run `npx skills add ant-design/ant-design-pro`.\n\n### `/pro-upgrade` — Project Upgrade\n\nRun `/pro-upgrade` in Claude Code to auto-upgrade the project to the latest Ant Design Pro version. It diffs the latest template against this project and merges framework changes while preserving business code. Works for any version gap (v5→v6, v6.x→latest, etc.).\n\n### `/antd` — Ant Design CLI\n\nRun `/antd` in Claude Code for any antd-related work. It provides access to `@ant-design/cli` with offline metadata for antd v3/v4/v5/v6. Key commands:\n\n- `npx antd info <Component>` — look up props/API before writing code (mandatory)\n- `npx antd lint ./src` — check for deprecated or problematic usage (must pass before commit)\n- `npx antd demo <Component> <demo>` — get working code examples\n- `npx antd migrate <from> <to>` — migration checklist between major versions\n\n## Page Co-location\n\nEach page dir: `index.tsx`, optional `service.ts`, `_mock.ts`, `data.d.ts`, style files. Keep page-specific code with the page.\n\n# CLAUDE.md\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n\n---","isInternal":false,"tokens":1523,"sizeBytes":6083}],"systemPromptSnippet":"<yakaai_skills repo=\"ant-design/ant-design-pro\">\n<!-- File: .claude/skills/antd/SKILL.md (Tokens: ~2051 | Category: anthropic-skill) -->\n---\nname: antd\ndescription: >\n  Use when the user's task involves Ant Design (antd) — writing antd components,\n  debugging antd issues, querying antd APIs/props/tokens/demos, migrating between\n  antd versions, or analyzing antd usage in a project. Triggers on antd-related\n  code, imports from 'antd', or explicit antd questions.\nallowed-tools:\n  - Bash(antd *)\n  - Bash(antd bug*)\n  - Bash(antd bug-cli*)\n  - Bash(npx antd *)\n  - Bash(npx antd bug*)\n  - Bash(npx antd bug-cli*)\n---\n\n# Ant Design CLI\n\nYou have access to `@ant-design/cli` — a local CLI tool with bundled antd metadata for v3/v4/v5/v6. Use it to query component knowledge, analyze projects, and guide migrations. All data is offline, no network needed.\n\n## Setup\n\nThe CLI is installed as a dev dependency. Use `npx antd` to run it.\n\n**Always use `--format json` for structured output you can parse programmatically.**\n\n## Scenarios\n\n### 1. Writing antd component code\n\nBefore writing any antd component code, look up its API first — don't rely on memory.\n\n```bash\n# Check what props are available\nnpx antd info Button --format json\n\n# Get a working demo as starting point\nnpx antd demo Button basic --format json\n\n# Check semantic classNames/styles for custom styling\nnpx antd semantic Button --format json\n\n# Check component-level design tokens for theming\nnpx antd token Button --format json\n```\n\n**Workflow:** `antd info` → understand props → `antd demo` → grab a working example → write code.\n\n### 2. Looking up full documentation\n\nWhen you need comprehensive component docs (not just props):\n\n```bash\nnpx antd doc Table --format json        # full markdown docs for Table\nnpx antd doc Table --lang zh            # Chinese docs\n```\n\n### 3. Debugging antd issues\n\nWhen code isn't working as expected or the user reports an antd bug:\n\n```bash\n# Collect full environment snapshot (system, deps, browsers, build tools)\nnpx antd env --format json\n\n# Check if the prop exists for the user's antd version\nnpx antd info Select --version 5.12.0 --format json\n\n# Check if the prop is deprecated\nnpx antd lint ./src/components/MyForm.tsx --format json\n\n# Diagnose project-level configuration issues\nnpx antd doctor --format json\n```\n\n**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.\n\n### 4. Migrating between versions\n\nWhen the user wants to upgrade antd (e.g., v3 → v4 or v4 → v5):\n\n```bash\n# Get full migration checklist\nnpx antd migrate 3 4 --format json    # v3 → v4\nnpx antd migrate 4 5 --format json    # v4 → v5\n\n# Check migration for a specific component\nnpx antd migrate 4 5 --component Select --format json\n\n# See what changed between two versions\nnpx antd changelog 4.24.0 5.0.0 --format json\n\n# See changes for a specific component\nnpx antd changelog 4.24.0 5.0.0 Select --format json\n```\n\n**Workflow:** `antd migrate` → get full checklist → `antd changelog <v1> <v2>` → understand breaking changes → apply fixes → `antd lint` → verify no deprecated usage remains.\n\n### 5. Analyzing project antd usage\n\nWhen the user wants to understand how antd is used in their project:\n\n```bash\n# Scan component usage statistics\nnpx antd usage ./src --format json\n\n# Filter to a specific component\nnpx antd usage ./src --filter Form --format json\n\n# Lint for best practice violations\nnpx antd lint ./src --format json\n\n# Check only specific rule categories\nnpx antd lint ./src --only deprecated --format json\nnpx antd lint ./src --only a11y --format json\nnpx antd lint ./src --only performance --format json\n```\n\n### 6. Checking changelogs and version history\n\nWhen the user asks about what changed in a version:\n\n```bash\n# Specific version changelog\nnpx antd changelog 5.22.0 --format json\n\n# Version range (both ends inclusive)\nnpx antd changelog 5.21.0..5.24.0 --format json\n```\n\n### 7. Exploring available components\n\nWhen the user is choosing which component to use:\n\n```bash\n# List all components with categories\nnpx antd list --format json\n\n# List components for a specific antd version\nnpx antd list --version 5.0.0 --format json\n```\n\n### 8. Collecting environment info\n\nWhen you need to understand the project's antd setup, or prepare info for a bug report:\n\n```bash\n# Full environment snapshot (text — paste into GitHub Issues)\nnpx antd env\n\n# Structured JSON for programmatic use\nnpx antd env --format json\n\n# Scan a specific project directory\nnpx antd env ./my-project --format json\n```\n\n### 9. Reporting antd bugs\n\nWhen the user asks you to report an antd bug:\n\n```bash\n# Step 0: Collect environment info for reference (optional)\nnpx antd env --format json\n\n# Step 1: Preview for user review\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --format json\n\n# Step 2: Show to user, ask for confirmation\n\n# Step 3: Submit after user confirms\nnpx antd bug --title \"DatePicker crashes when selecting date\" \\\n  --reproduction \"https://codesandbox.io/s/xxx\" \\\n  --steps \"1. Open DatePicker 2. Click a date\" \\\n  --expected \"Date is selected\" \\\n  --actual \"Component crashes with error\" \\\n  --submit\n```\n\n### 10. Reporting CLI issues\n\nWhen the user asks to report a CLI bug:\n\n```bash\nnpx antd bug-cli --title \"antd info Button returns wrong props\" \\\n  --description \"When querying Button props for version 5.12.0, the output includes props that don't exist\" \\\n  --steps \"1. Run: npx antd info Button --version 5.12.0 --format json\" \\\n  --expected \"Props matching antd 5.12.0 Button API\" \\\n  --actual \"Props include 'classNames' which was added in 5.16.0\" \\\n  --format json\n```\n\nShow the report to the user and confirm before submitting with `--submit`.\n\n**Opt-out:** If the environment variable `ANTD_NO_AUTO_REPORT=1` is set, skip all bug-reporting suggestions entirely.\n\n### 11. Using as MCP server\n\nIf working in an IDE that supports MCP (Claude Desktop, Cursor, etc.), the CLI can also run as an MCP server:\n\n```json\n{\n  \"mcpServers\": {\n    \"antd\": {\n      \"command\": \"npx\",\n      \"args\": [\"antd\", \"mcp\"]\n    }\n  }\n}\n```\n\nThis 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.\n\n## Global Flags\n\n| Flag | Purpose |\n|---|---|\n| `--format json` | Structured output — always use this |\n| `--version <v>` | Target a specific antd version (e.g. `5.20.0`) |\n| `--lang zh` | Chinese output (default: `en`) |\n| `--detail` | Include extra fields (description, since, deprecated, FAQ) |\n\n## Key Rules\n\n1. **Always query before writing** — Don't guess antd APIs from memory. Run `antd info` first.\n2. **Match the user's version** — This project uses antd v6. The CLI auto-detects from `node_modules` if no flag is given.\n3. **Use `--format json`** — Every command supports it. Parse the JSON output rather than regex-matching text output.\n4. **Check before suggesting migration** — Run `antd changelog <v1> <v2>` and `antd migrate` before advising on version upgrades.\n5. **Lint after changes** — After writing or modifying antd code, run `antd lint` on the changed files to catch deprecated or problematic usage.\n6. **Report antd bugs** — When the user asks to report an antd bug, use `antd bug`. Always preview first, get user confirmation, then submit.\n7. **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.\n\n<!-- File: .claude/skills/pro-upgrade/SKILL.md (Tokens: ~1585 | Category: anthropic-skill) -->\n---\nname: pro-upgrade\ndescription: >\n  Use when the user wants to upgrade their Ant Design Pro project to the latest version.\n  Triggers on: upgrade pro, pro upgrade, migrate pro, update pro, 升级, 迁移项目,\n  \"how to upgrade\", \"update to latest\", \"keep project up to date\".\nallowed-tools:\n  - Bash(git clone *)\n  - Bash(diff *)\n  - Bash(npm install)\n  - Bash(npm run lint*)\n  - Bash(npm run build*)\n  - Bash(npm run tsc*)\n  - Bash(npx antd *)\n  - Bash(rm -rf /tmp/ant-design-pro-upgrade*)\n  - Read\n  - Edit\n  - Write\n  - Glob\n  - Grep\n---\n\n# Ant Design Pro Upgrade Skill\n\nYou are an Ant Design Pro upgrade assistant. Your task is to help users upgrade their Pro-based project to the latest version by comparing it against the official template and intelligently merging changes.\n\n## Preflight\n\nBefore starting, confirm:\n\n1. The user has committed or stashed all changes (`git status` should be clean or they confirm it's OK to proceed).\n2. If not clean, remind them to commit or stash their changes first (e.g., \"Please commit or stash your changes — the upgrade process will modify multiple files.\") and wait for them to confirm.\n\n## Upgrade Flow\n\n### Step 1 — Fetch the latest template\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\ngit clone --depth=1 https://github.com/ant-design/ant-design-pro.git /tmp/ant-design-pro-upgrade\n```\n\nRead the template's `package.json` to confirm its version.\n\n### Step 2 — Classify files\n\nSeparate the user's project files into **framework files** (Pro-owned, rarely customized) and **business files** (user-written, must be preserved).\n\n**Framework files** — diff these against the template:\n\n| Path | Notes |\n|---|---|\n| `package.json` | dependencies, scripts, devDependencies only |\n| `config/config.ts` | framework config |\n| `config/routes.ts` | structure only — preserve user-added routes |\n| `config/defaultSettings.ts` | layout/theme defaults |\n| `config/proxy.ts` | structure only — preserve user targets |\n| `src/app.tsx` | runtime config |\n| `src/access.ts` | permission definitions |\n| `src/global.tsx` | global side effects |\n| `src/loading.tsx` | loading component |\n| `src/requestErrorConfig.ts` | request interceptor |\n| `src/typings.d.ts` | global type declarations |\n| `tsconfig.json` | TypeScript config |\n| `biome.json` or `biome.jsonc` | linter config |\n| `.husky/` | git hooks |\n| `commitlint.config.*` | commit lint config |\n| `src/services/ant-design-pro/` | auto-generated — do NOT manually edit; regenerate with `npm run openapi` |\n\n**Business files** — preserve these, only adjust imports/APIs if needed:\n\n- `src/pages/**` — user pages\n- `src/components/**` — user components\n- `src/models/**` — user models\n- `src/services/**/*.ts` — custom service files (NOT the `ant-design-pro/` subdirectory)\n- `src/locales/**` — user translations (framework keys may need updating)\n- `src/utils/**` — user utilities\n- `mock/**` — user mocks\n- Any other files not listed above\n\n### Step 3 — Diff framework files\n\nFor each framework file, read both the user's version and the template version. Identify:\n\n- **New dependencies** or version bumps in `package.json`\n- **New/changed config options** in `config/` files\n- **Import path changes** (e.g., `from 'umi'` → `from '@umijs/max'`)\n- **API changes** in `src/app.tsx`, `src/access.ts`, etc.\n- **New files** that exist in template but not in user's project\n\n### Step 4 — Merge intelligently\n\nApply changes with these rules:\n\n**Framework files — adopt template structure, preserve user customizations:**\n- `package.json`: update dependency versions to match template. Keep any extra deps the user added. If a dependency exists in the user's project but not in the template, assume it is a user customization and preserve it.\n- `config/routes.ts`: adopt the template's route structure for framework pages, but keep all user-added routes intact.\n- `config/proxy.ts`: adopt structure, preserve user's proxy targets.\n- Other framework files: adopt the template version, preserving any user customizations that are clearly intentional (comments, extra exports, business logic mixed in).\n\n**Business files — minimal changes only:**\n- Update import paths if framework modules moved (e.g., `'umi'` → `'@umijs/max'`).\n- Update deprecated API calls if the template shows a new pattern.\n- Never rewrite business logic, restructure components, or change styling approaches unless the old approach is broken.\n\n**Auto-generated files:**\n- `src/services/ant-design-pro/`: do NOT edit. Tell the user to run `npm run openapi` after upgrade.\n\n### Step 5 — Antd-specific migration checks\n\nRun these commands to catch antd API changes:\n\n```bash\nnpx antd env --format json\nnpx antd lint ./src --format json --only deprecated\n```\n\nIf the user is upgrading across major antd versions, also run:\n\n```bash\nnpx antd migrate <current_major> <target_major> --format json\n```\n\nDetect the current major version from the user's `package.json` and the target from the template's.\n\nAddress any findings by updating the flagged code.\n\n### Step 6 — Install and verify\n\n```bash\nnpm install\nnpm run lint\nnpm run build\n```\n\nFix any errors. Common post-upgrade issues:\n- Type errors from changed APIs → check `npx antd info <Component>` for current APIs\n- New lint rules from Biome config changes → run `npm run biome` to auto-fix\n- Missing peer dependencies → check `npm install` warnings\n\n### Step 7 — Cleanup and summarize\n\n```bash\nrm -rf /tmp/ant-design-pro-upgrade\n```\n\nOutput a summary of all changes made, grouped by category:\n\n1. **Dependencies updated** — list version changes\n2. **Config changes** — what changed in config files\n3. **Code patterns migrated** — import path changes, API updates\n4. **New files added** — any files from the template that didn't exist before\n5. **Manual review needed** — anything you're unsure about or that requires user action\n\nRemind the user to:\n- Run `npm run openapi` if they use the auto-generated API services\n- Test their application thoroughly\n- Commit the changes\n\n## Key Principles\n\n- **No hardcoded versions** — this skill works regardless of the version gap between the user's project and the latest template.\n- **Preserve business code** — only modify what's necessary for framework compatibility.\n- **Conservative merging** — when uncertain whether a change is a user customization or an outdated pattern, ask the user instead of guessing.\n- **Leverage `@ant-design/cli`** — use `antd migrate`, `antd lint`, `antd info` for antd-specific checks; don't guess APIs from memory.\n- **Clean up** — always remove the temporary clone directory.\n\n<!-- File: CLAUDE.md (Tokens: ~1523 | Category: claude-rule) -->\n# CLAUDE.md\n\n## Project\n\nAnt Design Pro — React enterprise boilerplate on Umi Max v4, antd v6, ProComponents v3.\n\n## Commands\n\n`npm start` (dev+mock), `npm run dev` (no mock), `npm run build` (utoopack), `npm run lint` (Biome+tsc), `npm run test` (Jest), `npx antd lint ./src` (antd-specific checks).\n\nOther: `npm run openapi` (regenerate `src/services/`), `npm run simple` (**irreversible** — commit first), `npm run biome` (auto-fix), `npm run tsc` (type-check only).\n\n## Critical Rules\n\n- **Never edit `src/services/ant-design-pro/`** — auto-generated, regenerate with `npm run openapi`\n- **Biome only** — no ESLint, no Prettier. Both `npm run lint` and `npx antd lint ./src` must pass before commit\n- **Always `npx antd info <Component>` before writing antd code** — don't guess APIs from memory\n- **`npm run simple` is irreversible** — always commit/branch first\n- **Conventional commits** required (commitlint enforced)\n- **TypeScript strict** · **Node ≥ 22** · **`package-lock.json`** (not yarn/pnpm)\n- **`.umi` dir is auto-generated** — delete `src/.umi` and restart if dev server acts up\n\n## Architecture Essentials\n\n**Config**: `config/config.ts` (defineConfig), `config/routes.ts` (declarative routes). Route `name` → `menu.xxx` i18n key; `access` field gates visibility.\n\n**Convention files** (`src/`): `app.tsx` (runtime config + `getInitialState`), `access.ts` (permissions), `global.tsx` (side effects), `loading.tsx`, `typings.d.ts`.\n\n**Auth**: `getInitialState()` → `GET /api/currentUser`; 401 → redirect login. `access.ts`: `canAdmin = currentUser.access === 'admin'`. Mock creds: `admin`/`ant.design` or `user`/`ant.design`.\n\n**State**: `useModel('filename')` for global hooks (`src/models/`). `useModel('@@initialState')` for currentUser/settings. ProTable `request` prop for most data loading. `@tanstack/react-query` for complex server state.\n\n**Styling priority**: Tailwind CSS v4 (layout) → antd-style v4 / `createStyles` (theme tokens) → CSS Modules → Less (legacy only).\n\n**Request**: built-in `request` from `@umijs/max`, configured in `src/requestErrorConfig.ts`. Per-page `service.ts` for non-generated APIs.\n\n**i18n**: 8 locales in `src/locales/`. `useIntl().formatMessage({ id, defaultMessage })`.\n\n**Mock**: `mock/` (global) + `src/pages/**/_mock.ts` (co-located). Express-style handlers.\n\n**Cloudflare Worker**: `cloudflare-worker/` — separate Hono app, own `package.json`, not an npm workspace.\n\n## AI Skills\n\nThis project ships with two built-in Claude Code Skills (`.claude/skills/`). If you already have these skills in your project, no installation is needed — just run them directly. To update to the latest skill definitions, run `npx skills add ant-design/ant-design-pro`.\n\n### `/pro-upgrade` — Project Upgrade\n\nRun `/pro-upgrade` in Claude Code to auto-upgrade the project to the latest Ant Design Pro version. It diffs the latest template against this project and merges framework changes while preserving business code. Works for any version gap (v5→v6, v6.x→latest, etc.).\n\n### `/antd` — Ant Design CLI\n\nRun `/antd` in Claude Code for any antd-related work. It provides access to `@ant-design/cli` with offline metadata for antd v3/v4/v5/v6. Key commands:\n\n- `npx antd info <Component>` — look up props/API before writing code (mandatory)\n- `npx antd lint ./src` — check for deprecated or problematic usage (must pass before commit)\n- `npx antd demo <Component> <demo>` — get working code examples\n- `npx antd migrate <from> <to>` — migration checklist between major versions\n\n## Page Co-location\n\nEach page dir: `index.tsx`, optional `service.ts`, `_mock.ts`, `data.d.ts`, style files. Keep page-specific code with the page.\n\n# CLAUDE.md\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n```\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n\n---\n</yakaai_skills>"}