We set the GA bar for ADD — a spec-first, TDD-enforcing methodology plugin for Claude Code and Codex (docs here) — deliberately in v0.9.5: engineering evidence, not calendar time. Multiple releases past v0.9.0 with no post-tag rollback. A community fix merged during beta. A release-evidence bundle for the GA candidate. Install paths verified by machines, not by a maintainer clicking through a happy path. That bar is why v1.0 has taken this long.
What “provable” means in practice
Every push to main runs two install smokes with real agents behind them (live since v0.10.0). The Claude leg installs the plugin from the marketplace layout and drives /add:init --defaults headlessly until a valid project config exists. The Codex leg builds a pinned CLI (0.144.5) in a container, runs the same installer a user runs, asserts the full installed surface — 28 skills, five sub-agents, hook schemas — and then also drives init with a live agent. Their first live runs immediately found three real bugs, including #24, which had silently disabled ADD’s sub-agents and hooks on modern Codex, and #23, which made headless init impossible. That’s the argument for them in one sentence.
This week’s releases, v0.10.2 and v0.11.0, finished the loop:
| Change | Why it matters |
|---|---|
/add:doctor | One command that verifies an install in the field: version agreement, hook and agent schemas, feature flags, path resolution, manifest integrity. Each failure prints its remedy. The checks are a tested shell library, not prose. |
/add:init --defaults | True zero-question init for headless sessions and CI. The install smokes use the same flag a user would — the tests and the product share one path. |
| Install manifest | The Codex installer records every file it writes with a checksum. Upgrades back up files you have edited instead of overwriting them; uninstall removes exactly what was installed and nothing else. |
| Namespace hygiene | Codex sub-agents are now registered as add-* so they cannot collide with your own agents. The installer migrates old names and leaves anything it does not own untouched. |
| Honest version floor | The Codex adapter declares the minimum CLI generation it actually works on (0.140+, corrected during the v0.10.x fixes), instead of a floor that predated the current schema. |
All of this is the difference between “installed without an error message” and “installed, verified, and recoverable.” Migration remains automatic from any version ≥ 0.5.0 — the hop chain is continuity-checked by the release-evidence script for every release.
The one criterion left
Marketplace listing approval. The candidate build is what shipped this week; when the listing clears review, v1.0.0 goes out as a promotion tag — a statement that the bar was met, not a release that changes behavior. We chose that sequencing on purpose: the artifact under review is the artifact that was tested, and GA day introduces zero new code.
After v1.0: a small core, extended by plugins
The most important decision we’ve made about ADD’s future is what not to put in it. ADD core is a methodology runtime: specs, plans, TDD enforcement, maturity gates, learnings, multi-runtime install. It’s pure markdown and JSON with zero agent-side runtime dependencies, and every rule it injects costs context tokens in your sessions. Every feature added erodes both — the dependency-free install and the token bill — so the core’s feature budget is effectively spent.
Growth happens as loosely-coupled companion plugins instead — each optional, installable and removable on its own, so nobody carries weight they didn’t ask for. The areas we’re actively exploring, roughly in order:
- Telemetry & analytics — ADD already specifies an OTel-aligned JSONL telemetry format; a companion plugin would own emission, aggregation, and the cost/velocity dashboards, so projects that do not want measurement never pay for it.
- Enterprise controls — org-level policy packs: stricter deploy gates, audit trails, compliance reporting. The kind of thing a platform team turns on for every repo, and a solo developer never sees.
- CI/CD integrations — first-class bridges from ADD’s quality gates and evidence bundles into GitHub Actions and friends, beyond the smokes we run on ADD itself.
The contract between core and companions is the same one our two runtimes already honor: shared state lives in .add/ with documented schemas, and anything a companion needs from core has to be a stable, versioned surface. Each companion will live in its own repository — the split we already made for this website — and ship under the same evidence bar as core: signed releases, install smokes, migration chains. If we can’t prove a plugin installs cleanly, we won’t list it. These are directions, not dated commitments; specs will land in the open before any code does.
Try the GA candidate
claude plugin marketplace add MountainUnicorn/add
claude plugin install add@add-marketplace # fresh install
claude plugin update add@add-marketplace # upgrade — migration from any 0.5.0+ is automatic
/add:init # or --quick, or --defaults
/add:doctor # prove the install is healthy
On Codex: curl -fsSL https://raw.githubusercontent.com/MountainUnicorn/add/main/scripts/install-codex.sh | bash, then /add-doctor. Releases are GPG-signed; verify a tag yourself:
curl -fsSL https://github.com/MountainUnicorn.gpg | gpg --import
git tag --verify v0.11.0If the doctor reports something we didn’t anticipate, that’s exactly the feedback we want before v1.0 — open an issue. Full release notes: v0.10.2 · v0.11.0.
Tagged: GA · v0.10.2 · v0.11.0 · roadmap · plugins · install-verification