Skills that get better
from being used
A set of AI skills lives in a public repo. Using one reveals a weakness; a note lands in a private repo; a scheduled agent reads the notes and opens pull requests that fix the skills. Use them, and they improve.
A folder with one file that matters
An Agent Skill is a folder with a SKILL.md in it: a few lines of front matter — name, description — and then plain-English instructions. It can carry scripts and reference files alongside. The format is an open standard, so a skill written once works across agent tools.
The description is the load-bearing field. An agent reads only the name and description of every skill it has, and opens the full body only when the description matches the task. A bad description means a good skill never gets used. Flip the card to see the difference.
The agent decides whether to open a skill from its description alone. Write that line as if it is the only one anyone will read — usually it is.
Two repositories and a one-way valve
The notes are taken during real job-search conversations — which companies, which roles, what went wrong in which interview. They cannot be public. The skills are meant to be public: they exist to be installed, and a skill nobody can read is hard to trust. So there are two repositories — private input, public output — and a valve between them.
- the rules for writing a note
- the summariser's instructions
- the notes themselves, dated
- a record of runs, and where the last one stopped
skills/ business/company-research/ careers/role-fit/ careers/interview-prep/ careers/pay-check/ scripts/build_skills.py .github/workflows/
The valve is a review step. The note-taker redacts before writing, and nothing reaches the public repo except through a pull request that a person reads before it merges. Two layers, one of them human.
Private input, public output — and a person at the point where they meet.
How does an agent push code?
The agent works in a sandboxed cloud container. Its outbound traffic goes through a proxy, and git push only reaches repositories attached when the session started. So: an agent that can write files, run tests and compose a perfectly good commit — and cannot send it anywhere. Pick a route and watch where it stops.
Three ways out of the container. Two of them are walls.
The way around it was not to fight the proxy. The GitHub connector does not use the session's network at all: its traffic takes a different road and arrives at GitHub's API bounded by what the account has granted — a chosen set of repositories, pull requests only, nothing merged without a person.
The sandbox restricts what the machine can reach. The connector restricts what the account has granted. They are separate systems, and the second is the one that matters for writing to GitHub.
A network boundary and a capability boundary are different things. Confusing them is why this looked unsolvable for longer than it should have.
Seven steps, then back to the first
Click any step. It advances on its own until you do.
Two details in that loop are more interesting than they look.
Capture is deliberately trivial. The capture skill is 36 lines. It holds none of the rules for writing a note — it points at the file in the private repo where the rules live. The same pattern runs through the whole system:
Each rule lives in exactly one place: where it is enforced. Every layer above it points rather than copies.
Copy a rule into a second place and there are two places to update. One of them will be wrong within a month, and it will be the one you forget.
Summarise keeps a watermark. One small state file records the last note it processed, so a run that wakes to nothing new does nothing, and a run that crashes halfway does not reprocess. It is the smallest possible piece of state, and it is what makes the schedule safe to run unattended.
One footnote. The summariser's instructions live where the automation can edit them, so in principle it could rewrite its own rules. The invariants are therefore repeated in the scheduled task's own prompt, which it cannot reach. A self-improving system needs at least one thing about itself it cannot improve.
Write each rule where it is enforced and point at it from everywhere else.
Same findings, same model, new instructions
After the first automated run, its pull requests were reviewed and rated. Then everything was reset and the same findings went to the same model again — only the instructions had changed. Three rules were added. Click one to see only the changes it produced.
Both ratings are one reviewer's subjective judgement of the same findings processed twice. They are presented as such.
Accuracy barely moved; quality moved a lot. The original instructions said what to do and nothing about how well, so the agent picked the right problems and then defaulted to adding — more words, more caveats, several concerns in one pull request. What made rule 3 stick was not the principle but the accounting: state how many lines the skill gained or lost. A number the agent has to write down is a constraint. A principle it merely agrees with is not.
Telling an agent what to do is the easy half. The instruction that improved the output most was the one that told it what to remove — and made it count.
Three things the runs taught
Not from designing the system — from watching it work.
The loop finds real bugs, not just wording
The third run discovered that the interview-prep record was saving to a storage that does not exist, so nothing survived a reload. It proposed a fix and verified it in a browser it drove itself — including a browser that refuses storage altogether. The pull request is waiting for a person, as every one does.
A source of truth can be stale
Dates had drifted, so a rule said: take the date from GitHub. It read the last commit of a quiet repo — and stamped two pull requests ten days late. Take the date from the event itself, not from the last thing that happened nearby.
A person stays in the loop on purpose
Every pull request is read before it merges. That review is the boundary between private notes and public skills — and it is where the ratings in step 5 come from. A system that improves itself still needs someone to say what better means.
Automate the loop, keep the judgement. The runs are cheap; the review is where the system learns what good looks like.
The numbers, from the repo itself
The public repository's pull-request list is open, so these figures can check themselves: a snapshot from 11 September 2026, refreshed from the live API whenever GitHub answers. Only the loop's own pull requests are counted.
What to take from it
- A capability boundary and a network boundary are different things.
- Write rules where they are enforced and point at them from everywhere else.
- Telling an agent what to do is the easy half; telling it what to remove is what makes the output shippable.
- Give the agent a number it has to write down. “Keep it readable” is advice; “state how many lines it gained or lost” changes behaviour.
The loop keeps going: every real use is a chance to find the next improvement, and every improvement is one pull request, read by a person, away from being installed.
Everything quoted here is from the public repository or was cleared for publication. Nothing from the private repo appears: no notes, no companies, no roles.