work-loop

/work-loop — 待辦自主推進迴圈

2026-08-05 由 /change-loop（含 --turbo）與 /handoff-loop 合併而成。舊名已移除，無相容 stub。

本 skill 是 loop 四型分類中的 proactive loop——trigger 交給 runner.sh 或 /loop，工作清單交給 scan 自己找。四型分類與通用方法論見 cookbook vendor/snippets/loop-engineering/。

沒有「走哪一支」的判定。 repo 有沒有 openspec/、待辦是 spectra change 還是 tech-debt 條目，都由 Step 2 的 scan 結果決定路由——無 openspec/ 的 repo 掃出來的 spectra 段就是空的，這是正常的，不是 scan 失敗。

核心 contract：每次被叫起來，把待辦盡可能推到「已完成」「可驗收」或「已備妥決策選項」狀態。能自主決策的自主完成；必須人拍板的 NEVER 直接 skip——MUST 走 § Decision packaging 推進到「一句話就能答」的狀態。

Output contract：loop 的 output 是進度報告，不是 user call-to-action。

• ✅ 「<change> 標 🟢 ready-for-review（寫入 HANDOFF）」「TD-317 已修並 commit a1b2c3d」— 報告事實
• ✅ 「本輪處理 3 items：2 completed / 1 packaged。fingerprint 已變，續跑」— 報告進度
• ❌ 「待 user 驗收：請執行 pnpm review:ui」— user call-to-action
• ❌ 「待 user 決定：TD-402 要用 A 還是 B？」— 決策要落 awaiting[] + HANDOFF ## ⏳ Awaiting Charles，不是 chat 敘述（attended 下由 Step 2.7 用 AskUserQuestion 端出去問）
• ❌ 「下一輪可推進：1. ... 2. ...」— 列選單讓 user 決定

---

Step 0 — Mode detection、lock、continuous invocation

$ARGUMENTS

Flags

• --unattended（runner.sh 每輪固定帶）：5-item cap（避免 runaway）+ 禁止 AskUserQuestion。不帶時無 item cap，改由 Step 6 的 round cap / fingerprint 控制。

  裝載準則：cap 之內優先把同一 Location／同一 skill 的 item 併進同一輪。理由是成本不是整齊——runner 每輪起全新 process，而 git snapshot 每輪變動使 always-load 段整段重付一次冷載（約 90k effective tokens），輪數減半即該固定成本減半（[[TD-433]]，前提實測 median 18.6 分 < 1h cache TTL）。NEVER 反過來為了湊滿 5 個而把不相干的 item 拉進同一輪：cap 是上限不是配額，湊數只會讓單輪失敗牽連無關 item。

• --runner-child（只由 runner.sh 帶）：模型可見的 runner child 身分 marker；WORK_LOOP_RUNNER_CHILD=1 是同一身分的機械補強。

• --linked-dispatch-mode foreground（只由 runner.sh 帶）：runner child 內每一筆 decision-linked Pi dispatch 都是同輪 dependency，依 Step 1.5 的 foreground 契約執行；不帶時沿用一般 async watch protocol。

• --min-wakeup-seconds <n>（runner.sh 每輪固定帶，預設 1200；WORK_LOOP_MIN_WAKEUP_SECONDS 是機械補強）：本輪每一個 ScheduleWakeup / Monitor 的 interval MUST ≥ n。帶了它就以它為準，NEVER 因為「這次只等一下下」用更短的值——短輪詢買不到 notification 沒給的東西（Step 0 § (d) 已逐字禁止輪詢進度）。不帶時各處原有的 interval 建議照舊。

• 使用者說「自動推」「把待辦跑完」「持續做」「不要停」「無人值守」→ 等同要求 continuous（見下）。