qa-only

qa-only 概覽

qa-only 是一個僅回報、不修正的 QA skill，適合用在你希望先測試網頁應用、記錄 bug，並蒐集證據，但不做任何修補的情境。qa-only skill 特別適合 QA 審查者、產品負責人，以及需要乾淨 bug 回報流程、而不是「測試－修正－驗證」循環的代理。若你的目標是「找出問題並寫成報告」，qa-only 就很適合；如果你要改程式碼，請改用 /qa。

qa-only 是用來做什麼的

這個 skill 聚焦在結構化的 QA 輸出：健康度評分、截圖、重現步驟，以及清楚的 bug report。它是為「先確認有沒有 bug」和「只測試、不修正」這類需求而設計，能在使用者要的是證據而不是實作時，降低歧義。

為什麼 qa-only 不一樣

qa-only skill 的核心價值在於克制。它會把代理導向回報行為，避免不小心做了修復工作；這在交付物是審查結果、分流註記或交接報告時尤其重要。這也讓 qa-only for Qa 在修正不在範圍內或修正風險較高的環境中特別實用。

適用與不適用情境

當你需要對既有應用做一次 QA 檢查時，尤其是要找 bug、抓 regression，或產出書面評估，qa-only 很適合。若你需要程式碼修改、重構，或反覆修 bug，就不要把它當成通用測試助理；qa-only guide 本來就是以回報優先，不是以修復優先。

如何使用 qa-only skill

安裝並驗證 skill

請使用以 repo 為基礎的安裝流程：npx skills add garrytan/gstack --skill qa-only。安裝後，請先確認 skill 檔案已出現在你的 skills 目錄中，而且可正常讀取，再把它用在正式工作上。只有在代理能於 QA 執行期間實際載入 skill context 時，qa-only install 才真的有用。

給它正確的起始提示

好的 qa-only usage 提示應明確指出應用程式、測試目標、「只要 bug report」的定義，以及邊界條件。較佳的輸入像是：「在 staging 上測試 checkout flow，只回報可見 bug，包含重現步驟與截圖註記，不要提出修正建議。」像「幫我 QA 這個 app」這種說法太模糊，模型會有太多空間去猜測範圍與嚴重度。

先閱讀這些檔案

先從 SKILL.md 開始，再查看 SKILL.md.tmpl，了解生成出來的 workflow 是如何組裝的。因為這個 repo 沒有額外的 rules/、resources/ 或 scripts，這兩個 skill 檔案才是行為、觸發條件與限制的真正依據。如果你想在採用 qa-only 前先弄清楚它的運作，這是最快的路徑。

在實際 QA 流程中使用它

一個好的 qa-only guide 流程是：先定義要測的範圍、整理預期行為、讓 skill 做聚焦審查，然後把輸出整理成 bug 清單或 QA 備忘錄。如果第一次結果太廣，就把範圍縮小到單一使用者旅程、單一裝置／瀏覽器，或單一 release candidate。這個 skill 在任務有明確邊界、回報格式也清楚時最強。

qa-only skill 常見問題

qa-only 只適用於瀏覽器應用嗎？

大致上是。qa-only 主要是為網頁應用的 QA 與 bug 回報而設計，因此很適合 UI 流程、staging 環境，以及可以直接觀察與記錄的使用者旅程。若是只驗證後端，或沒有任何可見產品行為的任務，就沒那麼適合。

它和一般提示有什麼不同？

一般提示也可以要求 QA，但 qa-only skill 會額外帶來一致的回報姿態，以及更明確的「不要修」行為。當團隊需要的是乾淨的 issue report，而不是分析與實作混在一起的結果時，這能減少來回溝通。

qa-only 適合新手嗎？

適合，只要使用者能說清楚應用程式、環境與目標。新手最常犯的錯誤是把範圍講得太模糊；qa-only guide 在你明確告訴它要測什麼、要蒐集什麼證據、不要做什麼時，效果最好。沒有這些資訊，報告可能會太籠統，難以採取行動。

什麼情況下不該用 qa-only？

如果你真正需要的是除錯、修補，或端到端的修正驗證，就不要用 qa-only。另外，如果你需要深入的自動化測試建置、基礎架構工作，或任何依賴寫入程式碼變更的事情，它也不是好選擇。

如何改進 qa-only skill

收緊範圍，並提高驗收訊號的清楚度

要讓 qa-only 的輸出更好，最有效的方法就是定義一個明確目標和一個明確的成功條件。例如：「在 mobile Safari 上測試登入表單，回報驗證失敗問題，包含步驟、預期與實際結果，以及截圖參考。」這會給 skill 一個可衡量的框架，而不是一個模糊的稽核請求。

補上報告應該包含的證據

如果你想要更有用的 qa-only report，就要具體指定要輸出的素材：重現步驟、受影響的 URL 或 route、嚴重度、發生頻率，以及問題是阻斷型、外觀型，還是偶發型。這比單純要求「找 bugs」更好，因為它會迫使產出結構化發現，讓其他人能更快接手處理。

留意常見失敗模式

最常見的失敗模式是覆蓋範圍太大：代理想把所有東西都測一遍，結果報告變得很淺。另一個失敗模式是把修正意圖混進只回報任務裡，削弱了 qa-only 的目的。如果發生這種情況，就把需求重新說成「只回報，不修正，不改程式碼」，並縮小測試面。

從第一輪報告迭代到第二輪驗證

先用第一輪找出可能的問題，再針對最重要的 bug paths 跑第二輪 qa-only。這在第一份報告已揭露某個關鍵流程，但你還想更深入確認邊界情況、瀏覽器差異，或重現穩定性時特別有用。透過迭代，qa-only 會從一次性的提示，變成可靠的 QA 習慣。