# ScheduleWakeup

在 `/loop` 動態模式下排程何時恢復工作。此工具讓 Claude 能夠自主控制任務迭代節奏，休眠指定時間後以相同的迴圈提示詞再次觸發。

## 使用時機

- 在 `/loop` 動態任務中自主控制節奏，迭代間隔取決於工作狀態而非固定時鐘
- 等待耗時較長的建置、部署或測試執行完成後再檢查結果
- 在目前沒有特定訊號需要監視時，在迭代之間插入閒置等待
- 執行無使用者提示的自主迴圈——將字面量哨兵值 `<<autonomous-loop-dynamic>>` 作為 `prompt` 傳入
- 輪詢即將發生狀態變化的程序（使用較短延遲以保持快取熱態）

## 參數

- `delaySeconds`（數字，必填）：距恢復的秒數。執行環境會自動將值限制在 `[60, 3600]` 範圍內，無需手動限制。
- `reason`（字串，必填）：一句簡短的句子，解釋所選延遲時間的原因。顯示給使用者並記錄到遙測資料中。請具體說明——「正在檢查耗時較長的 bun 建置」比「等待中」更有用。
- `prompt`（字串，必填）：喚醒時觸發的 `/loop` 輸入。每輪傳入相同的字串，使下次觸發能重複執行該任務。對於無使用者提示的自主迴圈，傳入字面量哨兵值 `<<autonomous-loop-dynamic>>`。

## 範例

### 範例 1：短暫延遲以重新檢查快速變化的訊號（保持快取熱態）

建置剛剛啟動，通常需要兩到三分鐘完成。

```json
{
  "delaySeconds": 120,
  "reason": "檢查預計約 2 分鐘後完成的 bun 建置",
  "prompt": "檢查建置狀態並回報任何錯誤"
}
```

120 秒的延遲使對話上下文保持在 Anthropic 提示快取中（TTL 5 分鐘），因此下次喚醒更快、成本更低。

### 範例 2：較長的閒置等待（接受快取未命中，分攤至更長的等待時間）

資料庫遷移正在執行，通常需要 20–40 分鐘。

```json
{
  "delaySeconds": 1200,
  "reason": "遷移通常需要 20–40 分鐘；20 分鐘後再檢查",
  "prompt": "檢查遷移狀態，完成後繼續"
}
```

喚醒時快取將會冷卻，但 20 分鐘的等待足以分攤單次快取未命中的代價。每 5 分鐘輪詢一次會以相同的快取未命中代價重複 4 次，毫無收益。

## 注意事項

- **5 分鐘快取 TTL**：Anthropic 提示快取在 300 秒後過期。延遲低於 300 秒可保持上下文熱態；延遲超過 300 秒則在下次喚醒時產生快取未命中。
- **避免恰好設定 300 秒**：這是最糟糕的選擇——既承擔了快取未命中的代價，又沒有獲得實質性更長的等待時間。要麼降至 270 秒（保持快取熱態），要麼提交到 1200 秒或更長（一次快取未命中換來更長的等待）。
- **閒置等待的預設值**：當沒有特定訊號需要監視時，使用 **1200–1800 秒**（20–30 分鐘）。這讓迴圈能定期檢查，而不會每小時因無意義的快取未命中損耗 12 次。
- **自動限制範圍**：執行環境會將 `delaySeconds` 限制在 `[60, 3600]` 範圍內。低於 60 的值變為 60；超過 3600 的值變為 3600。無需自行處理這些邊界。
- **省略呼叫即結束迴圈**：如果打算停止迭代，請勿呼叫 ScheduleWakeup。省略該呼叫即可結束迴圈。
- **每輪傳入相同的 `prompt`**：`prompt` 欄位在每次呼叫時必須攜帶原始 `/loop` 指令，以便下次喚醒知道要恢復哪個任務。
