Set up a skill-backed recurring Hermes job and verify its first run

Hermes operators can attach a reviewed skill to a recurring job so each run begins with the same procedure. The useful test is whether one scheduled run reads the permitted input, produces an acceptable local report, and records which model and host actually handled it. This guide is for an operator who controls the Hermes profile, provider account and gateway host. BIG CHANGE reviewed the official cron manual and related documentation on 19 October 2026; we did not install Hermes or run a job.

The big change

• What changed: Hermes can load a reviewed skill before a scheduled prompt, run it in a chosen workspace and save the result locally. An operator can create the job paused, inspect it and resume that same job ID.
• Why it matters: A repeatable information task can use one reviewed procedure. The operator still needs to check a due run against its permitted input; a saved schedule does not establish which skill revision or model ran, or whether the report is accurate.
• What to watch: Continued use depends on the gateway host staying available and the first run meeting the report criteria. Check the attempt, output and available provider/model evidence before leaving the job active; inspect its exact state again after any interruption.

Before you schedule anything

Choose one small, permitted input file and an existing, isolated workspace. Decide what a correct short report must contain, where it should cite the input, and what missing data should make it stop. Keep this first job informational: no external posting, record changes or secrets in its output. Obtain separate authority to make it recurring. You also need a configured Hermes installation, a usable model/provider route and credentials, and a gateway host that can stay available for scheduled runs. Check your installed release and hermes cron create --help because the public manual does not state a version for every option. The quickstart covers setup; the provider guide covers the inference route. A harmless one-time chat can check that route before recurrence, but it is not evidence that a scheduled run succeeded.

A skill is a reviewed SKILL.md procedure, not a permission boundary. Put skills/local-input-report/SKILL.md under the actual owning profile's HERMES_HOME; ~/.hermes/skills/local-input-report/SKILL.md is the default-profile example. Adapt this minimal procedure to your approved input and report criteria before using it:

---
name: local-input-report
description: Report checked facts from one approved local input.
---

Read only <absolute-permitted-input-path> in the job workspace. In a short report, name that file, state only facts supported by it, and cite the relevant part. Flag missing data and stop. Do not send messages or change files or external records.

Inspect the actual file and confirm Hermes discovers it with hermes skills list in that same profile. If you use a project-local skill instead, the skills manual says that an interactive trust and scan decision must precede a noninteractive cron run; cron does not grant trust itself. Review the enabled tools and real file access separately. Record the skill's content or revision so its name cannot stand in for a review.

Create one job, then inspect it

1. Run every command against the same owning profile: the examples below use the default profile, while a named profile needs its profile selector, such as hermes -p NAME, on every command. Check that profile's current model with hermes model and gateway/ticker health with hermes cron status. Decide whether to pin an explicit provider and model, or pin the current main model. A per-job pin takes precedence over cron.model and cron.model_provider; those fleet settings take precedence over the current main model. An unpinned job can therefore change model when the applicable default changes. The saved configuration still does not establish the model used on an actual run.
2. With recurrence authorized, adapt this POSIX-shell CLI example to your reviewed skill and absolute, existing workspace. Confirm every flag in the installed help first. Its backslash line continuations are POSIX-shell syntax; use your shell's syntax on another platform. The prompt is deliberately narrow, and local delivery keeps the first output in the owning profile:

   hermes cron create "every 1h" \
     "Use the attached reviewed skill to read only the permitted input. Return a short local report with its source and missing-data note. Do not send or change external records." \
     --skill local-input-report \
     --name "Local input report" \
     --workdir "/absolute/existing/workspace" \
     --pin \
     --paused --paused-reason "Awaiting owner review"

Replace the workspace path, choose a unique job name, and replace the input placeholder in the skill file before running this command. The CLI uses local delivery by default. The cron manual also documents --model and --provider for an explicit pin. Use the real provider/model identifiers from your installation if you choose that route. Do not put credentials in the prompt or shell history. --workdir makes Hermes discover workspace instructions; without it, cron runs detached from the repository. A paused new job has no next_run_at until resumed.

Local delivery controls where the final report is saved. The prompt and any input content used for inference still follow the selected model/provider route; approve that data flow before resuming.

3. Keep the returned job ID. Use hermes cron list to read back its skill, workspace, delivery and paused state; use hermes cron status for scheduler health. The current official CLI source does not show saved model/provider fields in the list rows. Inspect the exact ID in the owning profile's cron/jobs.json read-only for its saved pin, model/provider and inference overrides, or use a job-details view that your installed release actually supports. Do not print credentials. Compare the saved settings with the file, report criteria and scope you approved. Correct this job with hermes cron edit <job_id> ... if needed; there is no reason to create a second copy.
4. When ready to observe a due run, use hermes cron resume <job_id>. Read back its actual next-run instant and the gateway's last successful tick. The gateway ticks about once a minute; a foreground gateway needs its host to remain up. hermes cron tick does not start a gateway for an agent job. A service or restart-safe worker has host-specific requirements, so check the selected host rather than assuming a laptop-off or reboot guarantee.
5. After one scheduled due time, inspect hermes cron runs <job_id> --limit 20 and the matching file under the owning profile's cron/output/<job_id>/. Compare the report with the real input and your acceptance criteria. Check the attempt's scheduled and claim times, final status, and any available transcript or run telemetry for the actual provider and model. If the installed records do not expose that identity, record it as unknown. A scheduler tick, admitted run or completed status does not by itself validate the report.
6. Pause the exact job with hermes cron pause <job_id> and read it back in hermes cron list. This stops future automatic scheduling; it does not kill an in-flight attempt. An explicit manual run is an operator override, even under a pause. Keep the history and local output while you decide whether the job met the acceptance criteria.

If it fails, recover the same job

Read the exact attempt and output first, then the job's last_error, last_fire_error and last_delivery_error where available. hermes cron status distinguishes a stopped ticker or unwritable cron store from a job that ran and failed. Check the owning profile and gateway host before changing provider settings: an interactive shell and a service can read different credentials. Fix only the affected setting, verify the state again, and resume the same ID only when its scope remains approved. If delivery is uncertain, inspect the intended destination before retrying; a timeout can occur after an adapter accepted a send.

The cron manual's admission-recovery section says interrupted execution or an unfound prepared fire stays paused for review; its execution-history section says unknown attempts are never automatically rerun. Check the installed job's paused state and exact attempt identity after a restart before deciding how to recover it. Never double-trigger a live attempt to probe overlap. Hermes has a scheduler tick lock, an in-flight guard for another admission to the same job, and a configurable fleet concurrency limit. Those controls do not guarantee exactly-once effects in an external system.

Provider use and an always-available host may cost money. Start with one bounded input and inspect provider usage after the due run before choosing a continuing cadence. The documented pre-run script timeout does not cap a skill-driven model turn or its bill; cleanup and inactivity limits are separate. A deadline written in the prompt is an instruction, not a hard spending control. If you cannot tolerate an unbounded model turn or an uncertain side effect, keep the job paused until you have suitable controls. This guide reports documented behavior, not a measured run, price, reliability result or savings claim.