菜单
Invoke once per timer tick under /loop dynamic mode — picks the next unblocked task, works it, schedules the next wake-up. Not for cron-style /loop 60s.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Anthropic API rate limit handling - retry logic, backoff, throttling for batch workloads against Claude models
Use when building an automated test → issue → fix loop with Claude Code and GitHub issues — overnight auto-fixing, regression loops, self-healing CI.
Use when creating, editing, publishing, or deleting posts on Cyril's Workshop blog or the steponnopets.net devblog.
Use when writing or contributing a boofuzz network-protocol fuzzer in this repo — layout, formatting rules, and reading results.
Use when a task needs real-time control of a connected browser via the Browser Bridge Broker — submit JS jobs over HTTP that browsers eval and return.
Use when training a character LoRA (Chroma/Flux or Pony/SDXL) on a RunPod GPU and wiring it into the ComfyUI + pony_web render stack.
| name | task-loop |
| description | Invoke once per timer tick under /loop dynamic mode — picks the next unblocked task, works it, schedules the next wake-up. Not for cron-style /loop 60s. |
Does one task per invocation, then schedules the next wake-up via ScheduleWakeup. Designed for /loop in dynamic/self-paced mode, where the command drives its own cadence — not cron-style /loop 60s /task-loop (which would keep firing even after a halt). Does not create tasks (consume whatever TaskCreate set up during planning), does not sleep or block, does not loop within a turn.
Always do the slice first, then decide whether to schedule — never schedule before doing work.
TaskList to fetch tasks.pending task with empty blockedBy and the lowest numeric ID. If none, print task-loop: no unblocked pending tasks, loop complete and STOP (no ScheduleWakeup).TaskGet to read the full description, then TaskUpdate → in_progress.task-loop: starting #<id> — <subject>.description, treating it as authoritative. Don't expand scope or refactor adjacent code — every changed line should trace to the description. Run any verification commands the task names (cargo check, cargo test, etc.) and confirm they pass.TaskUpdate → completed, print task-loop: completed #<id>.in_progress, print task-loop: halted on #<id> — <one-line reason>, STOP (no schedule).TaskList. If any unblocked pending task remains, call ScheduleWakeup(60) and print task-loop: scheduled next slice in 60s. Otherwise print task-loop: list drained, loop complete and don't schedule./loop + ScheduleWakeup.60 seconds is a ScheduleWakeup runtime floor (clamps to [60, 3600]), not a choice — it's the tightest cadence available, which is what Matt wants.
One commit per slice is a good default for code changes but not mandatory — some tasks (e.g. running verification) produce no commit.