---
schemaVersion: 1
slug: gp-218-20260607-supergoal-goal-handoff
ticketId: GP-218
lang: zh-tw
title: Supergoal：把 coding agent 從多輪 babysit，壓成一次 /goal 交接
summary: Supergoal 是一套給 Claude Code 和 Codex 用的 workflow：先用 /supergoal 做深度規劃、寫出 phase specs，再產生一行可直接貼上的 /goal，讓 agent 依序執行、失敗自救、寫回記憶，最後用 audit 收工。重點不是多一個規劃提示，而是把長任務交接做成 protocol。
originalDate: 2026-06-06
translatedDate: 2026-06-07
source: robzilla1738 / Supergoal
sourceUrl: https://github.com/robzilla1738/supergoal
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-218-20260607-supergoal-goal-handoff
status: published
replacementTicketId: null
replacementUrl: null
---

# Supergoal：把 coding agent 從多輪 babysit，壓成一次 /goal 交接

> **來源:** [robzilla1738 / Supergoal](https://github.com/robzilla1738/supergoal)

Coding [Agent](https://gu-log.vercel.app/glossary#agent) 最麻煩的時候，不是它不會寫 code，而是人類得一直站在旁邊餵下一步。

這套 workflow 想把這件事壓成少數幾個固定關卡：先輸入 `/supergoal <要完成的事>`，讓系統偵測 codebase、讀取記憶、分解工作、寫出每個 phase 的規格；人類確認計畫後，它產生一行可直接貼上的 `/goal`。接下來人類貼一次，後面就交給 Agent 依序跑完。

這裡的關鍵不是「幫忙想一份計畫」。普通規劃提示早就會做。這套 workflow 的重點是把計畫從聊天框搬到檔案系統：`ROADMAP.md`、`STATE.md`、`phase-N.md` 都放在 `.supergoal/` 裡，讓後面的執行階段可以讀同一份規格，而不是靠對話上下文硬撐。

> **Mogu 溫馨提示：**
>
> [GP-208](https://gu-log.vercel.app/posts/gp-208-20260509-openai-codex-goals-cookbook/) 講的是 `/goal` 本身：怎麼把「完成」寫成可驗收的條件。這套 workflow 往上多包一層，處理的是 `/goal` 前面的交接問題：如果一件事太大，大到人類也不想手動分 phase、寫驗收條件、整理起始基準，那這套工作能不能也交給 Agent 先做？

## 一次貼上，不是一串接力棒

README 把傳統流程畫得很直白：人類先叫 Agent 寫計畫，拿到第一步，執行，再重新提示，拿第二步，再執行。每一步都要人類回來接球。

這套 workflow 反過來利用 `/goal` 的特性。`/goal` 在 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 和 [Codex](https://gu-log.vercel.app/glossary#codex) 裡都不是長提示容器，而是短的終點條件：執行環境會根據每輪對話紀錄檢查條件有沒有成立；沒成立就繼續。

所以它不把整份長計畫塞進 `/goal`。它只把「直到所有 phase 完成、final audit 通過、印出 `SUPERGOAL_RUN_COMPLETE`」這個終點交給 `/goal`，真正的 phase 細節留在檔案裡。

這個設計避開兩個常見問題：第一，長提示會爆字數或被後面對話稀釋；第二，斜線指令不能自己接自己，因為斜線指令必須由使用者輸入觸發。這套 workflow 承認這個限制：最後一步就是誠實地給人類一行 `/goal`，讓人類貼一次。

貼完以後，執行迴圈才開始。每個 phase 都會讀規格、做事、跑 `SUPERGOAL_PHASE_VERIFY`，再寫回階段記憶。失敗也不是直接裝死：第一次失敗會把探針注入下一輪重試；第二次失敗會寫一份聚焦修復規格並就地修；第三次才停下來交回人類。

---

## 規格放在磁碟上，才像真的工單

`.supergoal/` 下面的檔案，是這套流程比較有意思的地方。

`ROADMAP.md` 放整體計畫，`STATE.md` 記目前進度，`THINKING.md` 放風險、依賴和套用到的記憶，`tools.md` 記這次執行偵測到哪些 [MCP](https://gu-log.vercel.app/glossary#mcp)、搜尋、技能或執行環境能力。真正施工時，每個 phase 都有自己的 `phase-N.md`。

這些檔案讓執行階段不用只靠聊天上下文，而能重讀同一份規格。人類不用一直把前情提要再講一次，Agent 也不用假裝自己永遠記得上下文。狀態寫在檔案裡，下一輪就有東西可以查。

它還會在開始前做啟動前冒煙檢查。也就是先跑一次去重後的必跑指令；如果起始基準本來就是紅的，它會在交付執行前把問題攤開，而不是把 Agent 丟進一個注定三連敗的坑。

最後的 audit 也不是只看「剛剛那個 phase 說有過」。它會重讀原始 `ROADMAP.md`，重跑建置、型別檢查、程式碼檢查、測試這類必跑檢查，並且拿基準參照對照完整工作樹：已提交、已暫存、未暫存、已刪除、未追蹤都算。這是用來抓「Agent 說做完，但其實檔案沒出現」的防呆。

> **Mogu 認真說：**
>
> 這個基準參照很可愛，因為它戳到 Agent 工作流一個很土但很真實的問題：AI 有時候不是做錯，而是「以為自己做了」。人類工程師也會啦，只是人類通常會被 git status 打臉。這套 workflow 把這個打臉流程制度化，算是很健康的羞恥心工程 (◕‿◕)

## Claude Code 是 plugin，Codex 是 skill

安裝方式也透露了現在 Agent 生態的差異。

在 Claude Code 裡，這套工具走 plugin 市集：加入 GitHub 程式碼庫、安裝 `supergoal@supergoal`、重新載入外掛，`/supergoal` 就出現。README 也提醒，如果用 `owner/repo` 簡寫，GitHub SSH 金鑰沒設好可能會失敗，所以 HTTPS URL 比較穩。

在 Codex CLI 裡，沒有 plugin 市集，所以是手動把 `skills/supergoal` 複製到 `~/.codex/skills`。同一套 workflow，到了不同執行環境，包裝層級不一樣：Claude Code 這邊像 [Plugin](https://gu-log.vercel.app/glossary#plugin)，Codex 這邊比較像 [Skill](https://gu-log.vercel.app/glossary#skill)。

它的定位剛好卡在這裡：不是模型，不是 IDE，也不是單純提示庫，而是一套讓 Claude Code 和 Codex 都能照著跑的工作協議。

> **Mogu 插嘴：**
>
> 這其實是我覺得最有趣的地方：Agent workflow 正在長出「可搬移的操作知識」，但平台層還沒完全收斂。有些執行環境用市集管分發，有些執行環境用本機 skills 資料夾，有些能力是內建斜線指令，有些能力靠程式碼庫裡的提示和腳本串起來。這套 workflow 很像站在這個過渡期中間，先把能搬的部分打包起來。

## 適合長任務，不適合小修小補

這套工具的一句話可以寫成：「Plan deeply, then autonomously build until it’s done.」真正適合它的，是跨多個 phase、需要測試或 audit、而且可能需要 Agent 自救的工作：新功能、重構、遷移、效能調整、長研究任務。

如果只是改一行文案、修一個明確 bug、整理一個很小的 PR，用普通提示就好。把小任務硬塞進這套流程，反而像買便當還開採購委員會。

它的賣點不是更會「想計畫」，而是把長任務交接變成可重跑、可檢查、可停下來的協議：人類先確認方向，Agent 照規格跑，失敗有固定處理方式，最後拿 audit 結果收工。