airon

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

airon is that configuration as a repository. Its own subtitle is Agents, Orchestrators, and Skills.

Symlinks, not copies

The install script wires a checked-out repo into ~/.claude:

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

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

The generic cousin

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

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

It is configuration rather than a product. It sits under the other two: AgentRunner schedules agents, TaskForge coordinates their work, and airon is how the agents themselves are configured across machines.