This skill's scripts/scripts.sh launcher lives inside this skill directory
and calls the identity-bound daemon through TARIBOY_TOOLS_SOCKET.
Execute the launcher when command execution is available. If it is unavailable,
return the exact command instead; never claim a script was queued, scheduled,
rerun, cancelled, or removed unless the command succeeded.
Run once with scripts/scripts.sh run <name> -- <command>. Queue it exactly once,
finish the iteration, and consume the later script.result message instead of
waiting in the current iteration.
Run repeatedly with scripts/scripts.sh schedule <name> --every <seconds> -- <command>.
Runs never overlap. A run that exits with $TARIBOY_QUIET_EXIT (111)
publishes nothing and keeps the schedule; it is the only outcome that does.
The daemon exports the code to every run, so a shell command stays quiet with
exit "${TARIBOY_QUIET_EXIT:-111}" and a Python one with
sys.exit(int(os.environ.get("TARIBOY_QUIET_EXIT", "111"))).
Inspect with scripts/scripts.sh ls, scripts/scripts.sh runs, and
scripts/scripts.sh logs; use scripts/scripts.sh rerun,
scripts/scripts.sh cancel, or scripts/scripts.sh rm for lifecycle control.
Address every definition by its script ID
REQUIRED: rerun, cancel, and rm accept only the scr-... script ID
or a srun-... run ID. Names are not unique and are not resolved: passing one
fails with not found, and run <name> -- <command> creates a second
definition instead of resuming the stopped one.
Take the ID from the script_id field of the script.result message that woke
you, from the creation output, or from scripts/scripts.sh ls. Record the
script ID, not only the name, wherever a durable monitor is recorded.
A published result stops the schedule
A recurring definition keeps its schedule only while every run stays quiet.
The moment a run publishes a script.result message, the daemon sets the
definition to completed and clears its next run: the agent is notified once
instead of repeatedly, and no further runs happen until it is resumed.
This covers every published outcome:
| Event | Effect on the recurring definition |
|---|---|
Run exits with $TARIBOY_QUIET_EXIT (111) |
No message; schedule keeps running |
| Run exits with any other code, success or failure | Result published; definition stopped |
A command that never exits with $TARIBOY_QUIET_EXIT |
Every run publishes, so the schedule stops after the first run |
cancel <run-id> for one active run |
That run still publishes a result, so the definition stops too |
| A run interrupted by a daemon restart | Recovery publishes the interrupted result, so the definition stops |
cancel <script-id> |
Definition cancelled; it can never run again |
Handling a script.result for a recurring definition
REQUIRED: Process the result, then close it with exactly one of these two decisions before the iteration ends. Doing neither silently ends the observation.
-
Still needed — resume the same definition:
scripts/scripts.sh rerun <script-id>rerunruns it now and returns the definition toactive, so its fixed delay continues afterwards. Never create a replacement schedule for work the stopped definition already describes. -
No longer needed — remove it:
scripts/scripts.sh rm <script-id>The published result already stopped it, so no
cancelis needed. Runscripts/scripts.sh cancel <script-id>first only whenlsstill reportsstate: active.
A stopped definition is not a wait object. Never end an iteration describing a
definition that published its result as an active monitor: either it was
resumed with rerun in this iteration, or the iteration's wait object is
something else.
External prerequisite failures
REQUIRED: A recurring schedule whose command cannot succeed until an
external prerequisite changes, such as a missing credential, binary, or
dependency, is no longer a valid wait object. Its failing result already
stopped it, so take branch 2 above and never rerun it:
scripts/scripts.sh rm <script-id>
Run scripts/scripts.sh cancel <script-id> before it only when ls still
reports state: active. Then, for a Native Task:
- Mention the customer and ask one blocking question. Reuse a matching unanswered question instead of creating or repeating it.
- Set the task to
wait_customerif it is not already there and record the question as the only resume event. - As the final action, finish the iteration through the
loopskill withscripts/loop.sh done.
The failure is handled only after the definition is removed, the task has one customer-answer wait, and the iteration is finished. An action trace that omits any of these is incomplete.
Pausing or disabling leaves the useless definition behind; it does not complete this sequence. Do not rerun the command, create a replacement schedule, or repeat the failure comment while the question remains unanswered.
Red flags
| Thought | Reality |
|---|---|
| "The schedule keeps running, so I can just finish." | Any published result stopped it. Resume with rerun <script-id> or remove it. |
| "Cancelling one run leaves the schedule intact." | That run still publishes a result, which stops the definition. |
| "I will schedule it again to resume monitoring." | A second definition duplicates the work. rerun <script-id> resumes the recorded one. |
"rerun <name> is clearer than the ID." |
Names are not resolved; only scr-... IDs work. |
| "It succeeded, so nothing stopped." | Success is not quiet. Only $TARIBOY_QUIET_EXIT (111) is quiet. |