AI-Driven Dev Framework: A Markdown SDLC Layer for Claude Code, Cursor and Copilot

The problem AIDD targets: prompt drift across a team

Every engineer who uses an AI coding tool eventually writes their own commands. One person has a review prompt, another has a planning prompt, a third pastes the same architecture description into every session. The prompts diverge, the outputs diverge, and nothing about the process is reviewable in a pull request. AIDD's answer is to package the process itself as versioned artifacts that install through a plugin manager, so the whole team runs the same frame, plan, implement, validate, review, challenge, ship sequence. The README frames this as unifying engineering teams around standardized workflows across modern stacks and legacy systems while reducing technical debt. The target user is a team lead or platform engineer at an organization that already has AI coding tools in daily use and wants the workflow layer to be something the team owns collectively. It is explicitly not a code generator, a linter, or a CI system. It installs instructions and commands into a tool you already pay for.

What actually gets installed: plugins, skills, agents and hooks

The repository is TypeScript, MIT licensed, and organized as a marketplace of plugins. The README's own counter block reports 8 plugins, 50 skills and 2 agents. Six plugins are described as stable: aidd-context, aidd-refine, aidd-dev, aidd-vcs, aidd-pm and aidd-orchestrator. Two more sit outside that set: aidd-ui is marked alpha and aidd-telemetry is marked beta, and the README says to install them separately. The distinction matters because the standard install command block only lists the six. Skills and commands are markdown, which is why the README states the workflows themselves need nothing beyond an AI coding tool. The one component with a real runtime dependency is the plugin that ships hooks, which the README says requires Node 22 or later on your PATH. If you install only the markdown plugins, you are installing text files and command definitions. If you install the hooks plugin, you are adding a Node process to the loop, and that is the piece most likely to break on a machine with an older Node.

The SDLC flow and how the orchestrator chains it

The headline command is /aidd-orchestrator:01-sdlc, shown in the README with the argument "add rate limiting to the /login endpoint". The documented pipeline is frame when needed, then plan, implement, validate, review, challenge, ship. The README's flow diagram splits this into a setup phase that runs once and a per-feature loop that repeats. Setup builds what the project calls the project memory bank, described as durable project context. The per-feature loop has three stages: Frame, where a functional need or User Story becomes an issue or ticket and then a plan; Deliver, where implement, validate and review run in sequence; and Ship. The design intent is that context is established once and reused, rather than re-explained per session. That is the context engineering angle the repository topics reference. The word challenge in the chain is worth noting: it implies a step whose job is to argue with the implementation rather than confirm it, which is a different posture from the review step that precedes it.

Installing it: marketplace versus flat, and why the split matters

For Claude Code the README gives slash commands run inside a session: /plugin marketplace add ai-driven-dev/framework, followed by six /plugin install lines, one per stable plugin, each suffixed with @aidd-framework. The same commands work from a shell prefixed with claude, for example claude plugin install aidd-context@aidd-framework. Updates go through /plugin marketplace update aidd-framework. For Cursor, Copilot, Codex and OpenCode the model changes. You download a per-tool bundle from the latest release and either unzip a marketplace archive and register it, or unzip a flat archive directly into a project directory: .cursor/ for Cursor, .github/ for Copilot, .codex/ for Codex, .opencode/ for OpenCode. OpenCode is flat only. The README also notes that installing host-wide for several tools can make the same command appear more than once, because one tool reads another tool's settings, and describes this as harmless. Cursor users can hide the duplicates by disabling Include Third-Party Plugins, Skills, and Other Configs under Settings, Rules, Skills, Subagents. That duplicate-command behaviour is the clearest sign that the multi-tool support is a compatibility layer over conventions rather than a single unified mechanism.

Where the flat install model creates real friction

The trade-off between the two distribution modes is not cosmetic. A marketplace install is registered once and updated with a single command, so every engineer on the team converges on the same plugin version. A flat install copies files into a directory inside the repository, which means the framework's skills and commands become part of your project tree and move through your own review and merge process. That is attractive if you want to pin and audit exactly which prompts your team runs. It is unattractive if you want updates to arrive without a pull request, because with a flat install you are the update mechanism. The README does not describe a sync or upgrade command for flat installs, so the material available does not establish how a flat-installed copy is refreshed. Treat that as an open question to answer before choosing flat for a large team. The other constraint is tool coverage: Gemini and Mistral are listed as in progress with no release distribution named, so anyone on those tools has nothing to install today.

The case for writing your own skills instead

The README anticipates the obvious objection and links to an FAQ entry titled why AIDD instead of your own skills. That link is the honest comparison point, and it is worth reading before adopting, because the alternative is not a competing framework. It is the status quo: a handful of hand-written command files in .claude/skills/ that your team maintains directly. The practical difference is surface area. A hand-rolled setup is a dozen files you fully understand and can edit in an afternoon. AIDD is roughly fifty skills across eight plugins with two of them still alpha and beta, which means more coverage of the SDLC but also more surface to learn and more places where an upstream change alters behaviour your team depends on. If your process is genuinely unusual, hand-written commands will fit it better than a general SDLC pipeline. If your process is ordinary and the problem is that nobody follows it consistently, the packaged version is the one that survives staff turnover.

Maintenance cost, versioning and the MIT licence

The release cadence visible in the supplied material is frequent. Version v5.10.0, cli-v5.3.0 and aidd-vcs-v2.3.2 all landed within roughly a day of each other in September 2026, and the project is not archived. Three separately versioned components means three things that can move independently, so a team pinning the framework should pin per plugin rather than assuming one version number covers everything. The MIT licence is permissive and imposes no copyleft obligation on your own code, but it also means no warranty and no support commitment from the maintainers. That combination is normal for developer tooling and is not a reason to avoid the project. It is a reason to decide deliberately whether you consume updates continuously through the plugin manager or pin a flat copy you control. The README does not document a compatibility matrix between framework versions and tool versions, so if you pin, you are also pinning against whatever Cursor, Copilot or Codex ships next.

Editorial conclusion

Adopt AIDD if your team already works in Claude Code and wants a shared, versioned SDLC expressed as markdown commands rather than each engineer inventing their own prompts. Do not adopt it if you are on Gemini or Mistral, or if you need OpenCode with a plugin manager, since that combination is flat-only. Before committing, verify two things yourself: that Node 22 or later is on the PATH of every machine that will run the hooks plugin, and that the six stable plugins install cleanly under your tool's plugin manager rather than falling back to a flat copy into .cursor/, .github/, .codex/ or .opencode/.

Official sources

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