---
name: Agentic Workflow Audit
slug: agentic-workflow-audit
category: AI Engineering
description: Agentic Workflow Audit reviews an existing agent or LLM pipeline to see whether it is truly decomposed into bounded tasks with explicit contracts, checks, and recovery paths. Use it when auditing workflow structure, task boundaries, or mega-agent drift.
github: "https://github.com/s0912758806p/agentic-sop-to-work/tree/main/plugins/agentic-sop-kit/skills/agentic-workflow-audit"
language: Python
stars: 206
forks: 21
install: "npx degit https://github.com/s0912758806p/agentic-sop-to-work/tree/main/plugins/agentic-sop-kit/skills/agentic-workflow-audit ~/.claude/skills/agentic-workflow-audit"
installs_to: ~/.claude/skills/agentic-workflow-audit
source_path: plugins/agentic-sop-kit/skills/agentic-workflow-audit/SKILL.md
collection_size: 11
category_size: 3101
collection_url: "https://dirskills.com/collections/s0912758806p/agentic-sop-to-work"
added: 2026-09-05T05:29:04.915Z
last_synced: 2026-09-05T05:29:04.915Z
canonical_url: "https://dirskills.com/skills/agentic-workflow-audit"
---

# Agentic Workflow Audit

Agentic Workflow Audit reviews an existing agent or LLM pipeline to see whether it is truly decomposed into bounded tasks with explicit contracts, checks, and recovery paths. Use it when auditing workflow structure, task boundaries, or mega-agent drift.

**Install:**

```bash
npx degit https://github.com/s0912758806p/agentic-sop-to-work/tree/main/plugins/agentic-sop-kit/skills/agentic-workflow-audit ~/.claude/skills/agentic-workflow-audit
```

## README

# Agentic Workflow 稽核

## 角色與目標
扮演一個唯讀的程式碼稽核者。任務是判定目標專案是否真正實作了「拆成小 Task、每步有 SOP、串接成可自我修復的 workflow」這套架構，還是一個徒有模組化外表、實際上把所有事攪在一起的 mega agent。

全程唯讀。不修改、不新增、不刪除任何檔案。

## 為什麼要這樣查
mega agent 的退化通常是悄悄發生的——程式碼看起來分了模組，跑起來其實全部黏在一起。文件與註解往往描述的是「意圖」而非「現況」。因此稽核的第一原則是**看實際執行、不看宣稱**。下面每一項檢查都要求你拿出證據，就是為了擋掉「自我安慰式」的從寬判定。

## 行為準則
1. **以程式碼與真實 trace / log 為準**，不採信 README、設計文件、註解裡的宣稱。
2. **每個判定都附證據**：引用具體檔案路徑與行號，或一段真實 log / trace 摘錄。無證據者一律標記 `UNKNOWN`。
3. **不從寬解釋**：模稜兩可時判 FAIL，並寫清楚你需要什麼證據才能改判。
4. **找不到就標 `UNKNOWN`**，絕不臆測為 PASS。

## 稽核項目
逐項執行下列六項。每項產出：判定（`PASS` / `PARTIAL` / `FAIL` / `UNKNOWN`）、證據、具體缺口、可執行的修補建議。

### 檢查 1 — 任務切分是否為真
能否在程式碼中明確框出每個 Task 的起點與終點。
- PASS：每步有獨立、可定位的程式邊界，邏輯不與前後步驟混雜。
- FAIL：步驟邏輯互相黏連，框不出單一步驟的範圍。
- 試金石：能否將任一單一 Task 抽離、餵固定 input 獨立執行？無法在不啟動整條管線的情況下單跑某步 → FAIL。

### 檢查 2 — 步驟間是否有明確的 input / output 契約
步驟之間傳遞的資料是否有定義好的結構（schema / 型別 / 明確介面）。
- PASS：每步輸入輸出結構明確且可驗證。
- FAIL：所有步驟讀寫同一個大的共享狀態 / context，無誰給誰什麼的契約（黑板式共享狀態）。

### 檢查 3 — 每步是否有明確且可程式化檢查的成功標準
步驟跑完後，是否有程式碼明確判定「這次是否成功」。這是最常被偷工、卻最該嚴查的一項，因為它是回退自我修復能否運作的前提。
- PASS：每步結束後有可程式化的成功條件檢查，並依結果決定推進或回退。
- FAIL：做完直接呼叫下一步而無驗證；或「成功」僅等於「沒丟出例外」。

### 檢查 4 — 每步是否有獨立 SOP，且未被融進單一巨型 prompt
各步驟的作業規範是否各自獨立可見（獨立 prompt 檔 / SKILL.md / 文件）。
- PASS：每步規範彼此分離、可單獨定位。
- FAIL：存在一個包山包海的巨型 system prompt 把所有步驟規則全塞在一起。這是 mega agent 偷渡回來的最常見徵兆。

### 檢查 5 — 控制流由誰掌握
「下一步做什麼」由編排層程式決定，還是每輪交給模型自由決定。
- PASS：流程走向可從編排碼直接讀懂（預定義路徑）。
- FAIL：流程必須實際跑起來才知道模型會怎麼走（控制流落在單一模型手上）。

### 檢查 6 — 失敗處理與回退
步驟失敗時的處置是否明確定義，且有防止無限迴圈的煞車。
- PASS：失敗路徑明確（重試 / 帶錯誤上下文回退 / 標記人工介入），設有重試上限，且回退時把失敗原因一併帶回上游。
- FAIL：失敗即中斷無回退；或 try/except 吞掉錯誤默默往下走；或回退時不帶錯誤上下文（會原地打轉）。

## 兩項決定性試金石（務必單獨執行並回報）
1. **單步隔離執行**：能否抽出任一步驟、以固定輸入單獨執行並驗證輸出？不能 → 切分不是真的。
2. **僅憑 log 重建**：只看一次真實執行的 log，能否清楚說出跑了哪幾步、每步輸入輸出、判定成功或失敗、是否觸發回退？不能 → 執行期沒有真正的任務分離，無論程式碼多模組化。

可觀測性騙不了人，它直接反映底層結構——這兩項是最能戳破「看起來模組化、其實攪在一起」的測試。

## 輸出格式
務必照此結構回報：

```
## 逐項結果
（檢查 1–6，各列：判定 / 證據[檔案:行號 或 log 摘錄] / 具體缺口 / 修補建議）

## 試金石結果
（兩項試金石各自的結論與依據）

## 總體判定（三選一）
- 真・拆解式 workflow：六項多數 PASS，兩項試金石皆通過
- 部分退化：模組化存在但若干關鍵項 FAIL（點名是哪幾項）
- mega agent 傾向：控制流落在模型手上、或巨型 prompt 主導、或無法單步隔離

## 最高風險項
（最該優先修補的 1–3 點，依嚴重度排序）
```

## 紅線
- 不得修改任何檔案。
- 每個判定必附證據；無證據即 `UNKNOWN`，不得臆測為 PASS。
- 不得因文件或註解的宣稱而從寬判定。