qa 是一个交互式 QA skill，用于把对话式 bug 报告转化为可长期保存的 GitHub issue。它会帮助代理先问几个有针对性的问题，再结合代码库上下文和领域术语进行探索，最后写出面向用户、避免实现细节的 issue。需要把杂乱的反馈整理成清晰 issue 时，可在 Issue Tracking 场景使用 qa。
该 skill 评分为 74/100，适合收录，但需要明确提醒使用边界。它提供了一套具体的 QA 到 GitHub issue 工作流，并给出足够的流程指引，使代理比通用提示更容易稳定触发和使用；但由于缺少配套文件，且路径位于已弃用目录下，能力仍然受限。
- 触发条件明确：frontmatter 直接说明可用于 bug 报告、QA、对话式提交 issue，或用户提到 “QA session” 时使用。
- 操作流程清晰：要求代理最多提出 2–3 个简短澄清问题，在后台探索代码库，并提交可长期保存、面向用户的 GitHub issue。
- 对代理很友好：它要求使用项目领域术语并避免内部实现细节，有助于提升 issue 质量。
- 该 skill 位于 skills/deprecated/qa，用户可能需要确认它是否仍在维护，或是否已被更新的替代方案取代。
- 没有看到支持文件、脚本、参考资料或安装命令，因此实际采用主要依赖 SKILL.md 本身。
qa skill 概述
qa skill 用于交互式 QA 场景：用户会用对话方式报告 bug、令人困惑的行为或产品问题，agent 再把这些信息整理成一条可长期留存的 GitHub issue。它最适合那些希望获得更高质量 bug 报告、但又不想强迫用户用 issue template 语言来写的人和团队。
qa skill 适用于什么场景
当你的真实任务是从一段杂乱的反馈里提炼出清晰 issue 时，就该用 qa skill：用户原本期待什么、实际发生了什么、是否可复现、涉及产品边界的哪一部分。它尤其适合 Issue Tracking 相关的 qa 场景，因为你需要报告读起来像一条有产品质量感的 issue，而不是一段原始聊天记录。
qa skill 的不同之处
qa skill 的核心价值并不是当场修 bug。它帮助 agent 只问少量、有针对性的问题，在后台结合代码库补上下文，并用项目自己的语言来撰写 issue。相比通用 prompt，它更适合需要“issue 质量”而不只是“摘要质量”的场景。
最适合与不适合的场景
当用户能描述一个可见问题、回归、边界情况或损坏的工作流时，这个 skill 最合适。如果你已经有完整复现步骤，只需要根因分析，或者任务本来就不是要变成 GitHub issue，那么它就不太合适。
如何使用 qa skill
在仓库中安装 qa
使用 npx skills add mattpocock/skills --skill qa 安装 qa skill。把它当作一次会话工作流，而不是一个库：安装后，当用户说自己在做 QA、报 bug，或者希望你把一段对话式反馈整理成 issue 时再使用它。
先从用户的粗略反馈开始
qa skill 最适合的输入，不是精修过的 bug template，而是用户用自然语言讲出的抱怨。好的输入通常会包含症状、期望结果，以及一些粗略上下文。例如：“我在手机上编辑完草稿后，保存按钮有时没反应。” 这样 agent 就足够先问一两个精准追问，然后继续推进。
先阅读这些文件
先看 SKILL.md，再检查 README.md、AGENTS.md、metadata.json，以及任何 rules/、resources/、references/ 或 scripts/ 目录。对于这个仓库来说，关键文件是 skills/deprecated/qa/SKILL.md；没有配套脚本或参考目录，所以这个 skill 主要依赖该文件里的说明，以及你自己的仓库上下文。
按这个顺序推进会话
推荐一个简单流程：先让用户解释问题，再最多问 2-3 个澄清问题，同时在后台浏览代码库，确认领域术语和行为边界，最后再整理 issue。如果报告里其实包含多个失败点，先拆开再写，这样最终生成的 GitHub issues 才仍然可执行、可跟进。
qa skill 常见问题
qa 只用于 GitHub issue 提交吗？
基本上是的。qa skill 的目标，就是把对话式 bug 报告转换成带足够上下文、以后还能派上用场的 GitHub issues。如果你需要的是调试、代码修改或分诊决策，通常要换别的工作流。
qa 和普通 prompt 有什么区别？
普通 prompt 往往会过度收集细节，或者只写出一段比较空的总结。qa skill 会把交互限制住：只问少量澄清问题、在后台浏览代码库，并用项目的领域语言来写 issue。这让它在 Issue Tracking 相关的 qa 场景里，比一次性的 prompt 更强。
新手需要很深的仓库知识吗？
不需要。这个 skill 的设计目标就是减少猜测成本。新手可以直接用自己的话描述症状，让工作流自动提取重点。最主要的要求是：问题必须足够可观察、可讨论。
什么时候不该用 qa？
如果问题纯属推测、还没有任何用户可见症状，或者你已经明确需要的是修复方案而不是 issue，就不要用 qa。那种情况下，通常调试或规划类 skill 会更合适。
如何改进 qa skill
先给出最清楚的症状
当第一条消息里就包含可见故障、期望行为，以及尽可能窄的上下文时，qa skill 生成的 issue 会更好。“Export fails” 不如 “在 Firefox 上先加第二个 filter 再点 Download 后，导出才会失败” 有效。更具体的描述会同时改善澄清问题质量和最终 issue 标题。
把一个 bug 和多个问题分开
常见失败模式是把多个问题揉进一条抱怨里。如果一条报告同时混有 UI glitch、性能卡顿和数据缺失，后续 triage 会更难。先按用户影响和复现路径拆分，再让 qa skill 去提交 issue。
补充复现步骤和边界条件
如果你已经知道复现步骤，就直接说出来。如果 bug 是间歇性的，说明发生频率、设备、浏览器、账号状态或数据集大小。这些信息能帮助 qa skill 判断它是单一问题、某种模式，还是更广泛的故障。
对 issue 草稿做迭代
第一版草稿出来后，检查措辞是否耐久、是否面向用户、是否去掉了实现细节。如果它听起来还是像聊天记录，就再要求一个更紧凑的标题、更清晰的“期望 vs 实际”表述，或者把内容拆成更干净的多个 issue。