Four months ago I wrote that Claude Buddy stopped being a tool and became an extension. Today it stopped being one plugin and became four.

The interesting part isn’t the count. It’s what those four plugins contain. Add up the code that Claude Buddy actually ships in this release, and most of the value it delivers lives somewhere else: in Daniel Miessler’s framework, in MuleSoft’s own skills, in Salesforce’s, in a Spring Boot generator, in the upstream installers for all of them. The new marketplace is less a pile of software than a set of contracts about where software comes from.

That sounds like a step backward. Fewer lines of your own code, more dependencies you don’t control. I’d argue it’s the opposite, and this release is where the argument stops being theoretical.

What Grew, and the Shape It Took

The v5 decision was simple to state and hard to live by: depend, don’t duplicate. Instead of reimplementing memory, identity, and learning inside Claude Buddy, I made the personal-AI framework a dependency and inherited all three. The tool got smaller and better at the same time.

This release scales that decision from one dependency to a distribution model. The marketplace manifest is now versioned (1.1.0, the first release to carry a version field at all), and it registers four plugins instead of one.

The public site frames them as four plugins, one ecosystem, and the names tell you the layering:

• LifeOS is the foundation: persistent memory, identity, and steering rules.
• Buddy (5.4.0) is the workflow platform: seven skills, twelve personas, six domains.
• SDLC (1.1.0) is the Tactical Loop: a ticket-driven layer that sits on top of Buddy.
• Setup (2.1.0) is the installers: thin wrappers that wire everything up.

The dependency chain runs downhill. SDLC depends on Buddy. Buddy depends on LifeOS. Setup installs the pieces underneath all of it. Nothing in that chain reimplements the layer below it.

The Installer That Vendors Nothing

Start with Setup, because it’s the smallest plugin and the biggest idea.

Setup ships four commands: /setup:lifeos, /setup:mulesoft, /setup:salesforce, and /setup:springboot. You’d expect each one to carry a bundled copy of the thing it installs. None of them do. Each command drives the tool’s own official upstream installer, fetches the current instructions at runtime, and asks permission before it changes anything on disk.

The site’s phrasing is exact: nothing is vendored, so installs never drift. That last word is the whole point. When you vendor an installer, you freeze it. Six months later the upstream project has moved, your copy hasn’t, and every new user installs a version that was already stale on the day you shipped it. A thin wrapper can’t go stale, because it holds no version to be stale about. It holds a pointer.

This is the same posture I keep coming back to when I write about owning the harness rather than the model. The leverage isn’t in hoarding code. It’s in controlling the seams: what runs, in what order, with your approval at each mutation. Setup owns the seams and delegates the substance.

The cost is real, and I’ll get to it. But the shape is clean. A marketplace whose installers vendor nothing can absorb upstream changes without a release of its own. It bends instead of breaking.

Repointing the Foundation: PAI Became LifeOS

Here’s the test that turned the philosophy into proof.

Between v5 and this release, Daniel Miessler evolved his framework. Personal AI Infrastructure (PAI) became LifeOS, the Life Operating System. Same lineage, new name, new scope. For a project that had bet its entire memory-and-identity layer on PAI, that’s exactly the kind of upstream move that usually forces a painful migration.

It didn’t. Because Buddy depended on the framework instead of copying it, the migration was a repointing, not a rewrite. Buddy’s description changed from “PAI-native” to “LifeOS-native.” The setup plugin learned to install LifeOS. The old pai plugin (now 1.1.1) is marked deprecated and kept only for legacy installs. No memory subsystem got rebuilt, because Claude Buddy never had one to rebuild.

Compare that to the counterfactual. If v5 had forked PAI’s memory system into Buddy’s own codebase, this release would have been a migration project: reconcile the fork, port the changes, test the merge, hope nothing broke in the seams. Instead it was a dependency swap and a deprecation notice.

I wrote last winter about the three-pillar architecture that a half-dozen builders converged on independently: memory, skills, and a heartbeat. The lesson underneath the convergence is that the pillars are worth depending on, not reinventing. This release is that lesson billed to my own project and paid without pain.

Two Ways to Work

The other headline is that Claude Buddy now ships two workflows with genuinely different opinions, and it’s honest about the fact that one shape doesn’t fit every job.

Buddy, the original, is document-centric. You move through a sequence of skills that each produce an artifact: foundation, spec, plan, tasks, implement, commit, docs. It suits greenfield work and anything where the specification is the thing you’re really negotiating. The documents are the audit trail, and the workflow is opinionated about producing them in order.

