Tell /loop what you want checked later. DuoDuo turns the request into a scheduled job, keeps your current conversation free, and brings each useful result back.
Plan before spending#
/loop check the staging deploy and tell me when something breaks
Before creating the job, DuoDuo proposes a plan with:
- the cadence or wake strategy
- the runtime and model
- what gets delivered and where
- the stop condition
The plan is where you decide what will run, how often it can spend a model turn, and when it should stop, so read it before you confirm. You can ask DuoDuo to skip confirmation when the plan is already clear.
Three useful shapes#
Fixed cadence#
For digests, sweeps and checks that should run on a stable calendar.
Delays and intervals accept composite durations such as 2h30m and 1d6h4m. An invalid cron string or a malformed duration is rejected when the job is created, instead of being accepted and never fired.
Self-paced mission#
For “watch until done.” The job decides when to check again, can slow down when nothing is happening, and ends itself when the goal is complete. It judges progress by whether the gap it named has closed, and stops when the work meets that bar instead of when it runs out of turns.
Long-term tracker#
For an answer that should improve over weeks or months. One job keeps the thread while short-lived helpers handle heavier research or analysis.
Manage a loop#
Talk to DuoDuo in plain language:
- “show me my loops”
- “stop staging-watch”
- “make the release tracker daily instead”
- “wake the market tracker back up”
The published duoduo-loop skill carries the rest. Stopping a loop takes it off the schedule and moves its files out of the active set; a run already under way finishes, and nothing is deleted, so a stopped loop is still there to read. Ending only the run in progress is a separate act, and the reason you give opens the loop's next run, so it learns why it was cut off. One extra look (“check once more tonight”) adds a single fire and leaves the cadence alone.
Re-pacing has a cost: a loop's conversation is keyed to its schedule, so a new cadence starts a fresh conversation and the judgment the old one accumulated stays behind.
Each of these is also a duoduo job command on the host, which is what DuoDuo runs.
When a loop reports back#
A finished run's receipt reaches you as context on your next turn in the conversation that owns the loop; it does not start a turn of its own. A daemon restart delivers nothing by itself, so a loop never promises a follow-up it cannot keep.
Book one more turn#
A conversation can book its own next turn: DuoDuo sets a reminder that wakes this same session at a future time, with no job to name and no target to address. In a job session, it is one more fire of that job's own schedule. A pending reminder shows in the dashboard's job list with its owner, when it fires, and what it says. Ask DuoDuo to cancel it.
Give a job its own tool surface#
A job's frontmatter can configure the session it runs in, so a scheduled sweep does not inherit the defaults of a live conversation. DuoDuo writes this block when you ask for a narrower sweep:
prompt_mode: ...
allowedTools: [...]
disallowedTools: [...]
additionalDirectories: [...]
claude:
tools: [...]
Host-wide defaults for all jobs live in kernel/config/job.md.
Cost rule#
Every scheduled wake can spend a real model turn, so match the cadence and model to the value of the check. If nothing needs judgment until new data arrives, let a script detect the change and wake DuoDuo only then. Ask for that shape and the published duoduo-pipeline skill builds it.