01 / When to use
什麼時候用？
適合計畫已經存在，需要查看進度、找下一步、評估變更或收尾結案時使用。它沿用專案既有的 spec、工單與 tracker，不從零規劃新工作，也不訪談需求或撰寫規格。
查看進度 計畫做到哪了
區分完成、進行中、受阻與可開始，附來源與查詢時點。
下一步 接下來做哪一張
從可開始的工作中挑出最值得做的一張，附上交接內容與入口。
另一條路 新工作還沒有規格
交給專案自己的規劃入口；PM 不訪談、不寫 spec 或工單。
02 / How it works
先看清依賴，
再交給專案入口。
PM 不假設任何特定流程。它依你的意圖選一項能力，從既有紀錄建立目前狀態，再把工作交給專案自己宣告的入口。
依意圖選能力
範圍、計畫、進度、下一步、風險、變更、報告與結案共八項；一次涵蓋多項時，依生命週期的順序執行。
建立目前狀態
讀既有的 spec、工單與 tracker，用 gh 唯讀查詢；標明來源與時點，過期的資料標為過期。
解讀依賴
只依明確寫下的依賴建圖。缺漏、成環與矛盾的狀態列出具體鏈路，受影響的下游不算可開始。
主動核對結案
查相關 PR，包含已合併與已關閉的，分成符合關閉條件、尚有工作與證據不足三類。
找專案入口
依序查專案規則、對話與計畫的上下文、已安裝的 skill（只當建議），都沒有就問你；規則與 skill 衝突時以規則為準。
提出交接
一個具體提案：工單、入口與它的來源、範圍、交付終點。只交出入口宣告能接受的份量。
| 你的回覆 | 它的下一步 |
|---|---|
| 「執行這張」 | 重新核對前置、承接者與分支，讀取所選入口並接續，不要求重貼 prompt。 |
| 「執行這份 spec」 | 只在入口宣告能接受整份 spec 時成立；交出後內部排程歸入口，PM 不再逐張派發。 |
| 「同意」 | 回應明確的執行提案時算選定；回應報告或修改規則的提案時，不算工單執行授權。 |
| 候選不只一張時說「開始」 | 只問要選哪一張，不自行挑選。 |
| 「取消 #11」 | 先評估受影響的下游、可行的選項與可逆程度，等你選擇後才改工單的中繼資料。 |
| 「結案」 | 先確認每張工單已結案，再核對整體驗收與交付終點；都滿足才交出交接清單與回顧，否則列出剩餘工作與需要決定的人，不宣告完成。 |
「執行這張」「執行這份 spec」「同意」「開始」只對 PM 剛提出的具體提案有效；單次交接完成後回報結果，不自動接下一張。
03 / Questions
常見問題
它會另外建一份進度表嗎？
不會。它不另建進度帳本、狀態機或匯入格式，只在你和專案的授權範圍內寫回既有的紀錄來源。tracker 沒有適合的位置時，回報缺口由你決定。
只是看進度，會被當成要開始做嗎？
不會。查看與建議都是唯讀；認同報告不等於授權實作，只有回應明確的執行提案，或你直接要求執行某張工單時，才會接續。
專案沒有寫明入口怎麼辦？
它會從上下文找，再把已安裝的 skill 當成建議提出並說明來源；都找不到時問你，不自行挑一個慣用的流程。
可以讓它一路推進整份計畫嗎？
需要環境提供 active Goal，以及你明確授權它推進指定計畫、選擇實作入口。期間它驗收每份交付，重算可開始的工作再接著做；只來自已安裝 skill 的入口仍會先問一次。
用對的跡象
- 影響選擇的結論都標明已驗證、推論或假設。
- 進度數字附上分母，並說明取消與範圍外的工作怎麼算。
- 提出的入口說明來源：專案規則、上下文，或已安裝的 skill。
- 有可接續的工作時，結尾是一個具體提案；沒有時明說已無工作可接續。
04 / My work
我在這個作品上的工作
我將它從綁定特定流程的版本，改成依專案規則查找專案入口，並擴充成八項可以單獨使用的能力。維護驗收文件中的封裝檢查與行為情境，涵蓋入口衝突、整份 spec 交接與授權邊界。
05 / Boundaries
使用前需要知道
- 持續推進需要環境提供可查詢與管理的 active Goal；沒有時仍可查看進度與逐次交接，但不會宣稱已在背景推進。
- 現有的行為情境驗證在 Claude Code 上抽樣，Codex 與其他宿主尚未測試；完整 Goal 執行與各平台整合的驗證範圍，以 carl-skills 的維護驗收紀錄為準。
- 單次交接只授權那一個工作單位，完成後不會自動接下一張。
- commit、push、merge、發布與 tracker 寫入依既有授權處理；入口內建的寫入步驟不會額外擴大權限。
- 查詢 GitHub 需要已登入的 gh。實作入口不隨本集合附送，交接前要能讀取所選的入口。
- 本頁示例沒有查詢或修改任何工單。
06 / Start here
帶回自己的專案
先閱讀完整流程，確認它和專案既有的規則與工具如何銜接，再按自己的情境安裝。