chore: 纳入 antdv 协作 skills，忽略本机 Agent 接线目录

.agents/skills/antdv-next-cli-create-pr/SKILL.md

@@ -0,0 +1,343 @@
+---
+name: antdv-next-cli-create-pr
+description: Create pull requests for antdv-next/cli using the repository's PR conventions. Use this skill when the user asks to create/open a PR, draft PR title/body, summarize branch changes for a PR, or otherwise prepare PR content. Judge by intent rather than fixed phrases; short colloquial requests still count if they are about creating a PR rather than discussing PR concepts.
+---
+
+# Antdv Next CLI PR 创建规范
+
+## 目标
+
+一、基于当前分支相对基线分支的全部改动生成 PR，不只看最后一个 commit。
+
+二、优先使用仓库自带 PR 模板；当前没有模板时，使用本 skill 约定的 `Summary` / `Testing` 结构。
+
+三、PR 正文默认使用英文，用户明确要求中文时可使用中文；PR 标题始终使用英文，并遵循本文档约定的命名格式。
+
+四、真正执行 `gh pr create` 之前，必须先把 `base`、`title`、`body` 给用户确认，确认后才能创建 PR。
+
+## 基本规则
+
+### 一、按意图触发，不按短语触发
+
+只要能判断用户是在请求创建 PR，或为创建 PR 做准备，就应使用本 skill。
+
+不要把触发限制成固定说法。即使用户表达很短、很口语，或要求不完整，只要不是在单纯讨论 PR 概念，也应进入本 skill 的工作流。
+
+### 二、正文结构以仓库约定为准
+
+当前仓库没有 `.github/PULL_REQUEST_TEMPLATE*`。默认使用：
+
+- `## Summary`
+- `## Testing`
+
+如果仓库之后新增 PR 模板，必须先读取并使用模板，不要自行改 section 名称或删除主结构。
+
+### 三、正文默认英文，但标题固定英文
+
+现有 PR 正文以英文为主，因此默认使用英文正文。用户明确要求中文时可以使用中文正文。
+
+无论正文使用哪种语言：
+
+- `PR title` 都必须是英文
+- `PR title` 必须符合 Conventional Commits 格式
+- 标题 subject 必须以小写字符开头，以通过 `.github/workflows/validate-pr-title.yml`
+
+### 四、先分析分支，再写 PR
+
+创建 PR 前，必须先看：
+
+- 当前分支名
+- 基线分支
+- 当前分支相对基线分支的 commit 列表
+- `base...HEAD` 的完整 diff
+
+不要只根据工作区未提交内容写 PR，也不要只根据最近一个 commit 写 PR。
+
+### 五、先给草稿，后创建 PR
+
+无论用户是否说“直接帮我创建 PR”，都要先完成以下步骤：
+
+1. 生成 `base`、`title`、`body` 草稿
+2. 明确告诉用户：这是准备提交的 PR 内容
+3. 让用户确认是否继续创建，或先修改
+4. 只有用户明确确认后，才能真正执行 `gh pr create`
+
+若用户中途要求修改标题、类型、测试说明、目标分支等，应先更新草稿，再次确认。
+
+### 六、标题和正文要分工明确
+
+- PR 标题：用英文一句话概括本分支最主要的变动
+- PR 正文：说明主要结果、关键方案、关联 issue 和实际验证结果
+
+正文不是逐文件流水账。要归纳“为什么改”和“改完后对开发者/用户有什么影响”。
+
+### 七、信息不足时不要硬写
+
+若以下内容缺失且无法从分支改动中可靠推断：
+
+- 基线分支
+- 关联 issue
+- 变动性质
+- 测试或验证方式
+
+可以先给出草稿，并把无法确认的地方保留为待补充项；若用户要求直接创建 PR，也必须先说明缺失项并等待确认。
+
+## 执行步骤
+
+### 1. 检查仓库和 PR 环境
+
+建议先确认：
+
+```bash
+git status --short
+git branch --show-current
+git remote -v
+gh auth status
+```
+
+若 `gh` 不可用、未登录、当前不在 git 仓库、或当前分支不适合提 PR，应先说明问题，不要继续伪造结果。
+
+### 2. 确定基线分支
+
+不要未经分析就直接使用 `main`。按以下顺序判断：
+
+1. 用户明确指定了 `base branch` -> 直接使用
+2. 若当前分支存在可用的“来源线索”，优先根据真实 Git 信息推断：
+   - `git branch -vv` 查看 tracking / upstream
+   - `git reflog show <current-branch>` 查看是否能看出“从哪条分支 checkout 出来”
+   - 必要时结合 `git merge-base HEAD <candidate-branch>` 比较分叉点
+3. 若能较可靠判断“当前分支是从某条分支切出来的”，优先使用该分支作为 `base`
+4. 若无法可靠推断，再退回远端默认分支或仓库默认分支
+
+建议查看：
+
+```bash
+git branch --show-current
+git branch -vv
+git reflog show --date=local $(git branch --show-current)
+git remote show origin
+```
+
+注意：
+
+- tracking / upstream 只能作为线索，不等于绝对正确的“父分支”
+- `reflog` 若已清理，可能无法得到结果
+- 若推断结果不够确定，要在草稿中明确标注为“推断值”
+
+#### 新功能分支说明
+
+本仓库的新功能 PR 通常也提交到 `main`。只有用户明确要求 stacked PR，或 Git 历史能可靠证明当前分支基于另一功能分支时，才使用非 `main` 的 base；不要仅因类型为 `feat` 擅自改 base。
+
+### 3. 收集本分支全部改动
+
+至少查看：
+
+```bash
+git log --oneline <base>..HEAD
+git diff --stat <base>...HEAD
+git diff <base>...HEAD
+```
+
+必要时再看：
+
+```bash
+git diff --name-only <base>...HEAD
+```
+
+归纳时要覆盖该分支会进入 PR 的全部提交，而不是只写最后一次改动。
+
+### 4. 确定正文结构和语言
+
+先检查是否存在 `.github/PULL_REQUEST_TEMPLATE*`：
+
+- 存在：读取并使用仓库模板
+- 不存在：使用 `Summary` / `Testing` 结构
+
+正文默认使用英文；用户明确要求中文时再使用中文。
+
+### 5. 判断 PR 类型
+
+必须根据整条分支的“主结果”判断，不要被单个文件或 commit 干扰。
+
+优先判断：
+
+1. 新增 CLI、Agent、MCP 或集成方可用能力 -> `feat`
+2. 修复错误行为 -> `fix`
+3. 只修改文档或 skill -> `docs`
+4. 主要修改构建、打包配置 -> `build`
+5. 主要修改 workflow / CI -> `ci`
+6. 主要修改测试 -> `test`
+7. 无外部行为变化的代码整理 -> `refactor`
+8. 性能优化 -> `perf`
+9. 依赖或内部维护 -> `chore`
+10. 版本发布 -> `release`
+
+例如：
+
+- 新增 MCP tool -> `feat(mcp)`
+- 修复 changelog 版本解析 -> `fix(changelog)`
+- 更新 agent skill 说明 -> `docs(skills)`
+- 调整 tsdown 打包配置 -> `build(config)`
+- 修改 PR 校验 workflow -> `ci`
+
+### 6. 归纳 PR 的核心信息
+
+至少整理出：
+
+- 主要结果：本分支解决什么问题或新增什么能力
+- Related Issues：有可靠关联时填写 issue 链接或 `Closes #xxxx` / `Fixes #xxxx`
+- Summary：归纳用户影响、关键方案和重要约束
+- Testing：只列出本次实际执行并通过的命令
+- 兼容性：说明是否有 CLI 参数、输出格式、配置、MCP API 或打包产物变化
+
+### 7. 处理 Testing
+
+根据改动范围选择验证：
+
+- 所有 PR：`pnpm lint`
+- 修改 `src/**` 或 `test/**`：`pnpm build` 和 `pnpm test`
+- 涉及 CLI 执行、MCP、setup、打包或跨模块集成：考虑 `pnpm test:all`
+- 通用补充检查：`git diff --check`
+
+只写实际执行且通过的命令。未执行时写 `Not run (reason)`；失败时如实说明失败命令，不要写成通过。
+
+### 8. 生成 PR 标题
+
+标题要求：
+
+- 按下方“写法要求 -> 标题”生成
+- 覆盖整条分支的主要目标
+- 不要照搬单个 commit message
+- `type` 要与第 5 步判断一致
+
+### 9. 按约定产出 PR 正文草稿
+
+没有仓库模板时使用：
+
+```markdown
+## Summary
+
+- <主要结果或用户影响>
+- <关键方案或重要约束>
+
+## Testing
+
+- `<实际通过的命令>`
+```
+
+填写时遵守：
+
+- Summary 通常使用 2 至 4 个要点
+- Testing 只列实际结果
+- 有可靠关联 issue 时加入 `Closes #xxxx`、`Fixes #xxxx` 或链接
+- 涉及命令输出或交互变化时，提醒补充必要的终端输出、截图或示例
+- 有破坏性变化、迁移要求或公开行为变化时明确写出
+- 信息尚未确认时显式标注，不要假装确定
+
+### 10. 先给用户确认
+
+输出时至少包含：
+
+- `Base branch`
+- `PR title`
+- `PR body`
+- 实际执行的测试及结果
+- 需要用户补充或确认的点
+
+明确询问用户是否：
+
+- 直接创建 PR
+- 先修改后再创建
+
+没有明确确认前，不得执行 `gh pr create`。
+
+### 11. 创建 PR
+
+只有在用户明确确认后，才执行。
+
+执行前再次检查：
+
+```bash
+git status --short
+git branch -vv
+git remote -v
+gh repo view --json nameWithOwner,defaultBranchRef
+```
+
+要求：
+
+1. 确认当前分支的 tracking remote 和远端分支正确
+2. 确认 PR 的目标仓库是 `antdv-next/cli`，不要依赖 `gh` 默认推断
+3. 若 tracking remote 缺失、指向不明确、或不是预期 fork，先向用户确认，不要默认推送
+4. 只有在推送目标 remote 明确无误时，才推送当前分支
+5. 使用已确认过的标题和正文执行 `gh pr create`
+6. 只有用户明确要求 Draft PR 时才使用 `--draft`
+7. 相同 head/base 已存在 PR 时，返回现有 PR，不要重复创建
+
+若需要推送，优先使用明确的远端与分支名：
+
+```bash
+git push -u <remote> HEAD
+```
+
+正文较长时写入安全的临时文件，并使用：
+
+```bash
+gh pr create \
+  --repo antdv-next/cli \
+  --base <base> \
+  --head <owner>:<branch> \
+  --title "<title>" \
+  --body-file <body-file>
+```
+
+同仓库分支可以只传 `<branch>`；fork 分支使用 `<owner>:<branch>`。创建成功后返回 PR 链接。
+
+## 写法要求
+
+### 标题
+
+- 必须是英文
+- 默认先判断 `type`，再决定是否需要 `scope`
+- 优先使用 `type: subject` 或 `type(scope): subject`
+- 优先写结果，不写过程
+- 避免 `update`, `fix issues`, `misc changes` 这类空话
+- 若分支包含多类小改动，提炼一个更高层概括
+
+常用 `type` 参考：
+
+- `feat`：新增能力
+- `fix`：修复问题
+- `docs`：文档或 skill
+- `refactor`：重构
+- `test`：测试改动
+- `build`：构建或打包
+- `ci`：CI 或 workflow
+- `chore`：杂项维护
+- `perf`：性能优化
+- `release`：版本发布
+
+`scope` 使用规则：
+
+- 改动集中在单个功能边界时再加，如 `refactor(changelog): ...`
+- 常见 scope 包括 `cli`、`mcp`、`changelog`、`version`、`bug`、`setup`、`skills`、`package`
+- 若没有明显聚焦对象，就不要硬加 `scope`
+- 不要把目录名机械塞进 `scope`
+
+### Summary
+
+- 先写本分支解决的问题或新增的能力
+- 再写关键方案和重要约束
+- 若涉及 CLI 参数、输出格式、配置、MCP API 或打包产物变化，点明外部可感知差异
+- 不要写逐文件流水账
+
+### Testing
+
+- 只列本次实际执行并通过的命令
+- 未运行时写 `Not run (reason)`
+- 失败时如实说明，不要伪造通过结果
+- 根据改动范围参考 `pnpm lint`、`pnpm build`、`pnpm test`、`pnpm test:all` 和 `git diff --check`
+
+## 参考
+
+更多类型判断、基线分支建议、确认话术与标题示例见 `references/template-notes-and-examples.md`。

