name: github-issues description: GitHub问题评论指南，用于社区互动。在响应GitHub问题、错误报告、功能请求或任何GitHub讨论时使用。

GitHub问题与拉取请求评论指南

反模式（避免这些）

过度结构化的回复：对于简单的回复，不要使用标题、编号部分或项目符号列表。通常，一段对话式的段落更好。
公式化的开头：不要每次评论都使用相同的开头。根据对话调整语气。
重复显而易见的内容：如果有人问了问题，直接回答。不要复述他们说的话。
企业公告风格：“我们很高兴地宣布…” — 直接说明改变了什么。

遵循writing-voice获取语气指南。

开头模式

总是以个人问候开始，使用用户的GitHub句柄：

“嘿 @用户名，感谢您提出这个问题”
“嘿大家，感谢通知！”
“嘿所有人，感谢问题！”

核心元素

1. 确认

首先确认他们的问题/贡献
对问题表示同情：“很抱歉听到这个！”，“很抱歉您的快捷键丢失了！”
对延迟道歉：“我为延迟回复道歉”

2. 好消息传达

当宣布功能或修复时：

“好消息！” 或 “Good news！”
适度添加庆祝表情符号
致谢贡献者：“感谢您的灵感” 或 “感谢您以及@用户1和@用户2的灵感”

3. 调试提供

对于复杂问题，提供直接帮助：

“如果您有时间，我很乐意与您通话，一起调试这个问题”
“让我们在未来几天安排一个通话，我会与您一起调试”
总是包括cal.com链接：“https://cal.com/epicenter/whispering”
添加可用性：“我最早明天就有空”

4. Discord推广

在适当的时候，提到Discord：

“PS：我还最近创建了一个Discord群组，我希望您加入！您可以直接私信我获取更多功能。”
包括链接：“https://go.epicenter.so/discord”

5. 后续问题

提出澄清问题以更好地理解问题：

“为了澄清，您能确认这个问题即使在最新的v7.1.0安装程序中仍然存在吗？”
“您是否曾经收到弹出窗口要求授权访问录制设备？”
“这是否发生在您录制超过4秒时？”

6. 结尾

以感激结束：

“谢谢！”
“再次感谢！”
“再次感谢您的帮助，我会查看！”
“我的荣幸！”（当被感谢时）

响应示例

功能实现响应

嘿 @用户名，感谢您的问题，好消息！[Whispering v7.1.0](链接)现在包括[功能]！感谢您的灵感。

[简短描述它如何工作]

PS：我还最近创建了一个Discord群组，我希望您加入！您可以直接私信我获取更多功能。

https://go.epicenter.so/discord

调试响应

嘿 @用户名，很抱歉听到这个！我为延迟回复道歉；我正在最终化[最新发布v7.1.0](链接)。

为了澄清，您能确认这个问题即使在最新的v7.1.0安装程序中仍然存在吗？

如果您有时间，我很乐意与您通话，一起调试这个问题。您可以使用我的cal.com链接预订与我的会议，我最早明天就有空：

https://cal.com/epicenter/whispering

谢谢！

快速确认

嘿 @用户名，很抱歉[问题]！您有没有找到修复？

PR讨论（来回）

好发现！更新为仅在nuke模式下清除开发应用缓存。

The flow is now:
- `bun clean`: artifacts and node_modules
- `bun nuke`: above + Rust targets + dev cache

Let me know if you want a confirmation prompt before clearing.

写作风格笔记

参见writing-voice获取标点和语气指南。

使用随意、平易近人的语言
对用户贡献真正热情
引用特定用户并给予信用
链接到相关问题、发布或提交
保持回复个人化和对话式
避免企业或过于正式的语言
PR评论可以简短：持续讨论不需要完整的问候/结尾
匹配能量：简短问题得到简短答案，详细报告得到详细响应