Loops and schedules
Three ways to keep Syntic Code working without typing each step yourself.
| Tool | Use it when |
|---|---|
/loop | You want the same prompt re-run every few minutes while the session is open (“check the deploy and tell me when it is green”). |
/schedule | A prompt should run on a timetable in this project (“every weekday at 9, summarize new issues”). |
/goal | The agent should keep going, turn after turn, until a condition is true (“all tests pass”). See Goals. |
Loops
/loop 5m check whether the staging deploy finished and report its statusThe prompt runs right away, then again at every interval, but only while the session is idle, so it never interrupts you. Runs show up in the transcript marked as scheduled.
| Command | Does |
|---|---|
/loop [interval] <prompt> | Start a loop. |
/loop list | Show running loops and scheduled tasks. |
/loop stop [id] | Stop one loop, or all. |
Intervals
Write the interval as a number and a unit: 30s, 5m, 2h, 1d (also 90sec, 10min). The shortest interval is 10 seconds.
Leave the interval out and the agent paces itself: after each run it decides when to look again, anywhere from one minute to one hour, and says so at the end of its reply (“next check in: 15m”). If it does not say, the next run is in 10 minutes. This suits jobs whose rhythm changes, such as watching a deploy that speeds up near the end.
/loop watch the CI run for this branch and tell me as soon as it finishes or failsLoops and sessions
Loops belong to the session they were started in. They stop when you close it and come back when you resume that session. A loop never interrupts a running turn: a run that falls due waits until the session is idle.
Scheduled routines
Routines are prompts that run on a schedule in this project, as normal turns, whenever a session is open here. If a time is missed because no session was open, it runs once when the next session starts.
/schedule add every 30m run the flaky-test detector and file what it finds in FLAKY.md
/schedule add "0 9 * * 1-5" summarize yesterday's merged pull requests| Command | Does |
|---|---|
/schedule or /schedule list | Show this project’s routines, including ones the agent created. |
/schedule add every <30m|2h|1d> <prompt> | Add one by interval. Minutes must divide an hour, hours must divide a day. |
/schedule add "<cron>" <prompt> | Add one with a five-field cron expression. |
/schedule pause <id> · resume <id> | Keep it without running · continue from the next matching time. |
/schedule delete <id> | Remove it. |
You can also just ask: “remind me at 3pm to review the release notes” or “every Monday at 8 check for outdated dependencies”. The agent creates the schedule with its CronCreate tool, and can list and cancel jobs with CronList and CronDelete. One-time tasks are removed after they run. Each job belongs to the project it was made in and only runs there.
All times are UTC. Schedules are saved in ~/.syntic/cron-jobs.json (change with SYNTIC_CRON_FILE). Routines run only on your computer while a session is open in the project; nothing runs in the cloud.
Need a job that runs with no session open? Call syntic -p from your system’s scheduler (cron, launchd, Task Scheduler) or from CI. See Scripting & CI.
Goals
/goal <condition> keeps the agent taking turns until a condition is met, checked after every turn. It has its own page: Goals.
Long-running commands and alerts
- Background shell commands. The agent can start a command in the background (a dev server, a long build) and check its output later. Press
Ctrl+Bto send a running command to the background yourself. - Monitors. The agent can watch a command or file with its
Monitortool and is notified as new output arrives. - Notifications. The agent can send you a desktop notification with its
PushNotificationtool, for example when a long job finishes. Notifications stay on your computer.