SDLC is the new plugin, and the site calls it the Tactical Loop: Research, then Plan, then Implement, then Validate. It’s built for brownfield projects, the messy existing repositories where you don’t start from a blank spec, you start from a ticket. /sdlc:prime pulls context from a Jira issue or a Confluence page and reads the surrounding code. /sdlc:plan reduces the agent’s assumptions and writes a handoff plan a human approves. /sdlc:implement executes strictly from that approved plan in a fresh context, and delegates the actual test-driven execution back to Buddy. /sdlc:validate runs the tests, the linter, the type-checker, and the build, and reports honestly.

Two design choices stand out. /sdlc:init checks a lean AI layer into the repository: a short CLAUDE.md, a set of context modules, and an .mcp.json scaffold, all in plain text, all versioned with the code. And /sdlc:rca closes a loop most tools leave open: it root-causes a bug and proposes the rule that would have prevented it, so the next run is a little smarter than the last.

That checked-in, plain-text AI layer is the same instinct I unpacked in stealing the contract, not the catalog: keep the knowledge in Git-native text you already govern, not in a vendor’s managed store. SDLC talks to Jira, Confluence, and GitHub through MCP, with a human in every gate, and it credits its structure openly to Cole Medin’s work on AI-native development and his ai-native-starter-pack.

When do you reach for which? If you’re specifying something new and the argument is about what to build, start with Buddy’s document flow. If you’re working a backlog against an existing codebase and the argument is about how to change it safely, run the Tactical Loop on top. They aren’t rivals. SDLC delegates its foundation and its TDD execution back to Buddy and adds the parts Buddy doesn’t have.

New Domains, Same Detector

The quieter improvements land in Buddy’s domain system, the part that auto-detects your project type and loads templates and personas tuned to it.

This release adds a Salesforce domain to the existing set, so detection now covers a default profile plus React, JHipster, MuleSoft, Salesforce, and Spring Boot, with a wizard for building your own. The React domain was refreshed for React 19 and Vite, and the MuleSoft domain now leans on the official API-design skills rather than a hand-rolled approximation. Same detector, wider reach, and the MuleSoft refresh is one more case of depending on the upstream instead of guessing at it.

What I’m Still Watching

Owning nothing has a bill, and I’d rather name it than pretend the design is free.

Thin wrappers inherit their upstreams. If LifeOS or the Salesforce skills change in a way that breaks an assumption, Setup carries that breakage straight to your machine, because it holds a pointer, not a pinned version. The flexibility that keeps installs from drifting is the same property that removes a version I could freeze in an emergency. That’s a trade I’m making on purpose, but it’s a trade.

SDLC leans on MCP servers for its Jira, Confluence, and GitHub integration. It degrades to the gh CLI and manual steps when a server is absent, which is the responsible fallback, but a fallback is the graceful path, not the happy one. The full loop is at its best when the servers are there.

There are no git tags and no changelog in the marketplace yet. Version discipline lives in the plugin manifests, which is enough for me to reason about but thin for anyone auditing what changed between releases. That’s near the top of my list to fix.

And two workflows is one more than newcomers expect. Someone landing on the marketplace for the first time has to learn that Buddy and SDLC are complementary layers rather than competing products before they know which command to run. Clarity is a feature I still owe.

Owning Nothing Is the Point

Step back and the four-plugin shape stops looking like sprawl. It’s the depend-don’t-duplicate rule applied all the way down, until the marketplace is mostly a set of well-chosen dependencies held together by installers that vendor nothing.

The payoff showed up the moment PAI became LifeOS and the migration cost almost nothing. The next payoff is structural: a new domain, a new upstream tool, a second workflow like the Tactical Loop, each can slot into the ecosystem without a rewrite, because the ecosystem was designed to hold things it doesn’t own. Composition is the default, not the exception.

If you want to try it, the install is three plugins and a setup command, and it’s all on the Claude Buddy site and in the marketplace repository. Add the marketplace, install setup, buddy, and sdlc, then run /setup:lifeos and /buddy:foundation.

---

This is the next chapter in the Claude Buddy arc: Why I Built Claude Buddy to the tool becoming an extension to this, the extension becoming an ecosystem. The convergence thesis that predicted the shape is here.

Find me on X or LinkedIn. I write about what happens when AI infrastructure meets regulated reality.