---
name: automation
description: Schedule one bounded local Skill workflow for a later time, then verify the unattended result, timing and failure log. Use when a learner has an already-working workflow and wants a first observable automation run.
---

# Let a small workflow run once

Main quest 4-3. Start with one bounded, reversible run before recurring jobs.

## Define the run

Choose an already-tested workflow, source folder, new result folder and execution time.
State side effects and dependencies. Keep the first exercise to local public practice data.
Do not schedule sending, spending, deleting or publishing unless that exact action is already authorized.
For recurrence use the Agent/app's supported automation system; this package's helper is a local one-shot timer.
The helper needs Node.js 18+, a running computer and a process that survives until execution.
It does not wake a sleeping computer, persist after restart or run a new language-model session.

## Local first exercise

The included workflow observes direct children of a selected folder using the first-agent helper.
Inspect the plan before launching. Paths are resolved relative to the plan file.
The result directory must not exist; the helper preserves prior runs instead of overwriting them.
Use a short delay for practice and a new directory for each run:

```text
node <installed-skill>/scripts/schedule-once.mjs <plan.json>
```

Plan fields: `source`, `jobDirectory`, `delayMs` (1000–60000).
The parent starts one separate hidden local worker and exits.
The worker writes scheduled/due/start/finish times, process ID, exit status and log.
Read `references/automation-check.md` to interpret what the receipt proves.
To stop a pending practice run, use the printed process ID only after checking that it belongs to this job; do not kill unrelated processes.

## Verify after the due time

Read `status.json`, `job.log` and, on success, `result.json` in the job directory.
Check that start was at or after due time and that the child process differs from the launcher.
Reconcile observed filenames to the actual source folder.
For a missing source, expect FAILED and an error log, not an empty success result.
If the computer stopped or the worker did not complete, record UNKNOWN or FAILED rather than claiming unattended success.
Do not interpret a scheduled record as proof of execution.

## Self-tests and failure criteria

1. Schedule observation of a public folder with two different named files; leave the worker to execute and reconcile the delayed result.
2. Use a separate Unicode-named folder with different contents and a new job directory; verify the different inventory.
3. Schedule a nonexistent source. Verify nonzero workflow exit, FAILED status and no successful result file.
4. An existing job directory must be preserved and scheduling must refuse to reuse it.

Failure means running before due time, an overwritten result, an unlogged failure or a completion claim without an actual worker result.

## Continue

Return `/path/automation/`. Next `/path/publish-skill/`: publish a version only after its package and examples are verified.
Original free workflow. No extra API or service fee; Agent/model fees remain separate.