agentleFS
prestariusprestarius/jet-skills-stack/skills/job-supervisor/SKILL.md

job-supervisor

Skill1 starsChanged 2 months agoMITView on GitHub

Put every unattended job (launchd, cron) behind one wrapper that records each run as a JSON line in jobs/runs/<day>.jsonl (time with offset, job, ok or fail, exit code, seconds, last error line), so a morning check or a digest can read what ran at night. Use when a repo gains a scheduled job, when the user asks "did it run", "log the jobs", "supervise the cron", or when a lesson or plan calls for a supervisor over automations.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Delete the two synthetic rows so the day file holds real runs only.

    line 27
  2. Very specific:

    Commit jobs/run.sh, the plist and the first jobs/runs/<day>.jsonl.

    line 28

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

job-supervisor

A job that runs unattended needs a record someone can read in the morning without opening the job's own log. The record is one JSON line per run, appended to jobs/runs/<day>.jsonl in the working repo. The job itself is not changed; the scheduler calls the wrapper, the wrapper calls the job.

Install in a repo

  1. Copy ${CLAUDE_SKILL_DIR}/scripts/run.sh to <repo>/jobs/run.sh and make it executable. It finds the repo root as its folder's parent, so it must live in jobs/. Copy, do not symlink: launchd needs a path that is still there when the skills folder moves.
  2. Point the scheduler at the wrapper, with the job as its argument:
    • launchd: ProgramArguments = <repo>/jobs/run.sh, <repo>/jobs/<job>.sh; then launchctl unload and load the plist and check with launchctl print gui/$(id -u)/<label> that program is the wrapper.
    • cron: JOB_OWNER=cron <repo>/jobs/run.sh <repo>/jobs/<job>.sh.
  3. Self-check before trusting it (the wrapper returns the job's exit code): a script that exits 3 with a line on stderr must give a fail row with that line as error; a script that exits 0 must give an ok row without error; then run the real job by hand once. Delete the two synthetic rows so the day file holds real runs only.
  4. Commit jobs/run.sh, the plist and the first jobs/runs/<day>.jsonl; index jobs/ in the README.

The record

{"at": "2026-10-30T05:01:05+01:00", "job": "0501", "status": "ok", "owner": "launchd", "exit": 0, "seconds": 0}
{"at": "2026-10-30T04:00:01+01:00", "job": "backup", "status": "fail", "owner": "launchd", "exit": 1, "seconds": 12, "error": "quota exceeded"}

at carries the offset so two machines' records can be compared. error is the job's last output line, which is usually the message that matters. A missing day file means nothing ran, which is itself the finding.

Reading a night

cat jobs/runs/$(date +%F).jsonl

Count ok/fail per job from the rows, not from the jobs' own logs. A digest page or a morning routine reads the same file.

Limits

The wrapper records; it does not retry, alert or time out. Add those only when a night shows they are needed, and keep them in the wrapper, not in each job.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.