| name | antd-issue-reply |
| description | Help maintainers reply to Ant Design GitHub issues following official guidelines. Use this skill when the user asks to handle issues, reply to issues, process issues, check issues, or manage issues for ant-design/ant-design repository. Also use when the user mentions "issue" in the context of antd, Ant Design, or GitHub issue management. This skill provides guidelines for classifying issues (Bug vs Feature Request), handling dosubot replies, using proper labels, writing polite responses, and knowing when to close issues. |
Ant Design Issue 回复规范
目标
一、保持社区活跃 - 让用户反馈被及时响应，提升用户参与感和满意度。
二、提高处理效率 - 减少 open issues 和重复 issues，保持 issues 区整洁有序。
核心原则
开源项目的用户和维护者之间并不是甲方和乙方的关系，issue 也不是客服。处理 issue 时抱着『一起合作来解决问题』的心态。
基本规则
一、首次回复
对满足以下所有条件的 issues 进行回复：
- Issue 状态为 open
- 没有人类维护者（MEMBER/OWNER/CONTRIBUTOR）回复过
二、检查已回复的 Issues
对于已有 MEMBER/CONTRIBUTOR 回复的 issues，也要检查是否处理妥当：
需要关注的情况：
- 维护者已提出问题/解决方案，但用户**长时间（7天以上）**未回复
- 问题已明确被解决（用户确认或版本已修复）
- 维护者已说明这不是 bug，但 issue 仍然 open
处理方式：
- 用户长时间未回复 → 关闭 issue 并留言说明
- 问题已解决 → 关闭 issue
- 使用问题但已提供解决方案 → 关闭 issue
注意： Inactive 标签只表示近期无活动，不代表已解决，仍可回复。
⚠️ 语言政策（必须严格执行）
判断规则：只看 issue body 原始内容，忽略后续评论中使用的语言
判断流程：
1. 查看 issue 的原始 body（第一个帖子内容）
2. 检查 "What is expected?" 和 "What is actually happening?" 部分的语言
3. 如果是英文 → 用英文回复
4. 如果是中文 → 用中文回复
常见误区：
- ❌ 不要因为 issue-helper 模板是中文就用中文回复
- ❌ 不要因为后续评论使用了某种语言就跟随
- ❌ 不要因为 dosubot 使用了某种语言就跟随
- ✅ 只看 issue 作者在 body 中描述问题时使用的语言
示例：
Issue body:
"What is expected?" → "22.01.2026" (英文)
"What is actually happening?" → "dont work datepicker..." (英文)
正确做法 → 用英文回复
保持友善和耐心，即使用户语气不太好。
Issue 类型
Issue 列表主要用于跟踪 Bug 报告 和 功能请求。
使用问题的建议渠道：
处理 dosubot 回复
如果 dosubot 已经回复过：
- 审核回复的准确性
- 正确 → 确认背书："感谢 @dosu 的分析，确认这是正确的解决方案。"
- 不正确 → 提供更正："感谢 @dosu，但需要补充说明..."
- 完整正确 → 无需额外回复
使用 @dosu（而非 @dosubot） mention 机器人。
Issue 分类处理
Bug 报告
首先检查版本：
- 老版本 + changelog 中已修复 → 引导用户升级验证
- PR 已合并但新版本未发布 → 告知用户等待新版本发布
检查重现链接：
- 缺少/无关 → 添加
🤔 Need Reproduce，请求提供
- 有重现 + 确认 bug → 添加
🐛 Bug 标签
功能请求
- 添加
💡 Feature Request 标签
- 描述模糊 → 询问使用场景和期望 API
处理功能请求时，先排查现有能力再讨论新增：
- 先查现有 API — 用户提需求时常因"找不到"而误以为"没有"。收到 feature request 时，第一反应应是"我们是不是已经有这个了"，而非"怎么实现它"。搜一下相关组件的 props、文档、已有 issue，确认未被现有功能覆盖。
- 关注命名可发现性 — 如果功能已存在但用户找不到，问题的本质不是缺功能而是 API 可发现性差。此时应该：向用户指出已有 API 并附代码示例；同时反思文档是否需要补充搜索关键词或交叉引用（如用户搜
mapping 但 API 叫 fieldNames，文档中应关联这两个词）。
- 检查跨组件一致性 — 用户会从一个组件的 API 类推另一个。同一概念在不同组件用不同命名（如 Table 的
rowKey vs Select 的 fieldNames），会制造认知负担。如果发现用户因跨组件命名不一致而困惑，记录下来作为后续 API 一致性优化的参考。
- 用提问引导而非否定 — 确认已有功能后，不要直接说"我们已经有这个了"然后关 issue。用提问式引导让用户自己确认："看描述这个需求好像可以用
fieldNames 实现，是我理解的不对吗？"——既帮用户解决问题，又保护了用户面子。用户确认后再关闭。
使用问题
你可以尝试解决和回复使用问题：
- 查阅文档，提供解决方案和代码示例
- 如果能解决，直接回复帮助用户
- 如果用户描述的问题其实是现有 API 已覆盖的场景，用提问式引导："这个需求看起来可以用
xxx prop 实现，是我理解的不对吗？"——比直接甩文档链接更友好
也可以引入 AI 帮助解答：
@docu - GitHub Copilot 文档助手@Copilot - GitHub Copilot
回复示例：
感谢反馈！这是一个使用问题，让我尝试帮你解答：
[提供解决方案和代码示例]
参考文档：https://ant.design/components/xxx
如果以上方案不能解决问题，可以尝试 @dosu 或 @Copilot 获取更多帮助。
若无法解决，引导用户到其他渠道：
FAQ 问题
查找资源顺序：
- 带
❓FAQ 标签的 issues
- 组件文档 FAQ 部分
- 常见问题汇总
Bug vs Feature Request 分类
| 类型 | 特征 |
|---|
| Bug | 使用现有功能，行为不符合预期；之前正常现在坏了 |
| Feature Request | 需要目前不存在的新能力 |
示例：
- Cascader onFocus 不触发 → Bug（现有功能不工作）
- 添加 DatePicker 键盘导航 → Feature Request（新能力）
不确定时归类为 Bug
处理重复 Issues
- 找到原始 issue
- 回复："Duplicate of #xxxx"
- 关闭 issue
关闭 Issues（需谨慎！）
关闭前必须检查：
- ⚠️ 确认使用正确的语言（参考语言政策）
可关闭：
- 重复问题
- 确定不是 bug（使用问题）
- 已解决
- 用户长时间未回复（7天以上）
关闭时保持礼貌，简要说明关闭原因即可。
不要关闭：
- 不确定是否是 bug
- 用户未确认解决方案有效（且未超过等待时间）
- 有效的功能请求
- 正在活跃讨论中的 issue
禁止承诺
- ❌ 不要承诺发布日期
- ❌ 不要说"我们会添加这个功能"
- ✅ 应该说："这是一个合理的需求，我们会考虑。欢迎社区贡献。"
何时不回复
- dosubot 已提供完整正确答案
- 无法确定正确的回复内容
- Issue 正在活跃讨论中
检查已回复 Issues 的流程
对于已有维护者回复的 issues，按以下流程检查：
1. 确认回复语言正确（⚠️ 只看 issue body 原始语言）
2. 查看维护者的最后一条评论
├─ 是提问/请求更多信息？
│ └─ 用户是否超过 7 天未回复？
│ ├─ 是 → 检查语言 → 关闭 issue 并留言
│ └─ 否 → 跳过
├─ 是说明解决方案？
│ └─ 用户是否确认解决？
│ ├─ 是 → 检查语言 → 关闭 issue
│ └─ 否，且超过 7 天 → 检查语言 → 关闭 issue 并留言
└─ 其他情况 → 跳过
语气和风格
- 保持友善、耐心和专业
- 尽可能提供代码示例
- 引用文档链接
- 对新人友好，鼓励社区参与
交互流程
当用户要求处理 issues 时，采用「先草拟、后确认」的两阶段流程：
第一阶段：总览 + 草拟方案
- 使用
gh issue list 拉取指定范围的 open issues
- 对每个 issue 获取详情（body、comments、labels）
- 对每个 issue 给出处理方案，包括：
- 分类（Bug / Feature Request / 使用问题）
- 当前状态（无人回复 / 维护者已回复 / 等待用户反馈 等）
- 处理建议（需要回复 / 可以关闭 / 无需操作 / 等待中）
- 如果需要回复：草拟回复内容（含语言判断、正文、代码示例）
- 标签操作（添加/移除哪些标签）
- 是否关闭 issue
- 将所有方案一次性呈现给用户，不要直接操作
第二阶段：讨论和确认
- 用户可以对任意 issue 的方案提出修改意见
- 根据反馈调整方案，直到用户满意
- 用户确认后执行操作（评论、加标签、关闭等）
- 如果用户说「就这样」或类似确认，直接执行
关键原则：先草拟完整方案，等用户讨论确认后再执行。不要未经确认就回复或关闭 issue。
参考资源
详细标签列表和资源链接请参阅 references/labels-and-resources.md
