airon

Working seriously with a coding agent means accumulating configuration, which is to say the instructions that it should always follow, and the commands that you have defined for it, and the skills that it can invoke, and the rules about how it ought to behave. That accumulation happens on whichever machine you happened to be using at the time, and then you sit down at a different machine, and none of it is there.

airon is that configuration kept as a repository, and its own subtitle for itself is Agents, Orchestrators, and Skills.

Symlinks, not copies

The install script wires a checked-out repo into the .claude directory:

• The CLAUDE.md file is symlinked, so that the global instructions are editable in place, and the edits write back into the repo
• The commands, and skills, and agents, and rules directories have their contents symlinked into the corresponding directories
• The settings template is generated rather than linked, because a couple of the paths genuinely differ from machine to machine, and they get substituted at install time
• The shell aliases file is sourced from the shell profile

Symlinking rather than copying is the whole of the design. Improving a skill while working on one machine improves that skill in the repo, which means that it improves everywhere at once, rather than leaving 3 divergent copies behind, and no memory of which of them is the current one. The --dry-run flag shows what the installer would do before it writes anything at all.

The generic cousin

airon is explicitly the public counterpart of an internal setup that I maintain at work, with everything employer-specific stripped out of it, and that means the internal code-review loop, and the internal plugins, and the internal build bootstrap, and the internal model configuration.

I split it on purpose rather than letting the split happen on its own. The half that is worth keeping is the plumbing, which is the install, and the symlink, and the settings, and the shell wiring, and the memory that follows me between devices. The half that cannot travel is the integrations with systems that only one employer has. Keeping the 2 halves apart is what makes the rest of it shareable at all.

It is configuration rather than a product, and it sits underneath the other 2 of them, because AgentRunner schedules the agents, and TaskForge coordinates the work that they do, and airon is how the agents themselves are configured across machines.