概念審查
在任何人根據推理或實作規格進行建構之前，判斷其是否站得住腳。保持唯讀，除非使用者另外要求編輯。
從證據開始
- 先取得廉價證據：倉庫狀態、測試、編譯器或型別檢查器輸出、文件、日誌、基準測試、配置以及執行時期行為。推理從證據結束的地方開始；切勿在可以查證時只用推理。
- 遵守要求的修訂版本、分支、範圍和讀取限制。當規格綁定於某個提交時，讀取該提交，而非工作目錄。
- 將每一個引述、數字、倉庫主張和引用的先例視為需要驗證的對象。
- 將每個實質前提標示為觀察、推斷、假設或未知。無法取得的來源是覆蓋缺口，而非確認。
選擇模式
- 推理模式：適用於決策、主張或結論。
- 規格模式：適用於實作者將遵循的實化合約、計劃或簡報。
當規格建立在有爭議的主張上時，同時使用兩者。
推理模式
- 陳述決策或主張。
- 列出其依賴的前提，並按上述方式標示。
- 檢查證據是否支持結論，且無跳過步驟、循環支持或比前提所允許的更多確定性。
- 尋找不可能全部為真的前提。
- 指出最薄弱的關鍵環節。
- 給出最有力的可信反論或競爭解釋。不要使用稻草人謬誤。
- 詢問另一個決策是否能更好地處理關鍵不確定性，包括在必要時考慮可逆性。
- 建議最小的修正：保留、修改、調查一個命名的未知項，或切換方案。
規格模式
檢查什麼可能導致實作或其驗收錯誤：
- 結果： 行為、排除條件和先決條件彼此一致。
- 來源： 引述、範圍、協議規則、公式和外部事實與其主要來源相符。
- 算術： 計數、邊界、矩陣和總和能精確重算。
- 覆蓋率： 每個受影響的呼叫者、測試、介面、不變量、相容性承諾和文件句子都已納入考量。在規格指定的路徑之外執行有界搜尋，但不偏離到無關的架構審查。
- 驗收效力： 每個必要的測試都能針對其所針對的缺陷失敗。控制項有意義，負面案例有可觀察的失敗。
- 執行明確性： 檔案範圍、順序、邊界與失敗行為以及完成證明不留下任何實質性的猜測空間。
- 範圍： 先例和未來工作不會悄然證明超出當前證據所需的範圍。
使用倉庫的嚴重程度術語對發現進行評級，或使用：
- BLOCKING： 可能導致錯誤的實作、錯誤的通過或無可避免的猜測。
- AMEND： 具體的缺口或模糊之處；方法仍然成立。
- NIT： 措辭或證據修正，不改變實作。
輸出
- 以裁決開頭。推理模式：推理站得住腳，或指出什麼地方有問題。規格模式：準備就緒或未準備就緒，並給出決定性原因。
- 然後推理模式只給出重要的內容：關鍵假設、最薄弱環節、最佳反論和建議。
- 然後規格模式按優先級順序給出編號的發現（標題、嚴重程度、確切證據、為何重要、具體修正），以及一個簡短的已驗證清單，列出經得起考驗的重要主張。
- 以信心水準（高、中或低）、最可能改變裁決的證據，以及任何覆蓋缺口或未驗證的來源作為結尾。
規則
- 只提出可能改變決策的點。乾淨的裁決是有效的；切勿製造發現。
- 不要發明證據無法支持的概率或分數。
- 僅在缺失的決策或要求阻礙審查時詢問使用者。自行獲取可用的事實。
- 本次審查不授權實作、編輯或其他後續行動。
- 對於介面和縫合設計，建議使用
$codebase-design而非重做其方法。
基礎：改編自 Anthropic 和 Redwood Research 的概念推理索引工作，作為開發者工作流程。此技能未實作 CRI 或其基準測試。