Every skill my AI setup learns lives in one folder on my laptop — and none of it reaches the repo I created yesterday.
That gap is why I built a weekly job that pushes my accumulated skills into every project on the machine.
This is what it does, and the four failures I hit getting it to run unattended.
Why this mechanism works Claude Code's is essentially a personal "habits library." Workarounds, completion criteria, and verification commands discovered mid-task get written out to skill files automatically by the AI, and can be referenced immediately on the next request — that's how the mechanism is designed.
Reality is a little different, though.
Skills keep piling up in .
But a project in a freshly created git repo, a side-gig job opened for the first time in weeks, a set of tools written in another language — those don't have the skills at all to begin with.
Unless a human copies them by hand, or I type "refer to that skill" every single time, the habits I so carefully accumulated are completely dead in other projects.
The structure of the problem looks like this.
Skills accumulate in one place, (global) They're actually referenced only "when that project has or " (local) That bridging doesn't happen each time you create a new project (zero start) This isn't "growing your environment," it's "regrowing it every time." Once monthly revenue crosses a certain line, the number of concurrent jobs rises, and there are weeks where I cut two or three new repos.
Each time, noticing the missing skills, copying manually, verifying — that work quietly eats time.
Not the duration of a single tool call, but the opportunity cost of "if that skill had been here, this would have taken three minutes." The weekly auto-distribution script solves this.
Early every Sunday morning, it scans all git repositories and pours the skills in.
Without a human doing anything, the project you open on Monday has the latest skills in place.
Don't increase the amount of work — raise the baseline quality of the environment.
In building an autonomous Claude Code environment, this design philosophy has been the most effective one.
One important premise. "Skills" here means the files under that I built up myself.
Bundled skills and are never touched.
The distribution target is strictly my own habits library.
The overall flow Here's a bird's-eye view of the whole mechanism. launchd configuration: pinning "Sunday 06:10" in a plist launchd, the macOS job scheduler, loads plists placed in and runs them automatically.
The contents of look like this.
A of is Sunday.
It fires at 6:10 every Sunday.
Since is , it doesn't run the instant the plist is loaded.
It waits until the next Sunday.
PATH configuration is in there too. launchd doesn't go through a shell, so your usual isn't read.
Unless you explicitly write the path to the nvm-managed Node.js into PATH, the command won't be found and the job fails.
It's launched with , but even then isn't read in launchd's environment, so this PATH injection is mandatory. and both point at .
The function inside the script appends to the same file, so logs are consolidated into one file. ① Online check: bailing out safely with an 8-second timeout The trigger time can coincide with waking from sleep or with airplane mode.
Calling at that point would just fail, so the first thing it does is check HTTP connectivity to npmjs.
With , no response within 8 seconds is treated as offline, and it exits normally with .
The reason it doesn't return an error code is that launchd sometimes uses an error exit as a retry trigger. ② Project discovery: crossing languages with six manifest types Discovery is under and — two levels.
Directories nested deeper than that are out of scope.
This limit exists for both performance and deliberate scoping.
Two routes run in parallel, OR'd together: one that looks for the directory and takes its parent, and one that looks for manifest files and takes the parent directory. removes duplicates.
Something that isn't a