名称: dyad:反馈转问题 描述: 将客户反馈（通常是电子邮件）转化为独立的GitHub问题。检查重复项，提出新问题供批准，创建它们，并起草回复邮件。
反馈转问题
将客户反馈（通常是电子邮件）转化为独立的GitHub问题。检查重复项，提出新问题供批准，创建它们，并起草回复邮件。
参数
$ARGUMENTS: 客户反馈文本（电子邮件正文、支持工单等）。也可以是包含反馈的文本文件的文件路径。
指令
-
解析反馈：
仔细阅读
$ARGUMENTS。如果看起来像文件路径，则读取文件内容。将反馈分解为独立的、可操作的问题。对于每个问题，识别：
- 一个简洁的标题（命令式形式，例如“添加暗模式支持”）
- 类型：
bug、feature、improvement或question - 客户报告或请求的清晰描述
- 严重性/优先级估计：
high、medium或low - 原始反馈中的任何相关引用
忽略问候语、问候和非可操作评论。专注于提取具体的问题、请求和建议。
-
搜索现有问题：
对于每个识别出的独立问题，搜索GitHub以查找可能已覆盖它的现有问题：
gh issue list --repo "$(gh repo view --json nameWithOwner -q '.nameWithOwner')" --state all --search "<相关关键词>" --limit 10 --json number,title,state,url为每个问题尝试多种关键词变体，以避免错过重复项。搜索开放和关闭的问题。
-
向用户呈现报告：
将报告格式化为三个部分：
已提交的问题
对于每个已有匹配GitHub问题的问题，显示：
- 提取的问题标题
- 匹配的GitHub问题，包括编号、标题、状态（开放/关闭）和URL
- 简要解释为什么匹配
提议的新问题
对于每个没有现有匹配的问题，显示：
- 标题：提议的问题标题
- 类型：bug / feature / improvement / question
- 优先级：high / medium / low
- 正文预览：提议的问题正文（包括相关的客户引用和需要发生什么的清晰描述）
- 标签：根据问题类型建议适当的标签
摘要
- 从反馈中提取的总问题数：N
- 已提交：N
- 新问题待创建：N
然后请用户审查并批准提案，然后再继续。 不要创建任何问题。等待明确的批准。用户可能想要编辑标题、描述、优先级或跳过某些问题。
-
创建批准的问题：
在用户批准后（他们可能先请求修改——应用这些修改），创建每个批准的问题：
gh issue create --title "<标题>" --body "<正文>" --label "<标签>"报告每个创建的问题，包括其编号和URL。
-
起草回复邮件：
在所有问题创建后，为客户起草一份简短、专业的回复邮件。邮件应该：
- 感谢他们的反馈
- 简要承认他们提出的每个项目
- 对于已存在现有问题的项目：提及已经在跟踪中
- 对于新创建的问题：提及已提交并将被调查
- 保持简洁——不超过几个短段落
- 使用友好但专业的语气
- 包括每个项目的GitHub问题URL链接，以便客户可以跟踪进度
- 以邀请随时分享更多反馈结束
在用户发送前，将草稿邮件呈现给用户审查。