aidd-framework: one SDLC rendered into eight archive shapes for six coding tools

Six stable plugins install in one block, three more ship separately

The scope is stated as three counts: nine plugins, fifty-one skills and two agents. Those numbers sit between HTML comment markers named as a start and an end, which means they are generated rather than typed, so a reader can treat them as a snapshot that a release updates.

Six of the nine plugins are called stable and install in a single block:

/plugin marketplace add ai-driven-dev/framework
/plugin install aidd-context@aidd-framework
/plugin install aidd-refine@aidd-framework
/plugin install aidd-dev@aidd-framework
/plugin install aidd-vcs@aidd-framework
/plugin install aidd-pm@aidd-framework
/plugin install aidd-orchestrator@aidd-framework

The other three are deliberately excluded from that block and are named with a maturity label each: `aidd-ui` is alpha, `aidd-telemetry` is beta, and `aidd-qa` is new. Installing those separately is a considered choice rather than an omission, and it means the default install is the conservative subset.

The same seven commands work from a shell with a `claude` prefix in front, and updating later is one command, `/plugin marketplace update aidd-framework`.

The unit of work the whole thing exists for is a single orchestrator call, shown with a natural language request and its resulting sequence: frame when needed, plan, implement, validate, review, challenge, ship.

Only the hooks plugin needs Node 22, and the workflows are markdown

The prerequisite section has exactly two entries, and the second one is narrower than it first appears. The first is an AI coding tool. The second is Node 22 or later on the PATH, qualified as being needed only for the plugin that ships hooks. The workflows themselves are described as markdown and as needing nothing.

That single sentence explains most of the distribution design in the rest of the page. If the substance of the framework is markdown files containing skills, commands and rules, then any tool that can read a directory of files can run it, and no plugin manager is strictly required.

It also means the Node requirement is a real dependency for exactly one component rather than a floor imposed on the whole thing. A team that only wants the skills and agents can take the flat copy and never install a runtime.

The two maturity labels elsewhere in the page sit next to that split. The telemetry plugin is the one marked beta, and the root project ships a script named for a telemetry reference week, so the one component that reports anything outward is also one you opt into separately.

Eight archives per release, and two tools get flat files only

Tools other than Claude Code install from a bundle downloaded from the latest release, and the bundles are named per tool and per distribution mode. Counting the names on the page gives eight: a Cursor marketplace archive and a Cursor flat archive, the same pair for Copilot and for Codex, and flat-only archives for OpenCode and Kilo Code.

The two modes are defined once and mean something specific. Marketplace means installed and updated through the tool's own plugin manager. Flat means the files are copied directly into the project with no plugin manager involved.

OpenCode and Kilo Code are flat only, with no marketplace column entry. Kilo has an extra manual step, since its flat archive includes a generated `kilo.jsonc` and you have to start a new Kilo session for the generated project plugin to load. OpenCode has no equivalent note beyond unzipping into `.opencode/`.

The flat layout mirrors each tool's own directory convention: `.cursor/`, `.github/` for Copilot, `.codex/`, `.opencode/` and `.kilo/`. So the same content lands in five different trees, which is the maintenance cost the release automation has to absorb and the reason the release notes matter to anyone pinned to a version.

Two tools also read the Claude layout directly, which is the one place the formats overlap rather than diverge.

The verb differs per tool, and host-wide installs duplicate commands

The install commands are not uniform, and the differences are small enough to be missed. Copilot uses `plugin install`:

copilot plugin marketplace add ./aidd-framework-copilot-marketplace-<version>
copilot plugin install aidd-context@aidd-framework   # per plugin

Codex uses `plugin add` for the same operation, with the same per-plugin comment:

codex plugin marketplace add ./aidd-framework-codex-marketplace-<version>
codex plugin add aidd-context@aidd-framework   # per plugin

Cursor's marketplace route takes a different shape entirely, since it is a file copy rather than a CLI call, landing under `plugins/aidd-*` in the user's local plugin directory:

cp -r plugins/aidd-* ~/.cursor/plugins/local/

Then there is the cross-tool consequence, flagged in a note rather than buried. Installing the framework host-wide for several tools can make the same command appear more than once in a tool's list, because one tool reads another tool's settings. The page calls it harmless. For Cursor it gives the remedy, disabling a setting for including third-party plugins, skills and other configs under the rules, skills and subagents section.

The same note also flags a plan limit, with team marketplaces requiring a higher Cursor plan.

Three tags in ten seconds carry three different version lines

The three most recent releases were all published on the same day, within about ten seconds of each other, and none of them shares a version number with either of the others: the framework at 5.11.0, a CLI component at 5.4.0, and a version control component at 2.4.0.

