錯誤尋找活動
選擇一個能揭露新違反保證的實驗，然後根據實驗實際觀察到的結果來分配計算資源。讓發現、重現與分類的成本保持透明。速度是其中一個列出的性能因素，其他因素包括「程式碼覆蓋率應隨時間增長」以及解決阻礙問題，而一個有用的目標「必須在其測試的程式碼中具有良好的覆蓋率」；單純的執行次數並不能證明有效的探索範圍（OSS-Fuzz 整合、覆蓋率，ClusterFuzz 性能、性能因素）。
確立現有能力
讀取實際的目標版本、啟用的建置、測試生成器主體與斷言主體。記錄每個現有測試通道可以執行與觀察的輸入、初始狀態、操作、效果、排程、失敗與配置。檢查排除條件與被拒絕的案例。僅在文件說明的建置/執行環境適用的情況下，才使用覆蓋率或可達性工具；Fuzz Introspector 的文件指出「針對用 C/C++、Python 和 Java 編寫的專案」提供報告，每一種都有各自的建置工具鏈，因此它不是一個通用的後端（Fuzz Introspector、概述與建置工具鏈差異）。對於 JavaScript 或 TypeScript 專案，請閱讀JS 通道清單。
當檢查的實作確實提供了某項能力時，才將其視為已存在的能力。對於已經在使用有效程式生成、跨引擎結果比較與交易歷史的目標，以新名稱添加相同的機制並非提議的進步。應選擇一個未被覆蓋的互動或觀察點：SQLite 的 dbsqlfuzz「同時對 SQL 輸入與資料庫檔案進行變異」，並發現了「先前的模糊測試器遺漏的」錯誤，這是一個同時探索多個維度的具體先例。它是一個「專有的模糊測試器」：應借鏡其機制，而非假設存在公開的工具（SQLite 測試，§2 與 §4.1.3）。
使一個候選方案可執行
在專案現有的實驗記錄中描述該候選方案；不要引入新的服務或強制性的模式。將這些決策與證據路徑記錄在一起。OSS-Fuzz 要求一個目標在短時間的本地執行中「至少要取得一些進展」，而重現需要與報告相符的建置（OSS-Fuzz 整合、模糊測試目標，重現、建置映像檔與模糊測試器）：
- 生成器與缺口： 實際的進入點加上基線所遺漏的失敗空間。
- 保證與預言： 主導的契約、可執行的觀察以及合法/不支援/無法確定的結果。
- 搜索： 生成的值/狀態/操作以及任何受控的排程、故障或配置選擇。
- 試點： 授權的經過時間/工作者/資源限制、重現材料以及將證明下一次分配合理性的證據。
在倍增工作量之前，先設計好觀察方式。Elle 的可追蹤物件揭示了普通覆蓋寫入所隱藏的依賴關係，因為對暫存器的盲目寫入會「破壞歷史」。其推斷也有明確的限制：檢查器是健全的且「接近保證完整性」，並且「我們的方法忽略了謂詞，僅處理個別物件」。一個產生更多無資訊歷史的生成器並不能修復這些限制（Elle，§§3, 4.3 與 9）。使用 correctness-oracles 處理一般契約，並使用下面的專門技能處理特定的模型。
| 缺少的維度或觀察點 | 相關的專門技能 |
|---|---|
| 依賴的 API 物件與合法的操作序列 | stateful-property-testing |
| 可達的瀏覽器或 React UI 狀態（無操作模型），帶有每狀態預言與路徑重現 | ui-state-exploration |
| 具有所需狀態/效果的執行時期有效程式 | semantic-program-generation |
| 獨立執行比較或可證明的執行間關係 | semantic-differential-testing、metamorphic-testing |
| 檢測/搜索機制或保留的搜索材料 | coverage-guided-fuzzing、corpus-evolution |
| 記憶體存取診斷或受控的排程選擇 | native-memory-instrumentation、race-detection-campaigns、schedule-exploration |
| 並行物件或交易保證 | linearizability-checking、transactional-history-testing |
| 部署故障、受控環境或復原邊界 | distributed-fault-testing、deterministic-simulation、crash-consistency-testing |
| 困難的路徑約束或有界不變量 | symbolic-concolic-execution、bounded-model-checking |
| 資源增長、進展、建置互動或數值精度 | resource-complexity-testing、liveness-testing、configuration-differential-testing、numerical-oracles |
此表格指引了這個技能包的職責；它並不表示命名的工具支援該目標。僅閱讀選定的專門技能及其適用的參考資料。使用 harness-sensitivity 來取得證據，證明新的預言能夠到達並拒絕具有代表性的違規案例，最好透過現有的回歸測試或控制組；SQLite 的突變測試「驗證了測試套件能夠捕捉到該突變」（SQLite 測試，§7.6）。將此步驟與實驗成比例，不要變成一個重複的批准環節。
根據試點證據進行分配
在授權的範圍內執行。檢查是否已執行了目標程式碼以及目標屬性；區分不可達的路徑與可達但突變尚未解決的路徑。Fuzz Introspector 比較每個模糊測試器的「靜態可達性潛力」與動態覆蓋率來進行此區分。當缺少的生成器、語義先決條件或觀察是限制因素時，應更改實驗（Fuzz Introspector、概述）。有關診斷，請閱讀試點診斷。
當一個資訊豐富的通道的證據證明需要更多搜索時，則擴展它。在搜索機制不同的互補通道之間進行比較；AFL++ 指出「每個次要模糊測試器都應該有一個變體」（AFL++ 深度，§3.c 使用多核）。使用實際的時間、工作者和資源限制，而不是統一的持續時間或核心數量。將執行時期標誌保留在專門技能中；每個輸入的超時時間、活動持續時間和記憶體限制是不同的控制項（libFuzzer 23.1.0 選項）。
保留屬性評估與語義/程式碼可達性的原始計數、原始候選項目與重現的發現結果、重複項與未知項，以及設定/執行/縮減/分類成本。不要將它們合併成一個發明的生產力分數。當比較性的主張很重要時，應使用匹配的條件和重複的試驗以及變異性；FuzzBench 報告「試驗次數、平均值、中位數、標準」差以及「已達到覆蓋率的分佈」，而不是單一次幸運的執行（FuzzBench 報告、每個基準測試摘要）。
在總結之前，保留原始輸入、起始狀態、來源/建置/配置、檢測、原始輸出和重現選擇。一個 OSS-Fuzz 測試案例「包含饋送給」目標的位元組，而某些錯誤「僅在 32 位元模式或僅在 64 位元模式下」且在報告的消毒器下才能重現；僅一個種子並不是那個完整的構件（OSS-Fuzz 重現、模糊測試目標錯誤與建置映像檔與模糊測試器）。將候選項目導向 failure-reduction 和 evidence-based-triage；讓不可靠或未解決的發現保持可見，而不是默默地計數或丟棄它們。ClusterFuzz 根據重現的可靠性進行過濾，並保留「關於問題發生的頻率以及在何種條件下發生」的統計數據（ClusterFuzz 分類、過濾測試案例與崩潰統計）。
完成分配決策
記錄繼續、更改維度、重現/縮減/分類或停止，並附上觀察到的原因和剩餘空間。一個平台期會促使進行診斷；這既不能證明正確性，也不能證明另一個工具會有幫助。將零發現作為一個有邊界的結果保留下來。一個未處理的候選項目隊列可以證明將下一批預算用於取得證據而不是生成是合理的。對於覆蓋率引導的 libFuzzer 或 AFL 目標，ClusterFuzz 建議當一個目標發現許多新的崩潰時，「修復它們可能比分析性能更重要」（ClusterFuzz 性能、何時分析模糊測試目標性能）。
返回測試過的保證、實際預算、已達到的行為、證據路徑、分類後的發現以及下一個決策。在已確立的情況下描述用戶可見的影響；將可能的原因與已證實的違規行為分開。有關實際的分配和記錄，請閱讀活動示例；有關誤導性的捷徑，請閱讀常見錯誤。
調用此技能應保留用戶現有的範圍和執行規則。它本身並不授權目標更改、安裝、雲端支出、生產環境故障注入或外部發布。