60 Days of aeon

Two months ago the pitch was simple: a repo, a folder of Markdown skills, GitHub Actions as the runner, and an agent that quietly does work on your behalf. Nothing to install, nothing to babysit. That story hasn’t changed. What has changed is what happens inside a run.

If you forked aeon in May and never pulled again, you’d still have a working agent. But the version running today has grown a spine: cryptographic provenance on every output, per-skill secrets, a tighter blast radius, a CLI that doesn’t need a terminal to talk to. This is the changelog article - the one that catalogues what shipped between the first post in this blog and now, and why each piece matters if you run aeon in production or plan to.

The single largest shift is that every skill run can now carry a signature.

Skill outputs are attested via Sigstore and logged to Rekor. The attestation binds the exact bytes the skill produced to the workflow identity that produced them - repository, commit, workflow file, runner, trigger, timestamp. Anyone can pull the artifact and run gh attestation verify against it without trusting the repo owner.

Attestation is off by default. Turn it on with a single variable, and by default only feed-published runs get signed - the ones that leave the repo and hit an audience. It’s the trust boundary that benefits.

Article #2 in this batch is a deep dive on this alone. The important point for the changelog: aeon crossed from “trust the log” to “verify the signature” in a single PR sequence over one weekend in early July.

The old pattern for auth-heavy skills was ugly. A scripts/prefetch-*.sh file would run before Claude started, with full env access, and cache the response into a folder the skill would read from. It worked, but it meant every prefetch script implicitly had the entire secret store in scope.

The new pattern is secretcurl. Each skill declares the keys it needs. Only those keys are injected at run time, only for the duration of the call, only into the skill that asked. The prefetch scripts are being retired one by one. Blast radius on a compromised skill drops from “all secrets” to “the keys that skill explicitly claimed.”

This is the kind of infra decision most agent frameworks punt on. Article #4 in this batch walks the before/after with real skills.

Alongside the prefetch cleanup, the mirror pattern got retired too.

The old flow for irreversible sends - writing a Telegram message, posting a tweet, calling a paid API - was to write a request JSON to .pending-<service>/ during the run and let a scripts/postprocess-*.sh step drain the queue afterwards. It worked, but the operator had two mental models to hold: what the agent decided, and what actually got sent minutes later after the queue drained.

Now the sends happen in-run via secretcurl. The run either did the thing or it didn’t. The queue folder is gone. The Actions log reflects reality without a delay.

The aeon CLI used to require a TTY. Fine on a laptop, awkward everywhere else.

The July rewrite made every phase headless-capable. Read and write, provisioning and skill invocation, all runnable without a prompt. It’s a small change with an outsize effect on what you can compose aeon into. A cron on your VM can now drive an aeon fork the same way GitHub Actions does.

A quiet migration: outbound email moved from SendGrid to Resend.

The reason wasn’t a fight with SendGrid. It was that Resend’s API surface fits the aeon idiom better - one endpoint, one token, no template dance, no “verified sender identity” ritual. For a framework whose thesis is “the skill file is the whole implementation,” fewer moving parts in the notification layer matters.

If you set the SendGrid env vars in an older fork, they still work through a shim. New installs go straight to Resend.

Two script-injection issues in shipped skills got patched over one 24-hour stretch. A chain-input injection and an arbitrary file read, both flagged as GHSAs, both fixed by pulling the vulnerable ${{ github.event.* }} interpolations out of run: blocks and rebinding them to env: keys the shell reads as ordinary variables.

The pattern is the same one described in the workflow-security-audit article from April. What changed is that a scanner now enforces it. The workflow-security-audit skill runs zizmor plus actionlint over every workflow file in the repo, classifies findings as NEW, REINTRODUCED, UNCHANGED, or RESOLVED, auto-fixes the Critical and High regressions with a _UPPERCASE env-key rebind, and opens a PR only when the delta is non-empty. On a clean audit it says nothing. Silence is the correct output.

Article #3 covers this scanner alongside the two others aeon runs against itself.

In early July, eight parallel agents were dispatched across the codebase with a single shared instruction: dedup shared logic, remove dead code, tighten weak types. Each agent owned a lane. They ran concurrently, opened PRs into their lanes, and the merges came in over 48 hours.

You can see the shape of this in the commit history - a burst of scoped cleanups from a coordinated agent fleet, rather than one giant human refactor. It’s aeon dogfooding: using the framework to improve the framework.

The vuln-scanner skill went from documentation to functional. It picks a trending repo, runs Semgrep plus TruffleHog plus osv-scanner plus Slither where relevant, triages every finding through a “read the code before trusting the scanner” checklist, and routes findings to the correct disclosure channel - a Private Vulnerability Report for code flaws, a public PR only for dependency CVEs that were already public.

The wedge on this one is ethical, not technical. A security scanner that dumps unpatched vulnerabilities into public PRs is a zero-day publisher. This skill won’t do that. Article #3 goes deep on it.

The core bet is the same. Skills are still Markdown. GitHub Actions is still the runner. The dashboard is still an optional Next.js UI that shells out to gh. Forks are still deployments. Public logs are still the audit trail.

Two months of shipping tightened the surface without moving the thesis. The framework got harder to compromise, easier to compose into other systems, and more honest about what it did - signed, logged, and verifiable without asking the operator to install anything new.

If you forked in May, git pull upstream main is worth the merge conflicts.