That is a monorepo releasing independent streams, which is the right call when a CLI and a plugin set version independently. It is also why there is no single version to quote, and why a release archive name carries a placeholder for the version of the bundle rather than of the framework as a whole.

The repository root is arranged for it. A manifest for the release tooling and a separate configuration file for it sit at the top level, alongside a dedicated release document and a changelog. The presence of three tags seconds apart suggests automated publishing rather than hand-tagged releases.

The last push to the default branch is dated 2026-10-01, a week after those tags, so the branch and the newest release are close but not identical, which is the normal state for a repository that cuts several component releases per week.

The root package sits at 0.0.0 and the only test script is bespoke

The root manifest describes the repository as a community-maintained marketplace of skills, agents and rules for Claude Code. It is marked private, its license field is MIT, and its version is 0.0.0 while the tags say 5.11.0. The private flag plus an automated release process is why the root version is a placeholder rather than something you install.

The runtime requirements are Node 22.12 or newer with pnpm pinned to an exact version. Only two scripts exist at the root, and neither is a build: one installs git hooks, one runs a changed-file test script, and one runs a telemetry script.

That test script is worth noting. There is no test framework in the development dependencies at all, no runner, no assertion library. Testing is a hand-written Node script that looks at what changed, which is a defensible choice for a repository that is mostly markdown with a small amount of TypeScript, and an unusual one.

What the development dependencies do contain is a schema validator, a JSON Schema library with its formats plugin, a YAML parser, a git hook manager, and two commit lint packages. The schema validator is the piece that matters for a framework shipping into five different tool directory layouts: something has to check that a generated configuration is well-formed.

prepare ends in || true, and the Makefile installs hooks the explicit way

The root install hook is a single line that swallows its own failure. The prepare script runs the git hook installer and appends a shell operator that makes a non-zero exit succeed anyway.

The reason is visible in the Makefile, which contains its own setup target that installs dependencies with scripts disabled and then installs the hooks explicitly with a force flag. So a contributor running the documented setup path gets the hooks installed deterministically, while someone running a bare package install gets an attempt that cannot fail loudly.

That is a reasonable split, and it is also the kind of thing that hides a problem for a year. If the hook manager cannot install, the install still reports success.

The Makefile is otherwise a small, well-behaved tool. Its default goal is help rather than a build, and help is generated by grepping the makefile for targets carrying a double-hash comment and sorting the results, so the list stays accurate without a separate file. The other targets are a doctor target that runs a shell script to check the local toolchain, a check target that runs the pre-commit hooks, and a reload target that syncs this checkout into Claude, Codex and OpenCode, taking a plugin name that defaults to all.

A kanban directory sits at the repository root as well, so the framework tracks its own work in the same repository it ships.

The loop diagram stops mid-subgraph

The per-feature loop is introduced as a diagram, and the diagram is where the page ends. The flow opens with an onboarding node described as inspect and guide, then a setup group marked as happening once containing project memory labelled durable project context, then a loop group marked as per feature and repeat.

Inside that loop the Frame group runs left to right from a functional need or user story to an issue or ticket to a plan. The Deliver group runs from implement to validate to review. Then the Ship group begins and the diagram is cut off, and the sentence that should follow it begins with a functional need or a user and stops there.

So the frame and deliver stages are legible and the ship stage is not, on this page. The links to the system guide and the release documentation are elsewhere.

It is worth pairing that with the other description of the same loop, because the two do not match. The orchestrator example at the top of the page lists seven steps: frame when needed, plan, implement, validate, review, challenge, ship. The quick start table describes the feature flow as four: frame, deliver, check, and a pull request. The diagram uses a third grouping, with frame, deliver and ship as named subgraphs.

Three descriptions of one loop, none of them cross-referencing, is the main documentation gap in an otherwise unusually complete page.

Editorial conclusion

This is a workflow pack rather than a library, and the interesting part is how far the same content travels: nine plugins and fifty-one skills rendered into eight archive shapes so one methodology can land in six tools. Two things to weigh. Only one plugin needs Node 22, and the workflows themselves are markdown, so a flat copy is genuinely usable and you are not adopting a runtime. And the compatibility list is candid about its edges, with Gemini and Mistral marked in progress and the instructions warning that host-wide installs make the same command appear twice. If you want a single tool to drive, start with the guided onboarding command rather than reaching straight for the orchestrator.

Frequently asked questions

Official sources

1. ai-driven-dev/framework on GitHub
2. License: MIT
3. Project website
4. README
5. Releases