.agents/skills/issue-reply/SKILL.md
一、保持社区活跃 - 让用户反馈被及时响应，提升用户参与感和满意度。
二、提高处理效率 - 减少 open issues 和重复 issues，保持 issues 区整洁有序。
开源项目的用户和维护者之间并不是甲方和乙方的关系，issue 也不是客服。处理 issue 时抱着『一起合作来解决问题』的心态。
对满足以下所有条件的 issues 进行回复：
对于已有 MEMBER/CONTRIBUTOR 回复的 issues，也要检查是否处理妥当：
需要关注的情况：
处理方式：
注意： Inactive 标签只表示近期无活动，不代表已解决，仍可回复。
判断规则：只看 issue body 原始内容，忽略后续评论中使用的语言
判断流程：
1. 查看 issue 的原始 body（第一个帖子内容）
2. 检查 "What is expected?" 和 "What is actually happening?" 部分的语言
3. 如果是英文 → 用英文回复
4. 如果是中文 → 用中文回复
常见误区：
示例：
Issue body:
"What is expected?" → "22.01.2026" (英文)
"What is actually happening?" → "dont work datepicker..." (英文)
正确做法 → 用英文回复
保持友善和耐心，即使用户语气不太好。
Issue 列表主要用于跟踪 Bug 报告 和 功能请求。
使用问题的建议渠道：
如果 dosubot 已经回复过：
使用 @dosu（而非 @dosubot） mention 机器人。
首先检查版本：
检查重现链接：
🤔 Need Reproduce，请求提供🐛 Bug 标签💡 Feature Request 标签你可以尝试解决和回复使用问题：
也可以引入 AI 帮助解答：
@docu - GitHub Copilot 文档助手@Copilot - GitHub Copilot回复示例：
感谢反馈！这是一个使用问题，让我尝试帮你解答：
[提供解决方案和代码示例]
参考文档：https://ant.design/components/xxx
如果以上方案不能解决问题，可以尝试 @dosu 或 @Copilot 获取更多帮助。
若无法解决，引导用户到其他渠道：
查找资源顺序：
❓FAQ 标签的 issues| 类型 | 特征 |
|---|---|
| Bug | 使用现有功能，行为不符合预期；之前正常现在坏了 |
| Feature Request | 需要目前不存在的新能力 |
示例：
不确定时归类为 Bug
关闭前必须检查：
可关闭：
关闭时保持礼貌，简要说明关闭原因即可。
不要关闭：
对于已有维护者回复的 issues，按以下流程检查：
1. 确认回复语言正确（⚠️ 只看 issue body 原始语言）
2. 查看维护者的最后一条评论
├─ 是提问/请求更多信息？
│ └─ 用户是否超过 7 天未回复？
│ ├─ 是 → 检查语言 → 关闭 issue 并留言
│ └─ 否 → 跳过
├─ 是说明解决方案？
│ └─ 用户是否确认解决？
│ ├─ 是 → 检查语言 → 关闭 issue
│ └─ 否，且超过 7 天 → 检查语言 → 关闭 issue 并留言
└─ 其他情况 → 跳过
当用户要求处理 issues 时，采用「先草拟、后确认」的两阶段流程：
gh issue list 拉取指定范围的 open issues关键原则：先草拟完整方案，等用户讨论确认后再执行。不要未经确认就回复或关闭 issue。
详细标签列表和资源链接请参阅 references/labels-and-resources.md