.agents/skills/antdv-next-cli-create-pr/references/template-notes-and-examples.md

@@ -0,0 +1,174 @@
+## PR 类型建议
+
+优先选择最贴近整条分支主结果的一个 type：
+
+- 新增 CLI、Agent、MCP 或集成能力：`feat`
+- 修复错误行为：`fix`
+- 只修改文档或 skill：`docs`
+- 主要修改测试：`test`
+- 无外部行为变化的整理：`refactor`
+- 性能优化：`perf`
+- 构建或打包配置：`build`
+- GitHub Actions / CI：`ci`
+- 依赖或内部维护：`chore`
+- 版本发布：`release`
+
+## 类型判断补充说明
+
+不要因为 diff 里包含逻辑代码就直接判成 `fix`，先看最终结果。
+
+优先判断：
+
+1. `feat` 只用于对外新增能力，不是“代码变多了”
+2. `fix` 用于修复真实错误行为
+3. 文档、skill、构建和 CI 改动优先使用各自 type
+4. 以用户、CLI 调用方或维护者最终感知到的结果为准
+
+示例：
+
+- 新增 MCP 查询工具 -> `feat(mcp): ...`
+- 修复版本 fallback 逻辑 -> `fix(version): ...`
+- 更新 agent skill -> `docs(skills): ...`
+- 调整 tsdown 配置 -> `build(config): ...`
+- 修改 PR title workflow -> `ci: ...`
+
+## Related Issues 写法
+
+有明确 issue 时：
+
+- `Closes #123`
+- `Fixes #123`
+- `Refs #123`
+
+没有可靠关联时可以不写，或写 `None`。不要编造 issue 编号。
+
+## Summary 写法
+
+推荐使用 2 至 4 个要点，回答：
+
+1. 原先有什么问题，或为什么需要新能力
+2. 这次改变了什么
+3. 是否影响 CLI 参数、输出格式、配置、MCP API 或包内容
+4. 是否有破坏性变化或迁移要求
+
+英文示例：
+
+```markdown
+## Summary
+
+- keep changelog version resolution inside the diff utility
+- simplify the command layer to pass resolved versions
+- preserve existing CLI output with no public API changes
+```
+
+中文示例：
+
+```markdown
+## Summary
+
+- 将 changelog 版本解析收敛到 diff 工具内部
+- 简化命令层，只传递已解析版本
+- 保持现有 CLI 输出，不涉及公开 API 变化
+```
+
+## Testing 写法
+
+Testing 只记录实际执行并通过的命令，不要根据代码改动猜测结果。
+
+常见验证：
+
+- 所有 PR：`pnpm lint`
+- 修改 `src/**` 或 `test/**`：`pnpm build`、`pnpm test`
+- CLI、MCP、setup、打包或跨模块集成：考虑 `pnpm test:all`
+- 通用检查：`git diff --check`
+
+示例：
+
+```markdown
+## Testing
+
+- `pnpm lint`
+- `pnpm build`
+- `pnpm test`
+- `git diff --check`
+```
+
+未执行时：
+
+```markdown
+## Testing
+
+- Not run (documentation-only change)
+```
+
+若测试失败，要写明失败命令和原因，不能写成通过。
+
+## 基线分支判断建议
+
+目标是尽量推断“当前分支实际从哪里切出来”，而不是拍脑袋默认 `main`。
+
+建议顺序：
+
+1. 用户明确指定了 `base branch` -> 直接使用
+2. 查看当前分支是否能从 `reflog` 看出 checkout 来源
+3. 查看 `git branch -vv` 的 tracking / upstream 作为辅助线索
+4. 必要时结合 `merge-base` 比较候选分支
+5. 若仍无法确定，再退回远端默认分支或仓库默认分支
+
+建议命令：
+
+```bash
+git branch --show-current
+git branch -vv
+git reflog show --date=local $(git branch --show-current)
+git remote show origin
+git merge-base HEAD <candidate-branch>
+```
+
+注意：
+
+- upstream 不是绝对父分支，只是候选线索
+- `reflog` 最接近真实答案，但不一定一直存在
+- 不确定时要明确告诉用户“这是推断值”
+
+## 创建 PR 前确认话术建议
+
+在真正执行 `git push` 或 `gh pr create` 前，先给用户确认版草稿：
+
+```markdown
+我先整理了一版待提交的 PR 草稿，请你确认：
+
+- Target repository: `antdv-next/cli`
+- Base branch: `main`
+- Head branch: `refactor/changelog-version-loading`
+- PR title: `refactor(changelog): move version loading into diff utility`
+- Testing: `pnpm lint`, `pnpm test`
+
+如果没问题，我再继续推送并创建 PR；如果你想改 title、base、正文或 Draft 状态，我先更新草稿。
+```
+
+## PR 标题示例
+
+`antdv-next/cli` 的 PR 标题使用英文，并遵循：
+
+- `<type>: <subject>`
+- `<type>(<scope>): <subject>`
+
+subject 必须以小写字符开头，以通过 `.github/workflows/validate-pr-title.yml`。
+
+推荐示例：
+
+- `feat(mcp): add component changelog query tool`
+- `fix(version): resolve missing patch versions with fallback`
+- `docs(skills): clarify CLI usage for agents`
+- `refactor(changelog): move metadata loading into diff utility`
+- `build(config): optimize tsdown bundle output`
+- `ci: validate pull request title format`
+- `chore(package): include skills in published files`
+
+不要这样写：
+
+- `修复版本解析问题`
+- `Update version resolver`
+- `fix issues`
+- `some improvements`

