Skills that write skills

The day it said no to itself

In Chapter 1, I briefed the hire every morning. By now, I wanted the briefing to run the other way.

The gap was simple to describe. The brain held plenty of facts, but nothing in it told me, in one place each morning, what was due, what was stuck and what needed a decision. It had no routine for that. So it did what it is built to do when it meets a task it cannot do well: it stopped and started writing the missing routines.

It wrote several that day. A ranked list of next actions. A health check on live work. A daily briefing that pulls the two together. All tested, all reviewed by me, all finalised the same day.

Then it reached two more: one for deadlines, one for risks. Each would have been its own routine with its own file to keep fresh.

It declined.

The brain carries a rule against exactly this: never write five routines when one will do. Two more routines meant two more files to maintain and two more places for the truth to drift apart. So deadlines and risks became sections of the one daily file instead.

Tap to enlarge

Close

It proposed five routines and kept three; deadlines and risks became sections of the daily briefing instead.

The day the brain refused to grow is the day I started trusting it to grow. I had built a system that could grow its own tools, and I watched it use its own rules to say no. Growth that knows when to stop is the only kind I want running unattended in my business.

The idea

When the brain meets a task it has no routine for, it stops and writes one, so the next session already knows how.

Without this, a second brain is a capable assistant that forgets how it did things. You explain the same job twice, then ten times, and the knowledge of how lives only in your chat history.

With it, every gap becomes a routine, and the brain gets more capable the more you use it.

How skills work in a Claude Code second brain

The brain does its work through skills: small routines that each do one job. Draft a proposal. Clean a call transcript. Write the weekly report. A skill is a short plain-text file an agent reads and follows.

Every skill has the same shape. What it is for. When it runs. Roughly how it works. What counts as a hard fail. Where its output goes. A line in the log saying who ran it. How it tends to break.

Tap to enlarge

Close

A skill spells out what done looks like and what must never ship, and says very little about how to get there.

Two rules keep skills honest.

Skills name the destination, not the path. A skill says exactly what a good output looks like and what must never be in it. It says very little about how to get there. Modern models are better at finding paths than I am at specifying them, and an over-specified skill breaks the first time reality differs from my instructions. I took this from Suchintan of Skyvern in the YC Root Access series, and it held up.

Skills never write straight into what the brain believes. They write drafts, proposals and logs. Beliefs only change through the ladder, and outward work only leaves through the critic.

Then there is the rule that makes the system grow. I call it the fixed point, a name I borrowed along with the idea from the Answer This talk in YC Root Access: if a task cannot be done well with the skills that exist, stop and write the skill. Do not improvise the job and move on.

The steps are short: name the gap → check whether an existing skill could be tuned instead → draft the new one in the standard shape → test it once on real work → log it → add it to the catalogue.

   A TASK ARRIVES
        |
        v
  Is there a skill for it? --- yes ---> RUN IT --> THE CRITIC
        |
        no
        v
      STOP
        |
        v
  Could an existing skill be tuned instead? --- yes ---> tune it
        |
        no
        v
  Draft the skill  ->  test it ONCE on real work  ->  fix the gaps
        |
        v
  I review and finalise   (only I author skills)
        |
        v
  Logged + added to the catalogue  ->  the next session inherits it

Three warning signs sit inside the routine that writes routines. Five skills where one will do. A new skill for a single odd case, when the parent skill should be tuned. And any skill that skips the critic.

And one ownership rule: only I author skills. The brain may draft one, and the draft says the brain wrote it. It becomes real only when I review it and sign it off. That is what keeps growth reviewed instead of runaway.

What I learned the hard way

The first test run is where the skill gets written. One skill for logging calls found four gaps in its own first test, in a single pass. It had no bucket for a first conversation with a new person on a live project. Its file names could not hold two calls on the same date. A checkpoint log did not actually check the checkpoint; the brain's verdict was "A gate log that does not check the gate is decorative." And it had no way to log a call after the fact without duplicating what already existed. All four were fixed before I finalised it. I had assumed the draft was the hard part... but the test is where it earns its place.

Creating work is easy; closing it is the job. In one of my other brains, routines created more than 100 tasks and closed zero. A skill that only adds things to a pile is not doing the job. Now every skill says where its output goes and who closes it.

If the run was not logged, it did not happen. Every skill run writes one line saying who ran it, what went in and what came out. Without that line, the brain cannot learn from its own work, and neither can I.