Skills That Build Skills

The first time you open the aeon skill catalog, the surprise isn’t the number - it’s the format. There are 183 skills, but there’s no plugin SDK, no decorator pattern, no @skill annotation. Every skill is a Markdown file describing what it does and how to do it. The agent reads the file at run time, follows the instructions, and ships the result.

That sounds like a small choice. It isn’t - because this is what makes every other claim about aeon possible, from the composition story to the self-improvement angle, all the way to the audit trail. All of it falls out of the fact that skills are Markdown.

Open any file in skills/. You’ll find something like this (lightly abridged):

# morning-brief
> A priming document for the day, not a news dump.

## Inputs
- Yesterday's log
- MEMORY.md priorities
- Open PRs assigned to you

## Steps
1. Collect candidates.
2. Score each by leverage × urgency.
3. Keep the top three. Reject any that can't justify itself in ≤12 words.
4. Pull 2 candidate headlines via WebSearch. Drop unless they change a focus item.
5. Emit one Telegram message in the format below.

## Output format
*Morning Brief  {date}*

*Focus today*
1. ...
2. ...
3. ...

That’s it. There is no compile step, no type system, no runtime wrapping. When the cron tick fires, aeon hands this file to Claude Code with a small amount of harness context, and Claude executes the instructions. The output goes to the configured channel.

If you can write a clear prompt, you can write a skill. If you can edit a Markdown file, you can fork an existing skill and rewrite it for your use case.

Every other agent framework picks a programmatic surface - a Python class, a TypeScript function, a JSON config. Each one has the same problem: the intent of the skill has to be translated into the form the framework requires, and the translation loses information.

Markdown skills don’t have this gap. The intent becomes the form. The thing you’d write on a whiteboard to explain the skill to a teammate is, give or take, the skill file. Three concrete benefits fall out of that:

Skills are forkable

The upstream aeon catalog lives in aaronjmars/aeon. When you fork, you get every skill. You can edit any of them in place - change their format, swap the data source, rewrite the ranking logic, tighten their output. Just push, and your fork runs your version. No marketplace permission, no publishing flow, no server.

Skills are LLM-authorable

Because the format is plain prose, an LLM can author a new skill from a description. create-skill is a real entry in the catalog. You DM the bot - “give me a skill that pulls the top 5 weekly releases from my watched repos and posts on Fridays” - the agent drafts a Markdown file, opens a PR against your fork, and, once you (or another skill) merge it, the next cron tick runs it.

Skills are reviewable

A Python skill change requires reading code. A Markdown skill change is a diff in prose. PR review on a skill catalog feels closer to editing a magazine than to merging a codebase - and that’s one of the reasons the catalog has grown to 183 skills without becoming unmaintainable.

Skills get interesting when they chain. The chain syntax is the second half of the composition story:

chain:
  - skill: agentic-crypto-scout
    when: cron("0 14 * * *")
    output: scout.json
  - skill: narrative-tracker
    input: scout.json
    output: narratives.json
  - skill: morning-brief
    input: narratives.json
    delivers: telegram

Each step’s output becomes the next step’s input. aeon doesn’t care what’s in the JSON - that’s the contract between the two skills, and it lives in their Markdown spec files. Add a step, remove a step, reorder. The chain re-runs end to end on the next cron tick.

A real example, running in production on one of our contributors’ forks, NurstarK/aeon:

• agentic-crypto-scout - scrapes a watchlist of agent-related crypto narratives.
• narrative-tracker - scores each narrative for momentum and novelty.
• paid-odds-lookup - pays an x402 endpoint for live prediction-market odds on the top narratives.
• morning-brief - folds all three into one digestible message.

Each skill is a few hundred words of Markdown; the chain is six lines of YAML. The result is a daily brief that nobody else gets, because nobody else built that exact chain. Composition is the whole product.

The composition story has one more move that’s hard to pull off in other frameworks: skills that operate on the skill catalog itself. Three live examples from the upstream catalog:

create-skill

You describe what you want. The skill drafts the Markdown for a new skill, opens a branch, writes the file, opens a PR. You merge it - or your pr-review skill merges it (see below). The next cron tick runs the new skill.

self-improve

Runs on a schedule. It reads the past week of skill outputs from the repo and looks for patterns where a skill consistently produced low-signal output, hit rate limits, or fell over on edge cases. It drafts a patch to the offending skill’s Markdown and opens a PR. The agent improves itself in versioned, reviewable steps.

tool-builder

It notices when a skill’s instructions ask for a capability that doesn’t exist as a discrete tool - say, “summarize a YouTube transcript” - and proposes a new helper skill, plus a chain rewrite that uses it. The catalog gets denser over time.

The thing that makes all three tolerable to live with is that everything is a git commit. The agent doesn’t quietly mutate itself - it opens a PR you can see, merge, or close. The audit trail isn’t a feature. It’s the substrate.

The reason aeon can let the agent rewrite its own catalog without anyone losing sleep is that the persistence layer is git. Three properties matter:

• Versioned. Every skill change is a commit. git log skills/ is the audit trail.
• Reviewable. Every change can require a PR. Auto-merge is opt-in, per-skill.
• Reversible. A bad skill change is git revert <sha>. No “oh god, the agent broke itself” recovery procedure.

Most “self-improving” agent demos elide this. They show the agent rewriting a prompt and call it a day. aeon insists on the boring discipline that every change is a commit and every commit can be reverted. The result is an agent that’s allowed to expand itself without anyone losing the ability to roll back.

If you fork aeon today, you inherit 183 skills and a composition surface where you can:

• Edit any skill in place. Open the Markdown, change a line, push.
• Write a new skill in twenty minutes. Copy a similar one, rewrite the spec, push.
• Chain skills together in YAML. No code, no framework dance - just inputs and outputs.
• Ask the agent to write a skill for you. DM create-skill, review the PR, merge.
• Let the agent improve itself on a schedule. Enable self-improve in aeon.yml, review the weekly PRs.

The catalog is the substrate, the chain is the program, and the agent is the runtime. All three are visible in your repo. None of them are hidden behind an SDK.

A skill is a prompt with a name; a chain is a sequence of prompts that share a workspace; an aeon agent is the cron-scheduled execution of those chains, with git as persistence.

If that sentence is true, the rest of aeon’s design follows. Self-improvement isn’t magic - it’s a PR. Composition isn’t a feature - it’s YAML. Skills don’t have to be plugins - they’re files. Once the substrate is plain prose and plain git, the framework stops being the interesting part, and the catalog and the chains become the pivotal players in this agentic game.

Article 5: Receipts, not vibes. Why the GitHub Actions tab is aeon’s observability stack, why “quiet is a feature,” and how to read what your agent actually did last Tuesday at 04:00 UTC.