idd-continue: resume a half-done issue from its current phase (bridge between idd-list phase detection and phase execution)

[kiki830621]

Problem

Original text:
「我在想可能需要一個idd-continue讓我可以接續，幫我開在idd這個repo裡面」
— Source: user prompt, 2026-09-16 21:19 (+08:00)

Plain-language interpretation：使用者常在一個 issue 走到一半（diagnosed / planned / implemented / needs-fix）時中斷 —— session 結束、context compaction、換機器、隔天回來。目前要接續，人得自己回想「這個 issue 走到哪了」、自己選對下一個 idd-* skill、再把之前 comment 裡的 diagnosis / plan / verify findings 重讀一遍餵給它。提議新增 /idd-continue #N：讀 issue 現況 → 判定 phase → 載入先前 comment 的 context → 直接接著跑下一個 phase。

Type

feature

Priority

P2（排程；使用者措辭是「我在想可能需要」，屬提案，非阻塞）

Gap：既有 skill 各差一步

Skill	已經做到	差的那一步
idd-list	Step 3 從 body **Phase**: 或 comment heading 推 phase，並印 Suggested next（phase × PR state matrix）	只顯示、不執行。人要自己複製那行命令去跑
idd-all	整條 pipeline 串起來跑	只有 from-scratch mode 與 --in-chain；沒有「從 phase X 開始」的入口。對 half-done issue 重跑會從 diagnose 重來，浪費一輪且可能覆寫先前結論
idd-diagnose / idd-plan / idd-implement / idd-verify	各 phase 的 primitive	每個都要人指定；而且中斷後接續的 context（前一輪 diagnosis、plan、verify FAIL findings）散在 comment 裡，靠人記得回頭讀
unattended-contract state file (.claude/.idd/state/unattended.json)	跨 tool-call 持久 unattended 旗標	是 mode 旗標，不是 progress checkpoint；不記錄「走到哪」

一句話：phase 偵測（idd-list）與 phase 執行（idd-all / 各 primitive）之間沒有橋。idd-continue 就是這座橋。

Expected

/idd-continue #N          # 讀 #N → phase → 從對應的下一步接著跑
/idd-continue             # 無參數：取 idd-list Actionable 群裡最近有動靜的 issue，AskUserQuestion 確認

行為草案（待 diagnose 定案）：

1. Phase 判定重用 idd-list Step 3 的規則（body **Phase**: first-match → comment heading fallback → (no phase)），不另起第二套判定 —— bug: closing-summary marker 對 26% 的 closed issue 誤報，而 --retroactive 共用它 → 會貼重複 summary #295 的教訓是同一 marker 多個 consumer 分岔。
2. Phase → next step 對應（與 idd-list Suggested next matrix 一致）：
   • (no phase) / filed → /idd-diagnose #N
   • diagnosed（Simple tier）→ /idd-implement #N；（Plan tier）→ /idd-plan #N
   • planned → /idd-implement #N
   • implemented → /idd-verify #N
   • needs-fix → /idd-implement #N，並把最近一則 ## Verify (FAIL) 的 findings 當 scope 餵進去
   • verified → 停，提示 /idd-close #N（永不 auto-close，同 idd-all 契約）
   • tracking（epic / north-star）→ 拒絕，提示這是 tracker
3. Context 回灌：接續前先讀該 issue 最近的 Diagnosis / Plan / Verify comment，摘要成一段印給使用者確認「這是我們上次停的地方」，再 dispatch。
4. 本地狀態核對：若 phase 是 implemented / needs-fix，檢查 feature branch（idd/N-*）或 worktree 是否存在、有無 uncommitted changes、有無 open PR（reuse gh pr list --head），不一致就 surface 而不是猜。
5. attended 預設；--unattended 沿用 unattended-contract。

Actual

沒有這個 skill。中斷後的接續全靠人腦：idd-list 看 phase → 手打對應命令 → 自己回頭讀 comment。每次中斷都重付一次「重建 context」的成本，而且容易選錯 phase（例如 body 的 **Phase**: 停在 stale 值時，直接跑 idd-all 會重做 diagnose）。

Impact

• 跨 session / 跨機器的 IDD 工作流少一個真正的「resume」動作；目前的 idd-list 只解決「看到」不解決「接上」。
• 對 background job（/loop、bg session）尤其重要：job 被 kill 後（今天 OCR job 記憶體壓力被殺就是實例）沒有一條命令能把 pipeline 從斷點接回去。

Open questions（給 diagnose）

• 是做獨立 skill idd-continue，還是 idd-all --from <phase> / idd-all --resume 的 flag？獨立 skill 的理由：idd-all 的心智模型是「整條跑完」，resume 是「只跑剩下的」，而且 attended 情境下人通常只想接一步、看結果、再決定。
• 「最近有動靜」的無參數模式要不要做，還是 v1 強制給 #N。
• needs-fix 回灌 verify findings 的格式：直接貼 comment 全文，還是只抓 P0/P1 findings。

Clarity Surface(idd-clarify run 2026-09-16T13:21:26Z)

Type	Source	Question for you	Status
ambiguity	"接續"	「接續」是指只跑下一個 phase 然後停下讓你看，還是從斷點一路跑到 verified？	surfaced
ambiguity	"Phase 判定重用 idd-list Step 3 的規則（body **Phase**: first-match）"	當 body 的 **Phase**: 與最新 comment 的 heading 不一致（stale body）時，以哪一個為準？	surfaced
missing-context	"diagnosed（Simple tier）→ /idd-implement；（Plan tier）→ /idd-plan"	tier 要從 Diagnosis comment 的哪個欄位讀？如果那則 comment 沒寫 Complexity，預設走 Simple 還是問你？	surfaced
missing-context	"取 idd-list Actionable 群裡最近有動靜的 issue"	「最近有動靜」的判準是 issue updatedAt、最後一則 comment 時間、還是本地 branch 的最後 commit？	surfaced