Create pull requests for ant-design using the repository's official PR templates. 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.
一、基于当前分支相对基线分支的全部改动生成 PR，不只看最后一个 commit。
二、严格使用 ant-design 仓库自带模板，不自行发明 PR 结构。
三、根据用户语言习惯选择中文或英文模板，但 PR 标题始终使用英文，并遵循本文档约定的命名格式。
四、真正执行 gh pr create 之前，必须先把 base、title、body 给用户确认，确认后才能创建 PR。
只要能判断用户是在请求创建 PR，或为创建 PR 做准备，就应使用本 skill。
不要把触发限制成固定说法。即使用户表达很短、很口语，或要求不完整，只要不是在单纯讨论 PR 概念，也应进入本 skill 的工作流。
始终使用以下模板之一：
.github/PULL_REQUEST_TEMPLATE_CN.md.github/PULL_REQUEST_TEMPLATE.md不要自己改 section 名称，不要删掉模板里已有的主结构。可以删掉模板中的注释和说明性占位文本，但保留最终要提交的 section。
按以下顺序判断：
不要因为代码、分支名、commit message 或 issue 链接是英文，就强行改用英文模板。
但无论模板选中文还是英文：
PR title 都必须是英文PR title 要符合本文档的标题规范PR body 才跟随模板语言创建 PR 前，必须先看：
base...HEAD 的完整 diff不要只根据工作区未提交内容写 PR，也不要只根据最近一个 commit 写 PR。
无论用户是否说“直接帮我创建 PR”，都要先完成以下步骤：
base、title、body 草稿gh pr create若用户中途要求修改标题、类型、changelog、目标分支等，应先更新草稿，再次确认。
正文不是逐文件流水账。要归纳“为什么改”和“改完后对开发者/用户有什么影响”。
若以下内容缺失且无法从分支改动中可靠推断：
可以先给出草稿，并把无法确认的地方保留为待补充项；若用户要求直接创建 PR，也必须先说明缺失项并等待确认。
建议先确认：
git status --short
git branch --show-current
git remote -v
gh auth status
若 gh 不可用、未登录、当前不在 git 仓库、或当前分支不适合提 PR，应先说明问题，不要继续伪造结果。
不要默认就用 master。按以下顺序判断：
base branch -> 直接使用git branch -vv 查看 tracking / upstreamgit reflog show <current-branch> 查看是否能看出“从哪条分支 checkout 出来”git merge-base HEAD <candidate-branch> 比较分叉点base建议查看：
git branch --show-current
git branch -vv
git reflog show --date=local $(git branch --show-current)
git remote show origin
注意：
reflog 若已清理，可能无法得到结果如果改动性质判断为 feat / 新功能，且当前基线不是明显的功能分支（如 feature/*），应额外提醒用户：
feature 分支，而不是默认开发主分支此提醒只用于确认工作流，不要擅自改 base。
至少查看：
git log --oneline <base>..HEAD
git diff --stat <base>...HEAD
git diff <base>...HEAD
必要时再看：
git diff --name-only <base>...HEAD
归纳时要覆盖该分支会进入 PR 的全部提交，而不是只写最后一次改动。
根据“语言由用户习惯决定”的规则，二选一：
.github/PULL_REQUEST_TEMPLATE_CN.md.github/PULL_REQUEST_TEMPLATE.md读取对应模板后再填写，避免凭记忆手写 section。
必须根据“主目的”判断，不要仅因为改动里包含逻辑变更就默认写成 fix。
优先判断顺序：
site / docs / democi / chorefixfeatrefactor / test / type / perf判断时以“用户感知的主结果”为准，不要被单个文件或单个 commit 干扰。
例如：
site，不是组件 fixdocsdemocifix至少整理出：
close #xxxx / fix #xxxx对于以下场景，通常无需写实质 changelog：
sitedocsdemoci这类场景：
N/ANo changelog required无需更新日志只有当改动确实会影响组件使用者、公开 API、交互行为、视觉表现或发布内容时，才写实质 changelog。
标题要求：
type 要与第 5 步判断一致填写时遵守：
输出时至少包含：
Base branchPR titlePR body明确询问用户是否：
没有明确确认前，不得执行 gh pr create。
只有在用户明确确认后，才执行。
执行前再次检查：
git branch -vv
git remote -v
gh repo view --json nameWithOwner
要求：
ant-design/ant-design，不要依赖 gh 默认推断gh pr create若需要推送，优先使用明确的远端与分支名，例如：
git push -u <remote> HEAD
建议形式：
gh pr create --repo ant-design/ant-design --base <base> --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
创建成功后，返回 PR 链接。
type，再决定是否需要 scopetype: subject 或 type(scope): subjectupdate, fix issues, misc changes 这类空话常用 type 参考：
feat：新增能力fix：修复问题docs：文档或说明refactor：重构type：类型修正site：站点相关改动demo：示例相关改动test：测试改动ci：CI 或 workflowchore：杂项维护perf：性能优化scope 使用规则：
refactor(Image): ...scopescopesite / docs / demo / ci / 纯测试等无须强写更多类型判断、基线分支建议、确认话术与标题示例见 references/template-notes-and-examples.md。