TC 審查工作流程
目錄
- 進度檢查清單
- 紀律
- 鐵律
- 優先拒絶（前置條件閘門）
- 步驟 1 — 逐字載入兩個來源（中等自由度）
- 步驟 2 — 建立追溯矩陣（中等自由度）
- 步驟 3 — 案例品質檢查（中等自由度）
- 步驟 3b — 在「詢問產品負責人 / 報告者」前進行來源掃描（強制）（低自由度）
- 步驟 4 — 報告「良好」與「需改進」（中等自由度）
- 步驟 5 — 通知專案的 TC-review 頻道（低自由度）
- QA 結案（完成前強制執行）（低自由度）
- 技能組合
- 不適用範圍
- 必須 / 絕不
- 必讀文件
- 依賴項目
評判他人已撰寫的測試案例文件——此工作流程從不自行設計或編輯測試案例。它回答一個問題：此文件，按原樣撰寫，是否能證明票證的 AC/EC 和業務規則將被檢查？
斜線命令捷徑（支援命令的執行環境）：/tc-review → commands/tc-review.md。
進度檢查清單
在工作開始時將此區塊複製到您的回應中，並在完成每個項目時勾選。如果某個閘門失敗，則返回其「返回至：」行所指明的步驟——並從該處取消勾選。
TC 審查進度：
- [ ] 優先拒絶（前置條件閘門）
- [ ] 步驟 1 — 逐字載入兩個來源
- [ ] 步驟 2 — 建立追溯矩陣
- [ ] 步驟 3 — 案例品質檢查
- [ ] 步驟 3b — 在「詢問產品負責人 / 報告者」前進行來源掃描（強制）
- [ ] 步驟 4 — 報告「良好」與「需改進」
- [ ] 步驟 5 — 通知專案的 TC-review 頻道（僅詢問討論串）
- [ ] QA 結案（完成前強制執行）
紀律
遵循 shared-preamble.md 和 shared-must-never.md。
鐵律
沒有引用雙邊來源，就沒有發現
每個發現都比較本次工作階段中實際開啟的兩個事物：TC 文件本身的文字，以及票證本身的 AC/EC/業務規則文字（或設計來源，如 Figma/PRD，僅在其實際開啟後）。從一般的品質感覺認為「TC 看起來不完整」，但沒有在旁邊引用票證的原始措辭，這不是一個發現——請閱讀票證，然後再判斷。未在本次工作階段中實際開啟來源的設計來源聲明（精確複製文字、精確 UI 狀態）也不是一個發現——請說「無法驗證——無法開啟 {來源}」而不是猜測。
這是 catch-ai-workflow 用於檢查已完成工作的相同紀律；此工作流程是其特定於 TC 的實例，在執行前（而非執行後）執行。
優先拒絶（前置條件閘門）
如果缺少以下兩者，則不得開始：
- TC 文件 — 一個試算表、CSV 或 Markdown 檔案，可在本次工作階段中存取和讀取；
- 管轄票證 — 一個承載 AC/EC（或使用者明確指定的等效規格來源）的 Jira 問題金鑰或 URL。
🔴 停止 — 缺少任一項，根據 skill-rules-style.md 在一則訊息中停止。
跨組織 / 跨站點票證： 如果票證位於已連接的 MCP 未被授予存取權限的 Atlassian 站點上，請明確說明並要求使用者授予存取權限（或直接貼上 AC/EC）——切勿猜測 cloud id，切勿使用瀏覽器登入來讀取票證。
步驟 1 — 逐字載入兩個來源 [中等自由度]
- TC 文件 — 按其實際內容讀取；不要重新輸入、總結或在載入時「清理」措辭。記下確切來源（試算表 id + 分頁/gid、檔案路徑或 URL），以便後續的每個引用都能指向它。
- 票證 — 從票證自身的欄位（描述、自訂欄位——有些專案將內容完全放在
description之外；請檢查兩者）中擷取 AC、EC 以及任何業務規則 / 重新檢查清單章節。逐字引用 AC/EC 的標籤和文字；切勿根據對類似票證的記憶進行改寫。在任一位置都找不到 AC/EC → 根據優先拒絶閘門停止。找到規格文字，但其項目沒有 AC/EC 標籤 → 🔴 停止 — 顯示找到的文字，並在步驟 2 之前詢問使用者如何為其編號；切勿自行發明標籤。 票證或 TC 文件擷取錯誤、超時或返回部分內容（文字被截斷、缺少欄位、無法載入的分頁）→ 將確切的錯誤或缺少的內容告知使用者，不要根據部分的 AC/EC 或部分的 TC 文件建立矩陣，將失敗移交給superpowers:systematic-debugging，並僅在完整文字載入後才恢復步驟 1。 - 如果連結了設計來源（Figma、PRD）且使用者想要交叉檢查，請在本次工作階段中打開它。如果無法打開（沒有工作階段、沒有存取權限、唯讀且未呈現內容），請直接記錄下來——它會變成與相關發現旁邊的「無法驗證」註記，而不是默默地跳過。
步驟 2 — 建立追溯矩陣 [中等自由度]
對於票證上的每個 AC 和 EC，列出聲稱涵蓋它的 TC 行：
| AC/EC | 聲稱者 | 狀態 |
|---|---|---|
AC_01 | TC_003 | 已涵蓋 |
AC_05 | — | 無 TC — 缺口 |
AC_02 | TC_007 | 標籤錯誤 — TC_007 的預期結果符合 AC_04 |
EC_01 | TC_010, TC_011 | 標籤不一致 — 同類 TC_012 測試相同元素但無標籤 |
狀態是一個封閉的清單 — 每行只能使用以下四個值之一，並依所示方式命名 id：
已涵蓋 · 無 TC — 缺口 · 標籤錯誤 — <TC id> 符合 <AC/EC id> · 標籤不一致 — <TC ids>。
如果一行有多個問題，則按 已涵蓋 之後的順序採用第一個適用的。票證自身 AC 清單中的漏洞是規格層級的缺口，而不是矩陣行——在「需改進」中以規格問題的形式報告（請參閱「必須 / 絕不」）。
已劃掉的 AC/EC 不計入。 票證中已劃掉的行（例如 -AC_07-，通常標記為重複）不在範圍內：將其排除在矩陣和報告之外。不要提及它，即使是「正確地未涵蓋」也不要提及。
業務規則和票證評論是上下文，不是額外的 AC。 閱讀它們以了解 AC/EC 的含義，並用它來判斷 TC 是否測試了正確的事物。僅當業務規則或評論項目與 AC/EC 衝突時才報告，並指明它與哪個 AC/EC 矛盾。沒有 TC 但未與任何 AC/EC 矛盾的規則或評論不是一個發現。將其排除在「需改進」之外，也不要為其添加「規格備註」章節。
標記以下情況，並指明相關的行/AC id：
- 一個沒有 TC 的 AC/EC；
- 一個 TC 的預期結果可被驗證地符合其標記的 不同 AC；
- 同類行之間（例如共享的 UI 元素）標籤不一致——有些帶有 AC，有些沒有，且沒有說明原因。
步驟 3 — 案例品質檢查 [中等自由度]
對每一行套用 tc-quality-standards.md，尋找以下特定於審查的失敗模式（與編寫品質不同——這裡是關於別人寫的文件，所以問題是它是否可被信任，而不是它是否優雅）：
| 信號 | 為什麼重要 |
|---|---|
| 步驟未達到標題所聲稱的狀態。 標題為「學習者檢視 X」的行，其步驟在主頁面停止，從未實際打開 X。 | 該案例無法驗證它所聲稱要驗證的內容。 |
| 預期結果是 AC 自己的句子，逐字複製，沒有分解。 當票證在該 AC 下列出了幾個具體的子項（欄位、狀態、按鈕變體）時，僅僅重複 AC 句子的預期結果無法讓測試人員逐行檢查。 | 通過/失敗變成猜測。 |
| AC 列舉了已命名的案例/狀態（例如「案例 1–6」、「載入 / 空 / 篩選」狀態）而文件只為所有這些寫了一個通用的行。 | 即使該行被標記為完成，大多數列舉的狀態也未經測試。 |
| 測試數據在 AC 需要具體值的地方沒有具體值（邊界計數、特定的日期關係、命名的篩選選項）。 | 該行無法按原樣執行——測試人員將不得不憑空發明缺少的值。 |
| 該行測試的條件與 AC 的措辭不同。 AC 說「已經滾動過去」但該行使用「觀看到最後」。AC 說「僅限已發布的項目」但預期結果從未檢查狀態。 | 該行可能通過，而 AC 自身的條件仍未測試。 |
| 預期結果比該行自身的測試數據所允許的更加模糊。 測試數據提供了計算答案所需的所有輸入（分數、計數、公式），但預期結果只說「排序正確」。 | 測試人員必須在執行過程中自行計算預期值，因此錯誤的順序仍可能被標記為通過。 |
| 該行的欄位相互矛盾。 前置條件說「4 個項目」但測試數據只列出 3 個。標題說「狀態」但預期結果僅檢查順序。 | 無論測試人員遵循哪個欄位，另一個欄位都是錯的。 |
| 某個票證前置條件未出現在任何行中（例如「使用者已登入」）。 | 每一行都繼承了一個未說明的設定步驟。 |
| 設定命名了一個方法但沒有提供（「有一種方法可以使請求失敗」、「準備足夠的資料」）。 | 兩個測試人員會以兩種不同的方式進行設定。 |
不要標記不影響案例是否可被信任的測試案例風格選擇（命名慣例、欄位順序、優先級標籤），除非使用者特別要求進行風格審查。此處覆蓋 tc-quality-standards.md：忽略其 Priority 屬性和其審查關卡「已分配優先級」行，除非使用者要求進行風格審查。
步驟 3b — 在「詢問產品負責人 / 報告者」前進行來源掃描（強制）[低自由度]
此工作流程從不決定產品判決，但它確實會提出規格層級的缺口和疑問。在任何發現變成「詢問產品負責人 / 報告者」或「規格不明確」之前，請執行 result-quality-gate.md 第 14 層的來源掃描：預設分支上的產品程式碼，包含 path:line、其內嵌註解和 git log -L / blame；主票證及其所有評論；相關票證（父項 / 史詩、已連結的、相同畫面或 API 上的同類，以及提交訊息中命名的票證）；回歸結果；以及設計節點。在發現旁邊引用讀取的內容。來源已經回答的問題是一個帶有來源的發現，而不是一個問題。
產品克隆缺失或無法讀取（dependencies.md 中的 {MONOREPO} 檢查失敗）：不要停止審查，也不要默默跳過程式碼層。在每個程式碼層本應回答的問題旁邊寫上 未檢查程式碼 — 無克隆，繼續使用其餘來源進行掃描，並且永遠不要將此類問題呈現為掃描完成——它會帶著該註記進入步驟 4。
每個項目的輸出：發現（或剩餘的疑問）+ 帶有其位置的引用來源（path:line、票證金鑰 + 評論、回歸行、設計節點），或者當程式碼層無法執行時的 未檢查程式碼 — 無克隆 註記。
返回至： 掃描已回答的問題將作為附有來源的發現返回步驟 2 或 3；只有沒有來源回答的問題才會作為「與開發者/產品負責人確認」進入步驟 4。
步驟 4 — 報告「良好」與「需改進」[中等自由度]
兩個簡短的清單，每個項目都附有行 id、AC id 或引用的文字——絕不允許沒有錨點的意見。
**良好**
- {發現，附上 TC/AC id 或引用}
**需改進**
- {發現，附上 TC/AC id 或引用}
→ 建議：{如何修復}
每個「需改進」項目都帶有一個「→ 建議：」行，說明如何修復。沒有修復建議的問題會讓 TC 編寫者無所適從。每個建議必須來自某個來源，絕不能是發明的值：
- 從該行自身的數據計算得出： 當測試數據已經包含輸入時，計算出該值並提供（例如，附上每個計算分數的預期順序）。顯示數字以便編寫者可以檢查。
- 取自 AC/EC 措辭： 例如，用 AC 自己的措辭替換錯誤的條件，或使用 AC 自己的文字添加缺少的預期結果子句。
- 沒有來源給出該值（票證從未說明的閾值、計數或時間）：建議添加該值，並說明誰來確認它（「與開發者/產品負責人確認計數」）。切勿憑空捏造數字。
保持每個項目簡潔。建議說明要更改的內容，而不是重寫一行。如果使用者要求縮小範圍（例如「刪除所有關於 X 的內容」），則從步驟 2-3 中移除該類別並重新生成清單——不要被動地手動編輯文字，因為相同的類別下次會以不同的措辭重新出現。
語言： 預設情況下，使用與票證 / TC 文件相同的語言。如果混合使用（票證的 AC/EC 和 TC 文件使用不同語言）→ 詢問使用者一次要以哪種語言撰寫審查。Helix 選單和入職問題保留英文，依循 user-communication.md；審查內容本身則遵循目標文件的語言，這是該文件已承載的相同例外情況。
在執行步驟 5 傳送之前，先在聊天中發布審查結果——外部訊息不像聊天訊息那樣可以取消傳送。步驟 5 的討論串問題是進行下一步的信號；請勿添加單獨的「是否傳送？」問題。
步驟 5 — 通知專案的 TC-review 頻道 [低自由度]
每次執行都將完成的審查結果傳送至 TC-review 頻道。
…（以下為截斷內容，完整翻譯需原始完整文件）
QA 結案（完成前強制執行）[低自由度]
（…後續翻譯略）
技能組合
（…後續翻譯略）
不適用範圍
（…後續翻譯略）
必須 / 絕不
（…後續翻譯略）
必讀文件
（…後續翻譯略）
依賴項目
（…後續翻譯略）