Pdca process review

Skill goingli0324/muzi-going-skills/plugins/pdca-process-review/skills/pdca-process-review

Muzi Going 的 Claude skills 商店 — Claude Code plugin marketplace

Install

npx -y skills add goingli0324/muzi-going-skills --skill pdca-process-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

17 days oldThe repository was created 17 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

用 PDCA（戴明循環）檢視與優化任何反覆執行的流程。當使用者提到 PDCA／戴明循環／Deming cycle，要求流程復盤或持續改善，或描述一個自己反覆在做、但成效不如預期或執行起來很亂的流程並想找出卡點時觸發。不限領域，但檢視的是流程，不是單一決策。

SKILL.md

5.9 KB, ~2.7k tokens by cl100k_base, as published. Nobody here has run it

PDCA 流程優化循環

核心理念

PDCA 的價值不在「診斷一次」,而在「形成迴圈」。檢視流程最常見的失誤,是把 Check 階段發現的落差寫成一份漂亮的建議清單就結束了,沒有把它接回下一輪的 Plan。這個 skill 的任務,是確保每一次產出都是完整的一圈,而且明確指出下一圈 Plan 該從哪裡開始——不是句點,是迴圈。

同樣重要的是:PDCA 檢視的是「流程」,不是「單一決策」。如果使用者要問的是「A 方案還是 B 方案」這種一次性抉擇,那不是這個 skill 的範圍(見文末「與其他 skill 的分工」)。

先判斷:資訊夠不夠,決定走哪個模式

收到請求後,先看使用者提供的內容夠不夠支撐直接分析,不要預設一定要先問一輪問題,也不要不問就硬寫。

使用者提供的內容	走哪個模式
已經講清楚流程步驟、目前做法,且至少能看出「哪裡出問題」或「成效如何」	診斷分析模式:直接產出完整 PDCA 分析,不需要再問一輪
只說「我想優化 XX 流程」,但沒說目前怎麼做、有沒有目標或指標	互動引導模式:先用工具一次問 1-2 個最關鍵的問題,把 Plan / Do / Check 三階段的原始材料補齊,再產出 Act
使用者明確說「直接幫我分析就好,不要一直問」	診斷分析模式,缺的部分用假設帶過並明講是假設

互動引導時,善用 ask_user_input_v0 這類工具讓使用者用選的而非打字回答,一次別問超過 2 題,問完一輪就先摘要你聽到的內容再問下一輪,直到四個階段的原始材料都夠了為止。追問順序建議:先確認 Plan(目標/現況)→ 再問 Do(實際執行落差)→ 再問 Check(怎麼評估、結果如何),最後由你來寫 Act,不需要使用者自己講出優化建議。

四階段:每階段要回答什麼

Plan 計畫

這個流程真正要達成的目標或成功標準是什麼?盡量具體、可衡量,不要停在「讓流程更順暢」這種模糊說法。
目前(或原本設計)的做法與步驟是什麼?
有沒有明確指標可以衡量成效?如果沒有,先幫使用者定義一個暫時可用的指標,並註明這是推測。

Do 執行

實際執行時,有沒有偏離原本計畫?偏離的地方通常比計畫本身更有診斷價值。
過程中出現哪些意外狀況、卡點、或者不同執行者做法不一致的地方?

Check 檢核

用什麼方式評估成效?結果如何?
結果與 Plan 階段設定的目標/指標之間,落差在哪?這個落差是系統性的(每次都發生)還是偶發的(特定情境才出現)?兩者的優化方向完全不同,不要混為一談。

Act 行動

哪些做法已經證明有效,值得標準化、固定下來成為新的預設做法?
哪些做法無效或造成問題,需要修正、簡化、或直接放棄?
**這一輪學到的東西,具體會怎麼餵回下一輪的 Plan?**這一項不能省略——沒有這一項,PDCA 就斷成一次性建議清單,不是迴圈。

產出格式

不論走哪個模式,最終都收斂成這樣的結構化報告(標題可依語境微調用詞,但四階段+風險+下一輪起點的骨架不變):

【Plan 計畫】
目標/成功標準:...
目前做法:...
衡量指標:...(若為推測,註明「此為推測指標」)

【Do 執行】
實際執行狀況與落差:...

【Check 檢核】
評估方式與結果:...
與目標的落差:...(區分系統性/偶發性)

【Act 行動】
值得標準化的做法:...
需要修正或放棄的做法:...
下一輪 Plan 的起點:...

【風險與限制】
...

寫作時注意:

Check 階段如果證據不足以下定論,誠實呈現「目前資料無法判斷」,不要為了讓報告看起來完整就腦補一個確定的結論。
【風險與限制】不是形式上的免責聲明,而是真的指出這份分析可能哪裡站不住腳(例如樣本太少、指標本身可能有問題、外部條件可能改變)。
遇到 Check 階段結果可以有不同解讀時,呈現多元角度,不要只給單一定論式的說法。
避免「總結來說」「值得注意的是」「in conclusion」這類 AI 慣用語;論證性的段落用連貫段落寫,條列只用在真的是並列項目的地方。
預設用繁體中文回應;若使用者原本用英文提問,則用英文,四階段名稱(Plan/Do/Check/Act)可視情境雙語並陳。

與其他 skill 的分工

如果使用者要問的是「A 還是 B」這種一次性抉擇,不涉及反覆執行的流程,那是 multi-perspective-panel(多角度壓力測試)或一般判斷,不是這個 skill。
如果使用者的請求本身還很模糊,連「要優化什麼流程」都講不清楚,可以先借用 prompt-coach 的追問邏輯把目標問清楚,再回到這個 skill 走 PDCA。
這個 skill 檢視的是「流程本身」,不評分某一次具體作品或表現(那是 ai-course-reviewer 的範圍)。

使用範例(示意)

診斷分析模式 使用者:「我們每週三開的內容會議,流程是先各自報告進度、再開放討論,但常常討論到一半就沒時間收斂,決議也很少真的追蹤執行。這樣開了半年,想優化一下。」 → 資訊已經足夠(現況、卡點都講了),直接進入診斷分析模式,產出完整四階段報告。

互動引導模式 使用者:「幫我用 PDCA 檢視我批改學生作業的流程。」 → 只有意圖,沒有現況細節,先問 1-2 題(例如:「目前批改時主要看哪些面向?有沒有遇到評分標準前後不一致的狀況?」),補齊 Plan/Do/Check 的原始材料後,再產出完整報告。