qa 是一個互動式 QA skill，可將對話式 bug 回報轉成可長期保存的 GitHub 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 概觀
qa skill 適合互動式 QA 會話：當使用者用口語方式回報 bug、令人困惑的行為或產品問題時，agent 會把這些資訊整理成一則可長期使用的 GitHub issue。它特別適合想要提升 bug report 品質、但又不想逼使用者用 issue template 語言填寫的團隊。
qa 的用途
在 qa skill 裡，真正要做的是把一則雜亂的回報，整理成清楚的 issue：使用者原本期待什麼、實際發生了什麼、能不能重現、以及涉及到產品邊界的哪一部分。當你需要的是像產品品質 issue 的文字，而不是原始聊天紀錄時，這個 skill 尤其適合做為 qa for Issue Tracking 的流程。
qa 為什麼不一樣
qa skill 的主要價值，不是當下立刻把 bug 修掉。它會幫 agent 只問少數幾個針對性的問題、在背景中讀取 codebase 取得脈絡，並用專案自己的語言來建立 issue。當你要的是 issue 品質，而不只是摘要品質時，它會比通用 prompt 更合適。
最適合與不適合的情境
qa skill 最適合用在使用者能描述可見問題、regression、邊界案例，或某個流程已經壞掉的情況。如果你已經有完整重現步驟、只需要 root-cause 分析，或這個工作本來就不是要變成 GitHub issue，這個 skill 的適配度就比較弱。
如何使用 qa skill
在 repo 中安裝 qa
使用 npx skills add mattpocock/skills --skill qa 安裝 qa skill。把它當成一個 session workflow，而不是一個 library：安裝完成後，當使用者說自己在做 QA、回報 bug，或希望從口語回報中協助建立 issue 時，就使用它。
先從粗略的使用者回報開始
qa skill 最有效的輸入，不是打磨過的 bug template，而是使用者用自然語言說出的抱怨。好的輸入通常會包含症狀、預期結果，以及一些大致脈絡。例如：「在手機上編輯草稿後，儲存按鈕有時候完全沒反應。」這樣就足夠讓 agent 先問一兩個關鍵追問，再繼續往下處理。
先閱讀這些檔案
先從 SKILL.md 開始，再查看 README.md、AGENTS.md、metadata.json，以及任何 rules/、resources/、references/ 或 scripts/ 資料夾。對這個 repo 來說，關鍵檔案是 skills/deprecated/qa/SKILL.md；沒有支援腳本或 reference 資料夾，所以這個 skill 主要仰賴該檔案中的指示與你自己的 repo 脈絡。
依這個順序執行流程
建議用這個簡單流程：先讓使用者說明問題，最多只問 2-3 個釐清問題，接著在背景中探索 codebase，掌握領域用語與行為邊界，最後再建立 issue。如果回報其實包含多個失敗點，就先拆開，再撰寫，這樣產出的 GitHub issues 才會真的能處理。
qa skill 常見問題
qa 只用來建立 GitHub issue 嗎？
大多數情況下是。qa skill 的設計重點，就是把口語化的 bug report 轉成帶有足夠脈絡、之後仍然有用的 GitHub issues。如果你需要的是除錯、程式碼修改或 triage 決策，可能就要改用其他工作流程。
qa 跟一般 prompt 有什麼差別？
一般 prompt 常常會蒐集過多細節，或只寫出很空泛的摘要。qa skill 會把互動範圍收斂住：只問少量釐清問題、在背景中探索 codebase，並且用專案的領域語言來寫 issue。這讓它在 qa for Issue Tracking 的情境下，比一次性的 prompt 更強。
新手需要很懂 repo 嗎？
不用。這個 skill 的目標就是減少猜測。新手可以直接用自己的話描述症狀，讓流程去萃取重點。主要前提是，問題必須是看得見、說得清的。
什麼情況下不該用 qa？
如果問題純屬推測、還沒有使用者可見的症狀，或你其實已經知道自己要的是修正方案而不是 issue，就不要用 qa。這些情況下，除錯或規劃類 skill 通常會更合適。
如何改進 qa skill
先把最清楚的症狀說出來
當第一則訊息就包含可見失敗、預期行為，以及最小必要脈絡時，qa skill 產出的 issue 會更好。「Export fails」不如「只在新增第二個 filter 後、於 Firefox 點 Download 時才會失敗」來得有用。越具體，釐清問題時的提問就越準，最後的 issue title 也越好。
把一個 bug 和多個問題分開
常見的失敗模式，是把好幾個問題包成同一則抱怨。如果一則回報同時混有 UI 異常、效能變慢和資料缺漏，最後的 issue 就會很難 triage。先依使用者影響與重現路徑拆開，再讓 qa skill 去建立 issue。
補上重現條件與邊界
如果你已經知道重現步驟，就直接說。如果 bug 是間歇性的，也要補上發生頻率、裝置、瀏覽器、帳號狀態，或資料集大小。這些細節能幫 qa skill 判斷它是一個單一 issue、某種模式，還是更廣泛的故障。
持續修整 issue 草稿
第一版草稿出來後，檢查文字是否夠持久、夠面向使用者，而且沒有實作細節。如果讀起來還像聊天筆記，就再要求更精準的 title、更清楚的預期與實際落差，或更乾淨地拆成多個 issue。