手把手用 Supergoal 給 /goal 補規劃層
整理版優先睇
Supergoal 幫你喺 /goal 前面補好規劃，減少返工
用 /goal 最煩嘅一點係個計劃太薄，Supergoal 就係為咗解決呢個問題而出現。佢唔係取代 /goal，而係喺 /goal 執行之前做好規劃工作：拆清楚任務、將階段文件寫到磁盤、做預檢，最後俾一條可以直接貼嘅 /goal 命令。後續執行仍然交俾 /goal 嘅循環。
安裝好之後，Supergoal 會第一步揾記憶目錄，睇下有冇以前留低嘅偏好、項目事實、失敗修復記錄。然後判斷係新項目定老項目，老項目會掃代碼庫，新項目就會問平台、技術棧、設計方向等問題。接着會並行跑環境同代碼掃描，寫 context.md、repo-map.md 等文件，列出 top 3 風險同依賴。階段數量唔係固定，小改動可能得兩個階段，完整項目可以去到 8 至 12 個階段。每個階段都有獨立的 phase-N.md 文件。
寫好計劃之後，Supergoal 會自查一次：驗收標準係唔係可以檢查、階段有冇塞太多嘢、邊種失敗會連帶後面一齊壞。確認之後會跑預檢：build、typecheck、lint、test 等命令會去重後跑一次，只有預檢通過先會輸出 /goal。執行期間有三次失敗處理：第一次自動重試，第二次寫修復規格，第三次暫停交俾你。最後有 Final Audit，回頭對比 ROADMAP 同 Baseline，逐項檢查交付物。我嘅建議係由一個小功能開始試，例如「俾設置頁加一個導出按鈕」，感受嚇佢點問問題、點切階段、點樣寫驗收項。
- Supergoal 補強 /goal 嘅規劃層，唔係取代，而係喺執行前拆好任務、寫定規格。
- 安裝簡單：Claude Code 用 plugin 指令，Codex CLI 就 clone 技能目錄。
- 規劃過程會考慮記憶、項目類型（新/舊），並行掃描環境同代碼，動態生成階段（2-12個）。
- 會自動檢查計劃質素（驗收標準、階段粒度、失敗連鎖），然後跑預檢（build/typecheck/lint/test），確定冇問題先輸出 /goal。
- 執行時有三次失敗處理：自動重試、修復規格、暫停交回。最後有 Final Audit 確保交付物符合要求。
Supergoal 安裝指令（Claude Code）
/plugin marketplace add /plugin install supergoal@supergoal /reload-plugins
Supergoal 安裝步驟（Codex CLI）
mkdir -p ~/.codex/skills git clone /tmp/supergoal-clone cp -R /tmp/supergoal-clone/skills/supergoal ~/.codex/skills/ rm -rf /tmp/supergoal-clone 重啓 Codex
安裝同基本概念
Supergoal 係一個幫 /goal 補強規劃層嘅工具，唔係取代 /goal。佢嘅核心係先將任務拆清楚，寫好階段文件到磁盤，再俾一條你可以直接貼嘅 /goal 命令，後續執行繼續由 /goal 嘅循環負責。
Supergoal 唔係取代 /goal，而係喺 /goal 前面做好規劃準備
- 1 Claude Code 安裝：/plugin marketplace add https://github.com/robzilla1738/supergoal.git，然後 /plugin install supergoal@supergoal 同 /reload-plugins
- 2 Codex CLI 安裝：mkdir -p ~/.codex/skills，clone 倉庫到 /tmp，複製 skills/supergoal 到 ~/.codex/skills/，清走暫存，重啓 Codex
裝好之後就可以用 /supergoal build me an Expo app that converts photos to ASCII art 呢類命令開始規劃。
規劃流程：記憶、掃描同階段生成
Supergoal 第一步會揾記憶目錄，睇下有冇以前留低嘅偏好、項目事實、失敗修復記錄。就算揾唔到都照跑，只係唔會繼承舊資訊。
記憶目錄可以繼承以前嘅偏好同失敗記錄，但唔係必要
然後判斷新項目定老項目。老項目會掃代碼庫，盡量少問問題；新項目冇代碼信號，佢會問平台、技術棧、設計方向、集成項、範圍邊界、目標用戶等，唔係為咗傾偈，而係為咗後續階段唔會切錯方向。
接着進入偵察階段：並行跑環境同代碼掃描，結果寫入 context.md、repo-map.md 等文件，再列出 top 3 風險同依賴關係。階段數量唔係固定，小改動可能得 2 個階段，完整項目可以去到 8 至 12 個階段。真正有用嘅係佢生成嘅文件結構：
.supergoal/<run-id>/
├── ROADMAP.md
├── STATE.md
├── THINKING.md
├── PROTOCOL.md
├── repo-state.sh
├── context.md
├── repo-map.md
└── phases/
├── phase-1.md
├── phase-2.md
└── phase-N.mdROADMAP 係完整路線，STATE 記錄當前狀態同 Baseline ref，THINKING 寫目標、約束、風險、依賴，每個 phase-N.md 都係獨立嘅工作規格。
驗證機制：自查、預檢同失敗處理
寫好計劃之後，Supergoal 會自查一次，主要睇三件事：驗收標準係唔係可以檢查、階段有冇塞太多嘢、邊種失敗會連帶後面一齊壞。發現含糊嘅驗收項會當場改清楚。呢個步驟令計劃更實在。
你確認計劃之後，佢並唔會即刻甩俾 /goal，而係先跑預檢：build、typecheck、lint、test 呢啲命令會去重後跑一次。只有 PREFLIGHT_GREEN 先會打印條 /goal 命令。呢步好重要，如果倉庫本來係壞嘅，直接進 /goal 會令後續執行一直撞牆。
預檢攔住咗本來就壞嘅倉庫，避免 /goal 撞牆
執行期間有三次失敗處理：第一次失敗會插入 probe 自動重試；第二次失敗會寫 phase-N.fix.md 修復規格；第三次失敗就停止，將失敗歷史交俾你。階段驗證仲有清潔度檢查，睇 Git 提交狀態之餘，仲會檢查暫存、未暫存、未追蹤文件，新增 console.log、print、臨時 TODO、死 import 呢啲嘢會被標記，除非階段規格允許，否則階段唔算過。
最後嘅 Final Audit 會回頭讀最早嘅 ROADMAP，重新跑必要命令，逐項檢查驗收標準，仲會用 Baseline ref 同完整工作區比對交付物，補返 AI 可能話完成但實際冇改嘅漏洞。
實際建議同總結
當前版本 v0.7.0 解決咗一個實際問題：兩個 /supergoal 規劃會話如果喺同一個工作區同時跑，以前可能互相覆蓋，而家每次運行都會有自己的 .supergoal/<run-id>/。但要留意，規劃文件唔會互冚，唔代表兩個 /goal 可以喺同一個工作區同時改 code。真係要並行跑兩個任務，建議用唔同 git worktree。
Supergoal 最有價值嘅地方係令 /goal 開始跑之前有一套能落地嘅規格，減少後續返工
如果你平時已經鍾意用 /goal，Supergoal 就係補上規劃層嗰塊拼圖：唔係多一個計劃文件，而係少好多返工嘅機會。
用 /goal 最煩惱嘅一點，係你明明叫佢繼續推，但前面嘅計劃太薄弱。
Supergoal 解決嘅就係呢個問題。
佢唔會取代 /goal。佢先將啲任務拆清楚，將階段性文件寫入磁盤，再畀你一條可以直接貼上嘅 /goal。後面嘅執行仍然交畀 /goal 嘅循環。
先裝。
喺 Claude Code 用呢三行：
/plugin marketplace add https://github.com/robzilla1738/supergoal.git
/plugin install supergoal@supergoal
/reload-plugins
Codex CLI 冇插件市場，直接複製技能目錄：
mkdir -p ~/.codex/skills
git clone https://github.com/robzilla1738/supergoal /tmp/supergoal-clone
cp -R /tmp/supergoal-clone/skills/supergoal ~/.codex/skills/
rm -rf /tmp/supergoal-clone
重啟 Codex，就可以用：
/supergoal build me an Expo app that converts photos to ASCII art
你可以當佢係 /goal 前面嘅準備功夫。
佢第一步會揾記憶目錄，睇嚇有冇你以前留低嘅偏好、項目事實、失敗修復記錄。揾唔到都照行，只係唔會繼承舊資訊。
然後佢會判斷當前任務係新項目定係舊項目。
舊項目會掃描代碼庫，盡量少問問題。新項目冇代碼信號，佢會問平台、技術棧、設計方向、集成項、範圍邊界、目標用戶呢啲問題。唔係為咗傾偈，係為咗後面嘅階段唔好切錯。
接着進入偵察。
佢會並行執行環境同代碼掃描，將結果寫入 context.md、repo-map.md 呢類文件。然後列出 top 3 風險同依賴關係。
呢度有個細節：佢唔會固定生成 3 步或 5 步。
細改動可能得 2 個階段。完整項目可能 8 到 12 個階段。階段數量取決於任務本身，唔係根據模板。
真正有用嘅係佢寫到 .supergoal/<run-id>/ 下面嘅文件：
.supergoal/<run-id>/
├── ROADMAP.md
├── STATE.md
├── THINKING.md
├── PROTOCOL.md
├── repo-state.sh
├── context.md
├── repo-map.md
└── phases/
├── phase-1.md
├── phase-2.md
└── phase-N.md
ROADMAP 係完整路線。STATE 記錄當前狀態同 Baseline ref。THINKING 寫目標、約束、風險、依賴。每個 phase-N.md 都係獨立嘅工作規格。
寫完之後，佢仲會自查一次個計劃。
主要睇三樣嘢：驗收標準係咪可以檢查，階段有冇塞太多嘢，邊種失敗會連帶後面一齊壞。發現含糊嘅驗收項，會即刻改清楚。
然後先至畀你確認。
你確認之後，佢唔會即刻交畀 /goal。佢先跑預檢：build、typecheck、lint、test 呢類命令會去重後全部行一次。只有 PREFLIGHT_GREEN，先會印出條 /goal。
呢一步好重要。
如果倉庫本來就壞咗，直接入 /goal 會令到後面嘅執行循環不停撞牆。Supergoal 先將呢件事攔住。
你拿到 /goal 後，只需要貼上一次。
後面嘅循環大概係咁：讀 phase-N.md，執行，行 SUPERGOAL_PHASE_VERIFY，通過後寫一條非顯而易見嘅記憶，再進入下一階段。
失敗時有三個級別嘅處理。
第一次失敗，插入 probe，自動重試。
第二次失敗，寫 phase-N.fix.md，然後跟住呢個修復規格繼續。
第三次失敗，停止，將失敗歷史交畀你。
階段驗證仲有個好實用嘅清潔度檢查。佢唔只睇 Git 提交，仲會睇暫存、未暫存、未追蹤嘅文件。新增 console.log、print、臨時 TODO、死 import 呢啲嘢會俾佢計出來。除非階段規格明確容許，否則階段唔算過。
收尾係 Final Audit。
佢會返轉頭讀返最初嘅 ROADMAP，重新行必要嘅命令，逐項檢查驗收標準，仲會用 Baseline ref 同完整工作區比對交付物。
呢個檢查填補咗一個常見漏洞：AI 喺對話裏面話完成咗，但文件入面冇對應改動。
當前倉庫版本係 v0.7.0。呢個版本修咗一個好實際嘅問題：兩個 /supergoal 規劃會話如果喺同一個工作區同時行，以前可能會寫到同一個 .supergoal/ 目錄互相覆蓋。而家每次執行都會拎到自己嘅 .supergoal/<run-id>/。
留意，規劃文件唔會互相覆蓋，唔代表兩個 /goal 可以喺同一個工作區同時改代碼。
真係要並行行兩個任務，用唔同嘅 git worktree。
我建議你，暫時唔好攞佢嚟行大型項目。揾一個小功能試下：例如“喺設定頁加一個導出按鈕”。睇下佢點樣問問題、點樣切階段、點樣寫驗收項、預檢會唔會過。
你會好快知道佢適唔適合你。
如果你平時已經鍾意用 /goal，Supergoal 最有價值嘅地方係：佢令到 /goal 開始行之前，先有一套可以落地嘅規格。唔係多一個計劃文件，而係少好多後面返工。
用 /goal 最煩的一點，是你明明讓它持續推進，但前面的計劃太薄。
Supergoal 解決的就是這個問題。
它不替代 /goal。它先把任務拆清楚，把階段文件寫到磁盤裏，再給你一條可以直接粘貼的 /goal。後面的執行仍然交給 /goal 的循環。
先裝。
Claude Code 裏用這三行：
/plugin marketplace add https://github.com/robzilla1738/supergoal.git
/plugin install supergoal@supergoal
/reload-plugins
Codex CLI 沒有插件市場，直接複製技能目錄：
mkdir -p ~/.codex/skills
git clone https://github.com/robzilla1738/supergoal /tmp/supergoal-clone
cp -R /tmp/supergoal-clone/skills/supergoal ~/.codex/skills/
rm -rf /tmp/supergoal-clone
重啓 Codex，就能用：
/supergoal build me an Expo app that converts photos to ASCII art
你可以把它理解成 /goal 前面的準備工。
它第一步會找記憶目錄，看看有沒有你以前留下的偏好、項目事實、失敗修復記錄。找不到也能跑，只是不會繼承舊信息。
然後它會判斷當前任務是新項目還是老項目。
老項目會掃代碼庫，儘量少問問題。新項目沒有代碼信號，它會問平台、技術棧、設計方向、集成項、範圍邊界、目標用戶這些問題。不是為了聊天，是為了後面的階段別切錯。
接着進入偵察。
它會並行跑環境和代碼掃描，把結果寫進 context.md、repo-map.md 這類文件。然後列 top 3 風險和依賴關係。
這裏有個細節：它不會固定生成 3 步或 5 步。
小改動可能只有 2 個階段。完整項目可能 8 到 12 個階段。階段數量看任務本身，不看模板。
真正有用的是它寫到 .supergoal/<run-id>/ 下面的文件：
.supergoal/<run-id>/
├── ROADMAP.md
├── STATE.md
├── THINKING.md
├── PROTOCOL.md
├── repo-state.sh
├── context.md
├── repo-map.md
└── phases/
├── phase-1.md
├── phase-2.md
└── phase-N.md
ROADMAP 是完整路線。STATE 記錄當前狀態和 Baseline ref。THINKING 寫目標、約束、風險、依賴。每個 phase-N.md 都是單獨的工作規格。
寫完之後，它還會自查一遍計劃。
主要看三件事：驗收標準是不是能檢查，階段有沒有塞太多東西，哪種失敗會連帶後面一起壞。發現含糊的驗收項，會當場改清楚。
然後才讓你確認。
你確認以後，它不會馬上甩給 /goal。它先跑預檢：build、typecheck、lint、test 這類命令會去重後跑一遍。只有 PREFLIGHT_GREEN，才打印那條 /goal。
這一步很重要。
如果倉庫本來就是壞的，直接進 /goal 會讓後面的執行循環一直撞牆。Supergoal 先把這件事攔下來。
你拿到 /goal 後，只需要粘貼一次。
後面的循環大概是這樣：讀 phase-N.md，執行，跑 SUPERGOAL_PHASE_VERIFY，通過後寫一條非顯而易見的記憶，再進入下一階段。
失敗時有三檔處理。
第一次失敗，插入 probe，自動重試。
第二次失敗，寫 phase-N.fix.md，然後按這個修復規格繼續。
第三次失敗，停止，把失敗歷史交給你。
階段驗證裏還有一個很實用的清潔度檢查。它不只看 Git 提交，也看暫存、未暫存、未追蹤文件。新增 console.log、print、臨時 TODO、死 import 這類東西會被算出來。除非階段規格里明確允許，否則階段不算過。
收尾是 Final Audit。
它會回頭讀最早的 ROADMAP，重新跑必要命令，逐項檢查驗收標準，還會用 Baseline ref 跟完整工作區比對交付物。
這個檢查補上了一個常見漏洞：AI 在對話裏說完成了，但文件裏沒有對應改動。
當前倉庫版本是 v0.7.0。這個版本修了一個很實際的問題：兩個 /supergoal 規劃會話如果在同一個工作區同時跑，以前可能寫到同一個 .supergoal/ 目錄互相覆蓋。現在每次運行都會拿到自己的 .supergoal/<run-id>/。
注意，規劃文件不會互相覆蓋，不代表兩個 /goal 可以在同一個工作區同時改代碼。
真要並行跑兩個任務，用不同 git worktree。
我的建議是，先別拿它跑大項目。找一個小功能試：比如“給設置頁加一個導出按鈕”。看它怎麼問問題、怎麼切階段、怎麼寫驗收項、預檢會不會過。
你會很快知道它適不適合你。
如果你平時已經喜歡用 /goal，Supergoal 最有價值的地方就是：它讓 /goal 開始跑之前，先有一套能落地的規格。不是多一個計劃文件，而是少很多後面返工。