.agents/skills/antdv/SKILL.md

@@ -0,0 +1,247 @@
+---
+name: antdv
+description: >
+  Use when the user's task involves antdv-next — writing antdv-next components,
+  debugging antdv-next issues, querying antdv-next props/events/slot/tokens/demos, migrating between
+  antdv-next versions, or analyzing antdv-next usage in a project. Triggers on antdv-next-related
+  code, imports from 'antdv-next', or explicit antdv-next questions.
+allowed-tools:
+  - Bash(antdv *)
+  - Bash(antdv bug*)
+  - Bash(antdv bug-cli*)
+  - Bash(npm install -g @antdv-next/cli*)
+  - Bash(which antdv)
+---
+
+# Ant Design CLI
+
+You can visit `@antdv-next/cli` - a local cli tool that contains metadata about the current, latest version of antdv-next. Use it to query component knowledge, analyze projects, and guide migrations. All data is offline and does not require a network.
+## Setup
+
+Before first use, check if the CLI is installed. If not, install it automatically:
+
+```bash
+which antdv || npm install -g @antdv-next/cli
+```
+
+After running any command, if the output contains an "Update available" notice, run `antdv 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.
+
+```bash
+# Check what props are available
+antdv info Button --format json
+
+# Get a working demo as starting point
+antdv demo Button basic --format json
+
+# Check semantic classNames/styles for custom styling
+antdv semantic Button --format json
+
+# Check component-level design tokens for theming
+antdv token Button --format json
+
+# Get the overall design language (design.md): colors, typography, spacing, radius + principles
+antdv design.md --format json
+```
+
+**Workflow:** `antdv info` → understand props/event/slot → `antdv demo` → grab a working example → write code.
+
+### 2. Looking up full documentation
+
+When you need comprehensive component docs (not just props):
+
+```bash
+antdv doc Table --format json        # full markdown docs for Table
+antdv doc Table --lang zh            # Chinese docs
+```
+
+### 3. Debugging antd issues
+
+When code isn't working as expected or the user reports an antdv bug:
+
+```bash
+# Collect full environment snapshot (system, deps, browsers, build tools)
+antdv env --format json
+
+# Check if the prop exists for the user's antd version
+antdv info Select --version 5.12.0 --format json
+
+# Check if the prop is deprecated
+antdv lint ./src/components/MyForm.tsx --format json
+
+# Diagnose project-level configuration issues
+antdv doctor --format json
+```
+
+**Workflow:** `antdv env` → capture full environment → `antdv doctor` → check configuration → `antdv info --ver X` → verify API against the user's exact version → `antdv lint` → find deprecated or incorrect usage.
+
+### 4. Analyzing project antd usage
+
+When the user wants to understand how antd is used in their project:
+
+```bash
+# Scan component usage statistics
+antdv usage ./src --format json
+
+# Filter to a specific component
+antdv usage ./src --filter Form --format json
+
+# Lint for best practice violations
+antdv lint ./src --format json
+
+# Check only specific rule categories
+antdv lint ./src --only deprecated --format json
+antdv lint ./src --only a11y --format json
+antdv lint ./src --only performance --format json
+```
+
+### 5. Comparing component APIs between versions
+
+When the user asks what component APIs changed between versions:
+
+```bash
+# Compare props, events, slots, and methods for all components
+antdv changelog 1.2.2 1.5.2 --format json
+
+# Limit the comparison to one component
+antdv changelog 1.2.2 1.5.2 Select --format json
+```
+
+### 6. Exploring available components
+
+When the user is choosing which component to use:
+
+```bash
+# List all components with categories
+antdv list --format json
+
+# List components for a specific antd version
+antdv list --version 5.0.0 --format json
+```
+
+### 7. Collecting environment info
+
+When you need to understand the project's antdv-next setup, or prepare info for a bug report:
+
+```bash
+# Full environment snapshot (text — paste into GitHub Issues)
+antdv env
+
+# Structured JSON for programmatic use
+anvtd env --format json
+
+# Scan a specific project directory
+antdv env ./my-project --format json
+```
+
+Collects: OS, Node, package managers (npm/pnpm/yarn/bun/utoo), npm registry, browsers, core deps (antdv-next/vue/dayjs), all `@antdv-next/*` packages, and build tools (vite/typescript/etc.).
+
+### 8. Reporting antd bugs
+
+When the user asks you to report an antdv bug:
+
+```bash
+# Step 0: Collect environment info for reference (optional — antd bug already embeds basic env)
+# Use the output to cross-check versions or attach extra details to the bug report
+antdv env --format json
+
+# Step 1: Preview for user review
+antdv bug --title "DatePicker crashes when selecting date" \
+  --reproduction "https://codesandbox.io/s/xxx" \
+  --steps "1. Open DatePicker 2. Click a date" \
+  --expected "Date is selected" \
+  --actual "Component crashes with error" \
+  --format json
+
+# Step 2: Show to user, ask for confirmation
+
+# Step 3: Submit after user confirms
+antdv bug --title "DatePicker crashes when selecting date" \
+  --reproduction "https://codesandbox.io/s/xxx" \
+  --steps "1. Open DatePicker 2. Click a date" \
+  --expected "Date is selected" \
+  --actual "Component crashes with error" \
+  --submit
+```
+
+### 9. Reporting CLI issues
+
+When the user asks you to report a CLI bug, or explicitly requests help filing one:
+
+```bash
+# Preview the bug report for the user
+antdv bug-cli --title "antdv info Button returns wrong props for v1.5.1" \
+  --description "When querying Button info for version 1.5.1, the output includes props that don't exist in that version" \
+  --steps "1. Run: antdv info Button --ver 1.5.1 --format json" \
+  --expected "Props matching antdv-next 1.5.0 Button API" \
+  --actual "Props include 'classes' which was added in 1.5.1" \
+  --format json
+```
+
+Show the report to the user and confirm before submitting:
+
+```bash
+antdv bug-cli --title "antdv info Button returns wrong props for v1.5.1" \
+  --description "..." \
+  --steps "..." \
+  --expected "..." \
+  --actual "..." \
+  --submit
+```
+
+**Opt-out:** If the environment variable `ANTDV_NO_AUTO_REPORT=1` is set, skip all bug-reporting suggestions entirely — do not suggest `antdv bug` or `antdv bug-cli` unless the user directly asks.
+
+### 10. Upgrading the CLI
+
+When the user wants to update `@antdv-next/cli` to the latest version, or when an "Update available" notice appears:
+
+```bash
+# Upgrade to the latest version (auto-detects package manager)
+antdv upgrade
+```
+
+The command detects which package manager installed the CLI (npm, yarn, pnpm, bun) and runs the appropriate upgrade command. If detection fails, it suggests the manual command.
+
+### 11. Using as MCP server
+
+If working in an IDE that supports MCP (Claude Desktop, Cursor, etc.), the CLI can also run as an MCP server, exposing all knowledge-query tools directly:
+
+```json
+{
+  "mcpServers": {
+    "antdv": {
+      "command": "antdv",
+      "args": ["mcp", "--version", "1.5.0"]
+    }
+  }
+}
+```
+
+This provides 8 tools (`antdv_list`, `antdv_info`, `antdv_doc`, `antdv_demo`, `antdv_token`, `antdv_design_md`, `antdv_semantic`) and 2 prompts (`antdv-expert`, `antdv-page-generator`) via MCP protocol.
+
+## Global Flags
+
+| Flag                | Purpose                                                                    |
+|---------------------|----------------------------------------------------------------------------|
+| `--format <format>` | Output format: `json`, `text`, or `markdown` (agents should prefer `json`) |
+| `--ver`             | Target a specific antd version (e.g. `1.5.0`)                              |
+| `--detail`          | Include extra fields (description, since, deprecated, FAQ)                 |
+| `-V, --version`     | Print CLI version and exit                                                 |
+
+## Key Rules
+
+1. **Always query before writing** — Don't guess antd APIs from memory. Run `antdv info` first.
+2. **Match the user's version** — Knowledge queries (`list/info/doc/demo/token/semantic/changelog`) support antdv-next v1.x.
+3. **Use `--format json`** — Every command supports it. Parse the JSON output rather than regex-matching text output.
+4. **Check before suggesting migration** — Run `antdv changelog <v1> <v2>` and `antdv migrate` before advising on version upgrades.
+5. **Lint after changes** — After writing or modifying antd code, run `antdv lint` on the changed files to catch deprecated or problematic usage.
+6. **Report antdv-next bugs** — When the user asks to report an antd bug, use `antdv bug`. Always preview first, get user confirmation, then submit.
+7. **Report CLI issues** — When the user asks about a CLI problem, use `antdv bug-cli` to help them file a report. Always preview first, get user confirmation, then submit.

.gitignore

@@ -23,3 +23,7 @@ build/
 # 测试与工具
 coverage/
 *.tsbuildinfo
+
+# Agent 本地接线（skills 本体只保留 .agents/skills）
+.claude/
+agent/

skills-lock.json

@@ -0,0 +1,17 @@
+{
+  "version": 1,
+  "skills": {
+    "antdv": {
+      "source": "antdv-next/cli",
+      "sourceType": "github",
+      "skillPath": "skills/antdv/SKILL.md",
+      "computedHash": "03eb1af94f9501f6b9ff2c4a3eb8010840e2492015e31c50402762964be7273e"
+    },
+    "antdv-next-cli-create-pr": {
+      "source": "antdv-next/cli",
+      "sourceType": "github",
+      "skillPath": ".agents/skills/create-pr/SKILL.md",
+      "computedHash": "ed62187839cd00787865cab43b1987d40b71f8cfdaa6ba862a0b130ea3243ac5"
+    }
+  }
+}