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.
In this repository28 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- architect-reviewSkill
- article-writingSkill
- changelog-watchSkill
- coordinator-workersSkill
- cost-forecastSkill
- design-docSkill
- documentSkill
- ea-briefingSkill
- estimateSkill
- eval-toolSkill
- gh-ticketsSkill
- headless-loopSkill
- interview-guideSkill
- market-researchSkill
- meeting-notesSkill
- migration-planSkill
- obsidian-noteSkill
- plan-to-issuesSkill
- postmortemSkill
- readSkill
- release-notesSkill
- skill-stocktakeSkill
- slide-deckSkill
- status-reportSkill
- threat-modelSkill
- tradeoff-tableSkill
- zoom-outSkill
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
- Distinctive: line 27
Delete the two synthetic rows so the day file holds real runs only.
- Very specific: line 28
Commit jobs/run.sh, the plist and the first jobs/runs/<day>.jsonl.
≈ “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.
Files
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
- Copy
${CLAUDE_SKILL_DIR}/scripts/run.shto<repo>/jobs/run.shand make it executable. It finds the repo root as its folder's parent, so it must live injobs/. Copy, do not symlink: launchd needs a path that is still there when the skills folder moves. - Point the scheduler at the wrapper, with the job as its argument:
- launchd:
ProgramArguments=<repo>/jobs/run.sh,<repo>/jobs/<job>.sh; thenlaunchctl unloadandloadthe plist and check withlaunchctl print gui/$(id -u)/<label>thatprogramis the wrapper. - cron:
JOB_OWNER=cron <repo>/jobs/run.sh <repo>/jobs/<job>.sh.
- launchd:
- 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
failrow with that line aserror; a script that exits 0 must give anokrow withouterror; then run the real job by hand once. Delete the two synthetic rows so the day file holds real runs only. - Commit
jobs/run.sh, the plist and the firstjobs/runs/<day>.jsonl; indexjobs/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).jsonlCount 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.
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
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.

