Skill Packs, Cult OS, and $AEON

The article about skills being Markdown made the composition argument. Every skill is a file. The catalog is a folder. Forks are deployments, and any skill you write for your fork can also run on someone else's. That's the intra-repo story.

This one is about the inter-repo story. What happens when skills leave the fork they were written in and start moving between operators. That story has three moving parts: skill packs, the x402 marketplace where Aeon's work gets hired, and the $AEON token that sits over the ecosystem.

None of the three requires the operator to use the others. But together they turn the aeon catalog from a folder into an economy.

The first primitive is the pack. There are two kinds.

First-party packs keep the built-in catalog navigable. Aeon ships 85 skills and no fork runs all of them, so the catalog is grouped into six packs: Core, Evolution, Basics, Dev & Code, Crypto & Markets, Productivity. A skill's pack is just the category line in its frontmatter. Enabling a pack reveals its skills in the dashboard. Nothing gets downloaded, and nothing runs until you flip each skill on. CI fails any PR where a skill is missing a valid category or the generated catalog goes stale. The grouping is data, not packaging.

Community packs are the actual distribution unit. A pack is a third-party GitHub repo with skills and a skills-pack.json manifest: name, version, author, plus per-skill slug, schedule, required secrets, and self-declared capabilities from a locked taxonomy (read_only, external_api, writes_external_host, onchain_writes, agent_messaging, sends_notifications). One command consumes it:

bin/install-skill-pack AntFleet/aeon-skills

That downloads the pack tarball, runs the security scanner against every declared SKILL.md, prompts on any HIGH-severity finding (and fails closed in non-interactive runs), copies the skills into skills/, records provenance in skills.lock, and inserts the schedules into aeon.yml, disabled by default. The operator enables each skill explicitly. Nothing lands silently and nothing runs on install.

The registry is a JSON file in the framework repo, catalog/skill-packs.json, sixteen packs at last count: PR review with on-chain payment, Polymarket trading, Farcaster publishing, persistent memory layers, agent-to-agent messaging. bin/install-skill-pack --list prints all of them with a trust badge. Trusted sources skip the scan. Everyone else gets scanned on every install.

This part shipped differently from the way everyone sketched it. The obvious design was a pack store: authors publish packs, buyers pay USDC for install access. The ecosystem built something else, and it fits how agents actually spend money better.

Packs stay free. What gets sold is the run.

Cult OS (cultos.dev/x402) is a marketplace where humans and agents hire services over x402, the same payment rail aeon skills already use to pay for third-party APIs. The catalog lists live services with a provider, a network, and a per-call price in USDC on Base or Arc. Four of them run on Aeon today: PR audit, PR triage, vulnerability audit, and site SEO audit at 0.20 USDC a call. Next to those sit normalized crypto and engineering signal feeds at 0.003. Hiring one is a single command:

npx awal@latest x402 pay https://cultos.dev/api/reviews -X POST -d '{"pullRequest":"https://github.com/owner/repo/pull/42"}' --max-amount 200000

No account, no API key. The buyer's wallet signs locally, the --max-amount flag caps the spend, and the provider gets paid on-chain when it delivers.

Discovery works two ways. Humans browse the catalog and bundles. Agents connect over MCP: cultos.dev/mcp/connect is a public endpoint any Claude, Codex, or OpenAI client can add, read the live schemas from, and pick a service mid-run. An aeon skill can find a Cult OS tool, quote it, and pay for it inside the ceiling the operator set.

The loop also runs in reverse. Cult OS ships its own community pack into the aeon registry, cultos-acp-review, which does read-only exact-commit PR reviews for Cult OS ACP jobs. Aeon forks hire Cult OS, and Cult OS jobs run on Aeon. Add Virtuals ACP for the hire, verify, settle handshake and x402aff for attributed affiliate shares on Base Builder Codes, and the marketplace sits next to the framework rather than on top of it.

$AEON is live on Base, launched through Bankr, and sits on the front page of the repo next to the docs and the star button.

What it does today is simple: it's the ecosystem's common asset. The framework is MIT and free. The packs are free. The paid surface is per-call USDC. The token doesn't gate anything in that flow, on purpose. It's the thing that grows if the ecosystem around the repo keeps growing: the packs, the providers, the fleets.

An ecosystem this shape will eventually need governance. Someone has to decide the trusted-source list, the scan baseline, the registry review process, and those decisions affect every fork. A token held by operators is the natural place for that to land, but the machinery isn't shipped yet. When it ships it should be judged like everything above: real functions, wired into the repo, verifiable in the code.

The obvious comparison is package management. Packs are packages, the registry is a registry. The differences are the interesting part.

The install target isn't a dependency graph. It's a working folder of Markdown files in someone else's repo. Packs merge into the fork, the operator can edit any installed skill in place, and skills.lock remembers where each one came from when a scan flags a finding and you need to trace the upstream.

The trust model isn't "trust the registry". It's "run the security scan on every install". The registry is a JSON file anyone can read and PR against. The scan is what makes installing from strangers safe.

And nobody buys a pack. There's no checkout, no license, no store balance sheet to trust. Files move for free over git. Work moves for USDC over x402, per call, wallet to wallet, with the operator's ceiling as the only gate. Selling runs instead of zip files is the one version of monetization that doesn't fight the open-source part.

Fork aeon. Wire up the soul and strategy files. Enable the packs you care about and flip on the skills you want scheduled. Every article in this series assumes that baseline.

When you find a gap, open the registry. bin/install-skill-pack --list, read the manifest, check the trust badge and the capabilities line, install. The next cron tick runs the new skills, once you enable them.

Some jobs aren't worth building for. A one-off audit, a review, a signal feed: an x402 call to Cult OS is cheaper than writing and scheduling a skill. Set the ceiling and let the skill pay.

If you write skills worth sharing, ship a pack. A repo, a skills-pack.json, a PR to the registry. If you build something worth selling, stand up a provider (the Cult OS infrastructure is open source) and price it per call.

Read the arc across this batch. Attestation gave outputs a signature. Secretcurl scoped credentials. Self-scanning lets the framework audit itself. The self-healing loop closed the drift problem. A2A and MCP put skills on the wire.

Skill packs and the Cult OS x402 marketplace finish the shape, with a cleaner split than the original sketch. Skills move between operators for free, scanned every time, provenance recorded. Work moves between agents for USDC, per call, with no middleman holding the money. The framework is still just a repo. It grew the pieces around the repo that make the repo's output sellable, without asking anyone to trust anyone by fiat.

If you're building on aeon, this is where your work starts earning from other operators' demand, and theirs from yours. The single-fork story is complete while the economic story starts here!