agentsclimarketplace

Pdca process review

Skill goingli0324/pdca-process-review

用 PDCA(Plan-Do-Check-Act,戴明循環)系統性檢視與優化任何反覆執行的流程或工作方式。當使用者要求「用 PDCA 檢視/分析/優化某個流程」「這個流程哪裡卡住、怎麼改善」「幫我做一次流程復盤」「持續改善」,或提到 PDCA、戴明循環、Deming cycle、Plan-Do-Check-Act 等詞彙時,務必觸發。也要主動用於這種情境:使用者描述一個自己反覆在做、但成效不如預期或執行起來很亂的流程(不論是研究方法執行、教學/評審工作、行政作業、專案管理、還是個人習慣),想要找出問題根源並規劃下一步調整——即使對方沒有講出「PDCA」這個詞。不限定領域,適用任何重複性流程的檢視與優化。From its SKILL.md

Install
npx -y skills add goingli0324/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

  • 22 days oldThe repository was created 22 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.

SKILL.md

6.3 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 的原始材料後,再產出完整報告。

What ships with it: 2 files

2.3 KB alongside SKILL.md

Keep looking

Skills are one crate of 326,452. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.